Custom Sizes not supported on printers that use rastertolabel as a backend.

[cvergaray]

Printers that use rastertolabel, i.e. Zebra, Brother, and Dymo printers do not respect the custom size provided by the application, so they will always print with the default size when a custom size is provided.

rastertolabel determines the label size from:

• The CUPS Raster header (width/height in pixels)
• The printer’s DPI
• The printer’s firmware defaults
  It does not read:
• PageSize=CustomPageSize
• cupsWidth
• cupsHeight
• IPP media values
  So attempts to set custom size via CUPS options always fail.

There are four options to fix this:

1. Don't fix it. When a printer does not support print-time defined page sizes, automatically switch between printer-defined sizes to find one that fits the generated content (i.e. for continuous media). I probably will implement this as a fallback for those that don't want to deal with lprint.
2. Use raw queue and send printer-specific commands (i.e. direct ZPL when communicating with a ZPL printer.) The idea behind using CUPS in the first place was to get away from vendor lock-in. This would make it difficult to maintain for every printer. Additionally, raw queues are being deprecated in CUPS per this announcement: https://openprinting.github.io/cups/drivers.html
3. Patch rastertolabel. Doubt this is going to happen, especially given that it is no longer maintained as it was replaced with LPrint.
4. Use LPrint. It is unclear if this driver supports custom, self-described sizes. The documentation suggests that it does, but I have not tested this. I had trouble getting it working when I threw it on a pi print server.

[cvergaray]

I believe this is the issue experienced by the user in this thread:

https://www.reddit.com/r/grocy/s/uVA4INiMc2

[phantom101]

Hi,

Have also an brother printer and can't fully confirm that, though.
(if i look at the reddit post ..)

To the Reddit Post:
They respect the "Custom Sizes" but with a little twist ...

In my opinion:
Label Web and Cups both do what they should do.

Cups defines the label size available in the printer. This size should not be changed by Label Web, as other applications might also access the printer and should also not necessary because why define a other label size then real loaded size ...
In short, Cups defines the maximum hard limits we have.

Label Web defines a label size in the app, but this is more of an internal value used for calculations. Ideally, the size should correspond to the actual label size (Cups).
In short we define our playground for calculations.

So to this point everything works fine and the label size in Label Web matches the Cups size :-)

The problem (that i also noticed) starts when Label Web sends rasterized data like the grocy code image to the printer.
Here we face a DPI mismatch. The printer is interpreting and printing rasterized elements with its own DPI settings.
So the rasterized elements break out.

Label Web rasterize and so calculate everything with 203 DPI and my brother printer rasterized elements with 300 DPI

If i want to a print code size around 13mm high at 300DPI i would set about 150px
But if i set 150px it would be rasterized in label web to 203 DPI und later rasterized again by the printer at 300DPI
Real Outcome is a 9mm Code high on the label.
So the real printed outcome is at 1.41 scale what means if i take the 150px value it has blown up the calculated DPI to ~423 DPI

So we have a raster problem in the first step ...

What lead to rastertolabel und cups raw queues being deprecated:

The simplest solution would be using direct IPP without a additional print tool like LPrint in between.
(LPrint also only support a defined range of printers ...)
100% of the actual printers now days support IPP and many company's made also ipp drivers for their older models ...

If someone have very old or special pinter without ipp maybe they find a IPP -> Printer solution.

Also Cups say: Printers supporting the various Internet Printing Protocol (IPP) “driverless” printing standards will continue to function without change.

Option 1:
Raster the whole label at the same dpi as the printer prints so the sizes match.
Send the label image directly to the printer if the printer has an build in ipp server. (zb. brother)
http://<printer_IP>:631/ipp/print

Option 2:
Print the lable image over cups with the ipptool.
Raster the whole label at the same dpi as the printer prints so the sizes match.
save it as lets say lbl.jpg
ipptool -tv ipp://cups-ip-address:631/ipp/print lbl.jpg

Option3:
A little bit tricky but i think the most solid solution
Print over cups and ipptool with an .pwg file
Raster the whole label at the same dpi as the printer prints so the sizes match as lbl.pwg (script like ImageMagick)

Make an .test file like:
`{
OPERATION Print-Job
GROUP operation-attributes-tag
ATTR charset attributes-charset utf-8
ATTR language attributes-natural-language en
ATTR uri printer-uri ipp://ups-ip-address:631/ipp/print
ATTR name requesting-user-name user
ATTR mimeMediaType document-format image/pwg-raster

GROUP job-attributes-tag
FILE /path/to/lbl.pwg

STATUS successful-ok
STATUS client-error-document-format-not-supported
}`

Print with:
ipptool -tv ipp://cups-address:631/ipp/print print-job.test

That would also mean that a large part of Label Web's core functions would no longer be needed. So, moving away from a true printing solution towards one that focuses more on design and templates.

Maybe a good chance for an clean restart of the project ?

[cvergaray]

There are a few issues with your analysis:

This size should not be changed by Label Web, as other applications might also access the printer

Print-time defined sizes are a standard feature of printing with CUPS. From the CUPS Manual:

When Custom is listed for the PageSize option, you can specify custom media sizes using one of the following forms:

lp -o media=Custom.WIDTHxLENGTH filename
lp -o media=Custom.WIDTHxLENGTHin filename
lp -o media=Custom.WIDTHxLENGTHcm filename
lp -o media=Custom.WIDTHxLENGTHmm filename

where "WIDTH" and "LENGTH" are the width and length of the media in points, inches, centimeters, or millimeters, respectively.

We are not adding a media size, simply telling the printer to use a custom one-off size.

and should also not necessary because why define a other label size then real loaded size ... In short, Cups defines the maximum hard limits we have.

This is true with die-cut labels, but not with continuous. If you have a continuous label, then only one side of the media is fixed width, the other in arbitrary. The way that CUPS defines sizes are fixed. So the only way to support continuous label sizes with CUPS is the custom size described above, which is not supported by printers that use rastertolabel as a backend because rastertolabel does not use the custom size definition.

Label Web defines a label size in the app, but this is more of an internal value used for calculations. Ideally, the size should correspond to the actual label size (Cups). In short we define our playground for calculations.

This is only partially correct. The label size defined in the app is supposed to correspond to the actual label size. Unless you are exclusively defining your own custom size, which should match what is loaded in the printer, then the size is pulled from CUPS. That's the point of the media_name_to_dimensions code that translates CUPS defined sizes to the pixel values used in labelweb2

The problem (that i also noticed) starts when Label Web sends rasterized data like the grocy code image to the printer.

A key clarification: The entire label is rasterized. Label Web generates an image file called sample-out.png and then sends that rasterized image to the printer:
conn.printFile(printer_name, 'sample-out.png', "grocy", options)
It's not just the grocycode that is rasterized, everything is.

Here we face a DPI mismatch. The printer is interpreting and printing rasterized elements with its own DPI settings. So the rasterized elements break out.

Label Web rasterize and so calculate everything with 203 DPI and my brother printer rasterized elements with 300 DPI

Label Web retrieves the DPI from the printer. 203 is the fallback value if the printer is not reporting it's DPI in CUPS or it otherwise can't be retrieved. If you have your printer set to 300 and it's using 203, then this is a separate issue. Please open an issue for it. It would make sense to allow the user to configure the fallback DPI on the config page, but I would like to know why your printer isn't providing it's DPI. Maybe that's a brother print driver thing. I made this tool because I didn't want to use a brother printer, but I may need to get one to test with.

The simplest solution would be using direct IPP without a additional print tool like LPrint in between. (LPrint also only support a defined range of printers ...)

LPrint and CUPS are both IPP endpoints. What I meant by Option 4 in the initial issue was to switch to IPP and allow connecting to whatever IPP server you want (be that CUPS, LPrint, or in the case of networked printers, the printer itself). LPrint is CUPS for label printers and it supports continuous media, so to address the issue described here, Custom sizes not supported on printer that use rastertolabel, I want to explore LPrint as it is the official CUPS replacement IPP tool for label printers.

If someone have very old or special pinter without ipp maybe they find a IPP -> Printer solution.

All of my printers are fairly old. My newest printer is from 2012. I used this software every day with a printer from 2002 and have tested it with printers that were even older. That is why I made it: So that really old (that is to say cheap and easy to come by) printers would be supported. CUPS and LPrint are IPP -> printer solutions. If neither of those work, there are others. But, from what I've seen CUPS works fine for die-cut labels even with really old printers.

Option 1: Raster the whole label at the same dpi as the printer prints so the sizes match. Send the label image directly to the printer if the printer has an build in ipp server. (zb. brother) http://<printer_IP>:631/ipp/print

i.e. option 1 is use generic IPP instead of CUPS specific. As mentioned earlier, labelweb already rasters the entire label at the same dpi as the printer, assuming the printer reports the DPI (again, separate issue, please make a separate issue for it)

Option 2: Print the lable image over cups with the ipptool. Raster the whole label at the same dpi as the printer prints so the sizes match. save it as lets say lbl.jpg ipptool -tv ipp://cups-ip-address:631/ipp/print lbl.jpg

This is quite literally exactly what Label Web is doing right now, except with lp instead of ipptool because ipptool is a test harness built into CUPS.
The DPI issue is separate from what this issue is getting at. Please don't conflate them and hijack this issue for something unrelated.

Option3: A little bit tricky but i think the most solid solution Print over cups and ipptool with an .pwg file Raster the whole label at the same dpi as the printer prints so the sizes match as lbl.pwg (script like ImageMagick)
...
That would also mean that a large part of Label Web's core functions would no longer be needed. So, moving away from a true printing solution towards one that focuses more on design and templates.

Maybe a good chance for an clean restart of the project ?

If you want to fork and do a clean restart, by all means, go ahead. But all of your solutions are attacking a different problem (DPI mismatch) than what is described in this issue (custom media sizes, i.e for continuous labels).
Please open an issue describing the DPI mismatch you are experiencing. If possible include your config.json (feel free to redact anything you don't want publicly available.)

I agree that switching to generic IPP rather than the CUPS implementation of it would make labelweb more flexible, allowing it to attach to CUPS, LPrint, IPP-Enabled Printers, or any other IPP implementation. So, that is the approach I have been investigating and will probably move forward with. But, I have a few more printers to set up so that I can have a wider testing pool before I can commit to any COA.

[phantom101]

Print-time defined sizes are a standard feature of printing with CUPS. From the CUPS Manual

We are not adding a media size, simply telling the printer to use a custom one-off size.

True and that is what i mean ... we mix real printer with app "playground" settings/sizes what can lead easy to issues like the rastertolabel problem and DPI missmatch.

This is true with die-cut labels, but not with continuous. If you have a continuous label, then only one side of the media is fixed width, the other in arbitrary. The way that CUPS defines sizes are fixed. So the only way to support continuous label sizes with CUPS is the custom size described above, which is not supported by printers that use rastertolabel as a backend because rastertolabel does not use the custom size definition.

I also use continuous label.
Exactly here is the problem we tell the printer a custom size if the printer not support it (rastertolabel ) or a other setting is off like dpi we ran into a problem. (Mix printer with app settings)

But its absolut not necessary to tell the printer a custom size even with continuous label.
The Printer could everytime set to full label width or width/height for die-cut labels.

The real label size would be automatically set by the size of the generated rasterized image we send to the printer.

Yes rastertolabel and dpi missmatch are two different stories but in my opinion, they originate from the same source

Let me explain on the cases and start with the easier to explain

DPI mismatch:

Now:
Set a label size for the Printer.
Create the content.
Rasterize only the content
Send only the rasterized content along with the labelsize setting to the printer.

Problems:
If the printer dont take the lable size we ran into a problem.
If the app dont get the dpi info from the printer the label size is correct but the content is off (dpi mismatch /dpi fallback)

Better:
Set the a label size along with offset point and printer dpi in the settings (no interaction with the printer)

Something like:
Size: 200px*150px
v_off: 5
h_off: 5
dpi: 300

Create the content

Rasterize the full label not only the content in this case a full 200px*150px image @ 300 dpi (So offset + content ..)
Send the full label image to the printer.

In this case the Printer would print the label in the correct size (height/width) .
Content position (startpoint) on the lable is set by offset.
Offset could also help to position die-cut labels if the printer not do it automatically.
Continuous label dont matter because the printed size is the label size.
Cutting on continuous label also work manual or when auto cutting after content is active.
Maybe also add a bottom space setting so we can set also a bottom space for cutting ...

There can be no dpi mismatch because the full image was generated at the specified printer dpi.

** rastertolabel problem:**

In this case we run into the "If the printer dont take the lable size" problem.

If we look at the rastertolabel code:
https://github.com/apple/cups/blob/master/filter/rastertolabel.c

1) The filter takes the page/raster size directly from the raster header.
For each page, a CUPS raster header is read (cupsRasterReadHeader2), and then exactly header.cupsBytesPerLine bytes are read per line.

The loop runs exactly until y < header.cupsHeight.

This means: height = cupsHeight, and the output data width per line = cupsBytesPerLine (thus indirectly also the width = cupsWidth, depending on the bits/pixels and packing/DPI).

2) There is no point that recalculates/interpolates/fits pixels to the page.
OutputLine() writes the read bytes practically 1:1 into the respective printer language (DYMO/Zebra/CPCL/PCL…), e.g., fwrite(Buffer, ..., header->cupsBytesPerLine, ...). No conversion to a "label size" takes place.

Summarized:
rastertolabel takes no special label size settings and its not necessary because it prints the raster input 1:1
This mean if we send a full label image instead content along with size settings like explained above we dont run into that problem and the label would be printed in the correct size.

All in all:

Yes they are two different cases but can be solved in one change ...
I would be easier and avoid many such problems when we separate printer and app settings by simply send a full label image. Instead of only content along with size settings which the printer can then interpret correctly... or not.

[phantom101]

Okay, a small oversight on my part: most print apps support auto-scaling based on media size. CUPS doesn't by default :-( but i am sure to find a solution for that too.