Retro printer day: I have an old IbmPro compatible dot matrix printer connected by a USB parallel adapter to my Ubuntu 20.04 system. It works great! One major trick in setting it up: set the URI to /dev/usb/lp0 and make sure the lp user is in the right group to write to that dev. That took me a while to figure out. I use the IBMPro generic printer driver and it's great. Other critical hints: 9600 baud, 8 bits, no stop bit, hardware flow control.
The one remaining problem: the print area is offset about 0.5" to the left. I'm sure I know what's going on: the tractor feed area is about 0.5" and so I need to somehow indicate, don't count the tractor feed area within the page margin. In other words, the full page width is about 9.5" but only print 8.5" of that and offset it 0.5" to the right.
I've tried editing the PPD file including changing the values in HWMargins and ParamCustomPageSize WidthOffset. None of this seems to have any impact. I've read a bunch of documentation about PPD files and it's just not clear what to do. I guess I could set up a custom paper size of 9.5" width but I would prefer to just have all my documents be the same and print correctly by offsetting everything as it's generating printer output.
There must be a simple setting for this.
Edit: tried a lot more things including:
Go to Printer Properties and go to Job Options. There's a left margin setting. I set it to 36 points, or half an inch, and that moved printing over. Adjust as desired. But that didn't work. I also tried to make this change in the PPD:
ImageableArea Letter/US Letter: "18 36 612 756"
and that didn't work.
It is fixed. The order of parameters for the gs line in the PPD must be just right and it's not obvious how to get it working. After much trial and error, this line works:
*FoomaticRIPCommandLine: "gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE &&
-dNOMEDIAATTRS -dNOINTERPOLATE -sDEVICE=ibmpro%A%Z &&
-sOutputFile=- &&
-c "<</PageOffset [36 0]>> setpagedevice" -f -"
It must be in exactly that order. Adjust the offset values (36 for the horizontal offset, 0 for vertical, in this case) as needed. This really should have been easier, given that it's going to be quite normal to adjust offsets on any dot matrix printer. I hope this question is useful for anyone else in this situation. Yes do pay attention to the HTML escapes used in the line above, they are correct. I tried before using ' and that didn't work. It must be ".
This was really a lot of effort to figure out although would probably be obvoius to someone experienced in PPD files.
I have a problem that I can't seem to get rid of.
When a customer of mine prints a specific QRP, he gets a "WARNING. This report may extend beyond the printer page margins. Text may be clipped, depending on the printer in use. Do you wish to continue?"
While of course in no way critical, it's a problem due to the sheer number of prints per day this customer has, having to confirm this dialog every time.
I've had this issue before and seemed to be able to fix it by setting the report format to "Custom", but I've recently updated the QRP and the problem is back despite being still set to "Custom". I have also tried A4 (which is the printer's standard page format) and A5, to no avail.
Is there maybe a way to suppress this error in code?
The report itself is way smaller than A4 (it's an A5 format packaging label) so there is no way it would lead to any problems with the print margins, and the prints do come out perfectly fine.
You can use the constant RPT_PrintNoWarn along with SalReportPrint function. The constant is used for suppressing warnings about margin overflow and tiled pages.
It can be combained with constant RPT_PrintNoErrors using pipe symbol.
SalReportPrint ( hWndFrm, strTemplate, strVariables, strInputs, nCopies, RPT_PrintNoWarn|RPT_PrintNoErrors, nFirstPage, nLastPage, nErr )
I'm developing a Windows application in WPF, which uses the "link-os" SKD to print a large amount of tickets over a USB connection with a Zebra GC420t. The problem is that during printing, the printer apparently loses the detection of the black mark and begins to print the content in a wrong position relative to the top of the ticket.
Important points:
My software build a ZPL string in runtime and sends it to the printer;
I'm using the "GC420t" driver (non EPL);
Before starting the print job, I send to the printer some print settings:
"~SD15~TA000~JSN^XA^SZ2^PW639^LL799^PON^PR2,2^PMN^MNM^LS0^MTT^MMT,N^MPE^XZ^XA^JUS^XZ"
At the beginning, the printer is correctly calibrated. Sometimes, when the problem reported in this post happens, the printer becomes uncalibrated.
Below, a ZPL sample code, and the link to a video that demonstrates exactly the moment the error happens. Every help is welcome.
Video: Zebra GC420t error while printing
Zpl String:
~DYE:LOGO1,P,P,34149,,89504E470D0A1A0A0000000D49484452...(Intentionally truncated)
^XA^LS0^LT0^XZ
The statement below is repeated for each label:
^XA
^FO70,0^IME:LOGO1.PNG^FS
^FO57,230^GB533,0,2^FS
^FT0,261^A0N,31,31^FB620,1,0,C^FDEVENTO TESTE^FS
^FO57,272^GB533,0,2^FS
^FT0,294^ACN,18,10^FB620,1,0,C^FD^FS
^FT0,316^ACN,18,10^FB620,1,0,C^FD01/09/2019^FS
^FT0,379^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,431^AAN,27,15^FB620,1,0,C^FDR$ 10.00^FS
^FT0,529^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,510^AAN,18,10^FB620,1,0,C^FD^FS
^FT0,492^AAN,18,10^FB620,1,0,C^FDInformau00e7u00f5es sobre o seu evento!^FS
^FT564,475^ABB,11,7^FH^FD008403615029^FS
^FT0,356^ABN,25,14^FB620,1,0,C^FDREFRIGERANTE^FS
^FT67,569^ABN,11,7^FH^FDPDV: TICKET SIMPLES ESC. 29/12/2018 00:50^FS
^FO57,582^GB533,0,2^FS
^FT0,649^ABN,22,12^FB655,1,0,C^FDREFRIGERANTE^FS
^BY3,3,61^FT172,717^BCN,,Y,N^FD>;008403615029^FS
^FT76,472^BQN,2,4^FH^FDLA,008403615029^FS
^XZ
The above statement is repeated for each label.
Thank you all!
Apparently the problem was solved when I set a more precise value for the label size.
I was setting the height of the label to 100mm, when in fact it measures 107mm.
After I made the adjustment, the problem did not happen again.
[EDIT]
Although the procedure described above has considerably reduced the occurrence of errors, even at a lower frequency, it persists. In contact with Zebra's support, we discovered another possible cause: the texts and logos on the back of the ticket are confusing the sensors of the printer (black mark). We're working on the redesign of the label. I will update this thread again soon.
I'm using wxMaxima 16.12.0 (Maxima 5.39.0) and when I try to print the output, I get overlapping text.
Here's an example (please, ignore the fact the the command couldn't be correct)
1st image
Sometimes happens also with print and printf (inside a block)
2nd image
printf(true, "Link ~d~%", i),
print("+------------------------------------------------+"),
3rd image
But outside a block
4th image
This makes all the output completely unreadable, and my program heavy relies on it. I think that in the 3rd image, the problem is that there is the 2 at the denominator is causing the "shrinking" of the output.
How can I solve it? Is it my problem or Maxima's?
OS: Mint 18 sarah
Kernel: x86_64 Linux 4.4.0-57-generic
DE: Cinnamon 3.0.7
P.S. I also noticed that sometimes, re-running previous commands could make "readable" the following, but that always happens random
EDIT1: I noticed that the last packages that I installed are
libwxbase3.0-dev
libwxgtk3.0-dev
libwxgtk3.0-0v5
libwxbase3.0-0v5
Could it be that there's some kind of conflict?
EDIT2: if I cut the command, the output is "reorganized" in a decent way
become
As BillThePlatypus requested, I'll answer so that everyone will have a quick solution.
In my case, just changing the font solved the problem (i.e. no more overlapping prints), so give it a try.
We have a POS application we have developed that can use any ESC/POS printer via MS POS.Net v1.12. Our application runs fine with Epson printers, but with a Star TSP700 it prints correctly, but it "stutters"/line-by-line (think calling PrintNormal repeatedly rather than using a StringBuilder and dumping it all at once into the queue). Setting the dip switch to what should be ESCPOS emulation does nothing, as I don't think the USB interface supports that according to the docs found on page 98 of https://www.star-m.jp/eng/service/usermanual/tsp700um.pdf. I am building a string and dumping it all at once using Transaction printing in OPOS. The print speed to the customer is unacceptable and replacing 100 printers is also not acceptable. There is another mode we use to connect to the printer aside from OPOS, and that is setting up the printer as a "Generic / Text Only" printer and then I send the escape codes to the printer, but it doesn't print everything out correctly at all - I imagine this is because the printer is expecting Star Line commands.
Phew. Anyone have any input on what to try? Worst case scenario I build in printing via Star commands, so all is not lost, and I'm going to try HexDump mode first to see if I am missing anything, but I would much prefer to not write out a whole library just to handle Star printers if I can avoid it.
ESC + | + N on an Epson printer resets the font to normal after setting it to big, bold, etc. However, this causes the Star to stutter to the point of shaking violently. I was able to remove that escape sequence from my code and have it not affect the output from Epson printers, so now the Star stutters less. Note, it doesn't stop stuttering, it prints 50 lines, flips out for 2 or 3 lines, and repeats. It's really a huge improvement if you are able to see the printer print before and after the fix.