philpem / printer-driver-ptouch

P-Touch PT-series and QL-series printer driver for Linux (under CUPS)
GNU General Public License v2.0
97 stars 24 forks source link

QL-500 Label Misaligned #51

Open Flo2410 opened 3 months ago

Flo2410 commented 3 months ago

Describe the bug I'm trying to print some labels with my QL-500 printer onto 17x54 mm die-cut labels. Unfortunately, the print does not align with the label itself, see picture below. Furthermore, the label gets pushed out too far, and cutting it cuts off a part of the next label.

The labels are generated by the label generator of PartDB. I'm printing via die KDE system dialog opened with floorp (firefox). The only label size which actually prints is the autogenerated custom_16.93x53.98mm, using the actual size of 17x54 mm results in the printer's power led flashing.

The exact same label works on Windows 11, printed directly via floorp.

To Reproduce Steps to reproduce the behavior:

  1. Get the sample from below.
  2. Try to print it.
  3. The print is misaligned.

Expected behavior I expect the print to align with the label.

Screenshots Here is a screenshot of the page setup: image

Operating system and platform (please complete the following information):

If you are reporting a print issue Here is a sample label.pdf. Which looks like this: image

Printing it results in it looking like this: IMG_20240804_104737

Pastitas commented 2 months ago

I'm seeing a similar problem in a brother ql-570, even the test print page does that, but feeding manually seems to be aligned with the labels

philpem commented 2 months ago

Which labels are you using, @Pastitas, @Flo2410 -- are they genuine Brother ones? It seems like they're not loaded into the printer correctly; this should not be possible.

philpem commented 2 months ago

The only label size which actually prints is the autogenerated custom_16.93x53.98mm, using the actual size of 17x54 mm results in the printer's power led flashing.

That's a printhead width issue, the slightly larger size is exceeding the valid printhead width (the head dots covered by the label) and is being rejected by the printer.

The exact same label works on Windows 11, printed directly via floorp.

Can you set both Linux and Windows to "print to file", zip the resulting files up, and attach them?

Flo2410 commented 2 months ago

Which labels are you using, @Pastitas, @Flo2410 -- are they genuine Brother ones? It seems like they're not loaded into the printer correctly; this should not be possible.

I'm using the Brother P-touch DK-11204 labels.

Here are the "print to file" prints. For the Linux one, I just got a PDF... My guess would be that you need something different, but unfortunately, I did not manage to get something else. files.zip

philpem commented 2 months ago

Yeah, I need the output the driver is sending to the printer, or at least a CUPS debug log to see what commands CUPS is using to generate the print output. (the log would be useful anyway - if the log level is high enough, it should include debug output about the print settings)

You might need to create a CUPS printer which outputs to a "file" URL, the details for doing that should be in the CUPS documentation.

Flo2410 commented 2 months ago

Thx, that was a good tip.

Here the cups log and the linux print file. cups.log linux.zip

philpem commented 2 months ago

Thanks, that's very helpful.

Your CUPS log level is set very low so the CUPS log isn't as useful as it could be - to change that, you need to edit your CUPS configuration and increase the log level to "debug". But ultimately we don't need it...

The print file from Linux seems ok:

00 Reset (350)
ESC @ Initialize
ESC i M 40 Various mode settings (40=auto_cut 80=mirror)
ESC i K 08 Advanced mode settings (01=draft 04=half_cut 08=nochain 10=special_tape 40=hires 80=no_clearing)
ESC i d 00 00 Specify margin amount (0 lines)
ESC i z 4e 0b 11 36 7d 02 00 00 00 00 Print information command (02=kind 04=width 08=length 40=quality 80=recover) kind=0x0b width=17 length=54 lines=637 page=first
Compression mode not specified; assuming no compression
g 00 5a Raster graphics transfer (90 bytes)
...
^Z End of job

The windows print file has a header which needs to be removed:

$ hexdump -C /tmp/windows.prn |head
00000000  3a 00 00 00 ef cd 00 00  0d 01 00 01 01 00 00 00  |:...............|

# header is 0x3A = 58 bytes, first 4 bytes of prn file

$ dd if=/tmp/windows.prn of=/tmp/windows.ql bs=1 skip=58
52661+0 records in
52661+0 records out
52661 bytes (53 kB, 51 KiB) copied, 0.123381 s, 427 kB/s

$ cat /tmp/windows.ql | ./ptexplain
Initialize command missing
ESC i z ce 0b 11 36 36 02 00 00 00 00 Print information command (02=kind 04=width 08=length 40=quality 80=recover) kind=0x0b width=17 length=54 lines=566 page=first
ESC i M 00 Various mode settings (40=auto_cut 80=mirror)
ESC i d 00 00 Specify margin amount (0 lines)
Compression mode not specified; assuming no compression
g 00 5a Raster graphics transfer (90 bytes)

...

g 00 5a Raster graphics transfer (90 bytes)
0c Print command
End of job command missing

But really all this tells us is it's not a setup command issue, because the only difference there is that Windows is enabling job recovery.

The main difference seems to be that your Linux print job has a label which is longer/wider than the Windows one (lines=637 vs. lines=566), and the Linux job has auto-cut enabled.

Reprocessing them into PNG files we can see what's going on...

$ ./ptexplain -v -i/tmp/linux.ps -wlinux_pr
$ ./ptexplain -v -i/tmp/windows.ql -wwindows_pr

Linux linux_pr1

Windows windows_pr1

Solution

If you look at page 8 of the P-Touch QL500 command reference, https://download.brother.com/welcome/docp000678/cv_qlseries_eng_raster_600.pdf, you can see that the 17x54 labels have a printable area of only 13.97 x 47.92 pixels (165 x 566 dots).

Further the margins are enforced by the printer - so by adding extra margins, you're offsetting the page.

To get a printout which matches your Windows printout, you need to create labels of this size (13.97 x 47.92 mm) with no margins.

Flo2410 commented 2 months ago

Okay... I still didn't mange to get it working...

I created a new label with a size of 13,97 x 47,92 mm and removed the margins... But it still has the same 637 lines. I don't know what I should do differently... Below, you can find my try, including a cups log with LogLevel debug2.

cups.log label.pdf printed_output.zip linux_pr1

philpem commented 2 months ago

Again unfortunately your CUPS log level isn't high enough - you need to edit /etc/cups/cupsd.conf and change LogLevel warn to LogLevel debug, then restart CUPS with sudo service cups restart.

It looks like you've set the page size in CUPS (or your application) to one of the standard page sizes - which it seems may need updating. You need to set a custom page size of 13.97 mm width, 47.92 mm height.

Flo2410 commented 2 months ago

Okay... I had the LogLevel at debug2 maybe it did not register it correctly. Here is the log with LogLevel debug cups.log

I used the default custom label size before because it's the only one which actually results in a label getting printed. Using the same label as above with the bellow print settings gives the error message: Page height (297mm) exceeds 255mm; use continuous-length tape It's pretty clear what it means, but I have no idea where the 297 mm come from...

Trying to print to the real printer, results in the power LED flashing.

The resulting print image is just a white strip. printed_output.zip

image image

Flo2410 commented 2 months ago

I just noticed that systemd was suppressing the cups log messages... So, here is a new log which hopefully includes all the info you need. cups.log

philpem commented 2 months ago

It's pretty clear what it means, but I have no idea where the 297 mm come from...

It seems like the application is overriding the page size to A4 (210x297 mm). What software are you using to print it?

I just noticed that systemd was suppressing the cups log messages... So, here is a new log which hopefully includes all the info you need.

Sadly not, the debug information about calling the filter (and the logs from the filter) are still missing

Flo2410 commented 2 months ago

I print from Floorp (Firefox browser) and Okular. From Floorp I use the Print using system dialog option, which I would assume uses the xdg-desktop-portal-gtk print dialog (See screenshots above). Okular looks like it has it's own print dialog.

I think I managed to log everything this time. At least it seems like there is more stuff in the log then previously.

cups.log printed_output.zip

philpem commented 2 months ago

Whatever you did seems to have fixed the CUPS log :)

The application you're using to print seems to be requesting a page size of 210x297 mm, or A4:

Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] Pondering option \'PageSize=Custom.595.28x841.89\'

595.28 points / 72 = 8.2678 inches 25.4 = 210 mm 841.89 points / 72 = 11.69 inches 25.4 = 297 mm.

And the print filter is seeing the same thing:

Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] rastertoptch: PageSize: 595.00x841.00 pt / 209.90x296.69 mm / 2479.17x3504.17 px
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] rastertoptch: ImagingBoundingBox: 4.32 8.40 599.32 849.40 pt / 1.52 2.96 211.43 299.65 mm /18.00 35.00 2497.17 3539.17 px
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] rastertoptch: HWResolution: 300x300dpi
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] rastertoptch: Width Height: 2479 3504
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] rastertoptch: NegativePrint: 0
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] Processing page 2...
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] printing page 1, 100% done
Sep 04 10:32:46 fwf cupsd[33651]: cupsdMarkDirty(----S)
Sep 04 10:32:46 fwf cupsd[33651]: [Job 149] Page height (297mm) exceeds 255mm; use continuous-length tape

You need to check your application settings, find the setting that's set to "A4" and change it. It might be worth printing the PDF with another application.

Edit - it seems like this could be an issue with Firefox:

Flo2410 commented 2 months ago

Whatever you did seems to have fixed the CUPS log :)

I had the --unit=cups.service flag set when calling journalctl, removing it and therefore logging everything fixed it...

I tried printing with the following command:

lp -d Test-Printer -o media=Custom.13.97x47.92mm label.pdf

Which did change the output, but the generated png still looks wrong. (I'm currently not at home and therefore cannot test it with the real printer.)

cups.log printed_output.zip

linux_pr1

Flo2410 commented 2 months ago

Okay. I tried it with the real printer, but without success.

Using the print command from above, the printer just flashes the power LED. Here the cups logs: cups.log