Bug: Dymo LabelWriter printing position error

[hameau]

Hello,

There is a positioning problem when printing directly from gLabels to the printer.

With a label in portrait orientation, the printed image is shifted down (about 6.2 mm) and right (about 1.6 mm). This offset appears to be about equal to the difference between the label PageSize and ImageableArea (ppd):

*PageRegion w102h252.1/99012 Large Address: "<</PageSize[102 252]/ImagingBBox null/cupsInteger0 0>>setpagedevice"
*PageSize w102h252.1/99012 Large Address: "<</PageSize[102 252]/ImagingBBox null/cupsInteger0 0>>setpagedevice"
*ImageableArea w102h252.1/99012 Large Address: "4.32 4.32 98.40 234.96"

In other words, gLabels seems to be placing the print relative to the ImageableArea, rather than the PageRegion (just speculation). The same problem occurs whether a label is printed from the GUI or via glabels-3-batch.

Other applications (LibreOffice, Geany, ...) print accurately to the label. If the label is first saved from gLabels to a .pdf file, this .pdf file can also be accurately printed to the label (using lpr, evince, etc.).

Use conditions:

• Debian 8 (jessie)
• cups: 1.7.5-11+deb8u1 (source: Debian repository binary)
• Printer: Dymo LabelWriter 450
  • ppd: lw450.ppd 16401 2011-10-31 18:51:16Z pineichen (source: Debian repository binary)
  • label stock: Dymo 99012 Large Address Label (36 mm x 89 mm)
• gLabels:
  • 3.0.1-4.1 (source: Debian repository binary)
  • 3.2.1 (source: compiled from GitHub release download)

[jimevins]

I am at a bit of a loss. To summarize your results, as I read them:

Action	Result
Print directly to device from glabels	offset
Print to file using glabels-batch	offset
Print to file from glabels	no offset

As far as glabels is concerned, the same code is used in all three cases, using a cairo context obtained from a GtkPrintOperation object.

I am not sure this offset is due to the ImageableArea offsets, because your vertical and horizontal offsets are quite different. (4.32pt = 1.524mm is about right for your horizontal offset of 1.6mm, but your vertical offset of 6.2mm is 4x this -- it's also not really consistent with a scaling issue)

Do you know if you see offsets with other label stock?

Unfortunately, I do not have access to a Dymo printer to test with.

[hameau]

Thanks for looking. Your summary is accurate.

In the PPD, the imageable area is not centered on the page -- the margins are not uniform. The PPD margins are set at (left, bottom, right, top; origin is bottom-left of page): 4.32, 4.32, 98.40, 234.96. The page size is 102 x 252 (all dimensions in pt).

The top margin is thus 25.4*(252-234.96)/72 ≈ 6.01 mm. The discrepancy with my estimate of about 6.2 mm is easily accounted for by the way the labels feed through the print head and the registration between the labels and the release paper (the latter carries the form-feed registration marks). However, I have tried adding a new paper size definition to the PPD, with minimal (1.0 pt) margins all round, and that displays the same offset. I have no other label sizes for this printer, unfortunately, but the imageable area seems to be a red herring.

I have two other printers, but both are A4 sheet-fed and the hard margins are between 0.0 mm and 0.89 mm -- a tiny percentage of the page size.

The Dymo printer is a recent acquisition, with no customising of the print flow, so I don't think that I have introduced anything.

One observation is that LabelWriter default setting in CUPS has the paper size set for the loaded label stock. The print dialog in gLabels shows a paper size of 'Other' (greyed -- cannot be changed), but when printing from evince, the paper size defaults to the correct named stock (and can be changed); similarly, printing via lpr uses the default paper size. Is there anything of value here?

Attached are two files, taken from the CUPS print cache (.pdf extension added to satisfy GitHub attachment rules): *-good has no offset, printed via gLabels -> PDF -> evince -> print queue; *-bad has the undesirable offset, printed directly from gLabels -> print queue

If I open the bad file in evince, it prints correctly from there without the offset. If I reprint the bad file from CUPS admin, it still has the offset. I'm now lost.

d00093-good.pdf d00094-bad.pdf

[jimevins]

Can you try the following attached template file out?

test-dymo-templates.xml.txt

Remove the '.txt' extension and copy it into ~/.config/libglabels/templates/

It contains two Dymo templates 99012-test1 and 99012-test2. Can you let me know if either works any better than the default template?

[hameau]

Results are identical with all three templates, 99012 (distributed), 99012-test1 and 99012-test2. (I have also tried with the redefined Dymo template file recently committed to master – no different.)

[hameau]

I have tested with a live-cd of Linux Mint 17.3 and the problem doesn't exist there, so it seems to be Debian-specific. The problems shows in two separate installations of Debian Jessie (one completely clean), each with direct USB connection to the printer.

If you have any suggestions for further troubleshooting, I'm all ears, but I guess this can be closed for gLabels.

[Dutchglory]

Hey:

I have "Dymo LabelManager PnP" with standard D1 (1/2") label http://www.dymo.com/en-US/labelmanager-pnp-label-maker

On (openSuse) Linux... where are new templates saved when i create one...?? want to create a new one and delete the old one....

screenshot: https://cloud.githubusercontent.com/assets/461485/14759901/9cd71afc-0933-11e6-8e75-3a9ae91dadcb.jpeg

thanks André

[jimevins]

Custom product templates are stored at

~/.config/libglabels/templates/

You can also edit/delete any custom product templates in the new label dialog under the "custom" tab.

[nmz787]

is there a workaround? gLabels just keeps printing blanks for my Dymo LabelManager PnP

[varac]

Same here, ubuntu 19.10, glabels 3.4.1-1.1build3, a Dymo LabelManager 420P with this Dymo_D1_19mm.template.txt.

In glables it looks like this:

But the printed label is offset like this:

[ddoherty03]

I would like to upvote getting this figured out. I have a Dymo LabelWriter 400 Turbo, and I use it to print file folder labels. The print from gLabels is shifted down. I tried a custom template, and it is not printing anything. I really want this to work! Thanks for glabels.

[hameau]

@ddoherty03 I'd strongly recommend trying glabels-qt (where future development effort will go). It's very usable, even though there is no official release, and most of my problems with the Dymo printer are resolved.

I'm using the AppImage package on Debian 10.

[ddoherty03]

@hameau, thanks for pointing me to glabels-qt. I have installed it via the Ubuntu PPA, and it looks really nice. I am still having a problem with the placement of the text on the label, though.

Just for the record, here is what I get printing to a Dymo LabelWriter 400 Turbo on Ubuntu using the cups driver.

Here is a label in the Designer View from glabels-qt, which looks perfect:

And here is what it looks like when printed:

And here is the Cups Test Page:

[LeoKogan]

Hello I have the same problem. I was trying to offset the printer some how adding a negative value but is not allowed.

[ddoherty03]

@hameau, @jimevins: It occurred to me that I have an extra Dymo LabelWriter sitting around. I could mail it to you if you would be willing to use it for testing this issue. Any interest?

[sur5r]

Since this is a long-standing issue for some users and seems related to Debian: Can anyone try and reproduce it with a current Debian bullseye (soon to be released as Debian 11) installation?

I'm using glabels with a LabelWriter 320 and Labelwriter Duo without any issues. I doubt the 400 Turbo will make any difference.

[ddoherty03]

@sur5r, Yes. Or let us know about non-debian distributions or bsd distributions. This is irritating enough I would consider changing from my long-standing use of ubuntu to solve it.