Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect label rotation when printing. #46

Open
petemate opened this issue Jan 15, 2019 · 19 comments
Open

Incorrect label rotation when printing. #46

petemate opened this issue Jan 15, 2019 · 19 comments

Comments

@petemate
Copy link

When I print a label, the label frame isn't printed correctly on the printer, a Dymo Labelwriter 320.
I have experienced this in the following versions:
gLabels 3.0.1-4.1(From repository)
gLabels 4.3.1 (Downloaded from glabels.org)
gLabels Continuous appimage(downloaded from github).

Please see attached photo of labels(Dymo 11354) produced with both horizontal and vertical orientation. The labels are produced with the continuous app image, but the same behavior is present in all versions mentioned above. The label rotation is always 90 degrees off. The thick box is a box that I have drawn on the label, while the thin box is created with the "print outlines" setting in the print menu.

Its clear that the text is being rotated correctly, although it is also reversed. But the actual "frame" of the label seem to always be vertical, as indicated by the outline box.

20190115_222556_exif

I have experimented with printer settings(auto rotate, keep orientation, 180 degrees, 270 degrees), but that doesn't change anything.

In the beginning, I thought the issue was incorrect custom label creation(Label 11354 isn't included in 3.01 and 4.3.1, so I had to create it myself), but regardless of how I did it(e.g. switching around height and width), the prints are always rotated to a vertical position.

I can verify that the printer prints correctly by printing from a custom size paper(with the dimensions of the label in landscape mode) in Libre Office Writer, as seen in the following screenshot. This leads me to belive that it is something in the commands from gLabels to the printer, that causes an issue.

20190115_225556_exif

My computer setup is Linux LMDE(LMDE 2 Betsy, 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64 GNU/Linux) and the drivers for the printer are the Dymo CUPS Drivers for Linux(v. 1.4.0-5). The printer itself is shared on the network using an OpenWRT-based router. I am able to print correctly to the printer using the official Dymo software(tested on a macbook).

Please let me know if you need any more information from me. I will be happy to provide it, if at all possible.

Thank you for your time.

@jimevins
Copy link
Owner

I don't have your exact combination, but the following combination is working for me: Dymo LabelWriter 450 Turbo with Dymo 30252 address labels:

20190115_195831

I am using Ubuntu 18.04. I am not sure what drivers are being used -- I just plugged in the printer and it just works -- I don't even have the printer-driver-dymo package installed, although 1.4.0-8 is in the repo.

My guess is that the print area in the template does not match the actual print area and the drivers are automatically rotating to try to fit it. You wouldn't happen to have access to any 30252 labels to see if that template works for you?

@petemate
Copy link
Author

Hi, I had some dymo 99010 labels that I used for testing. They are apparently the metric version of 30252, so the results should be identical(apart from the fact that I didn't load the labels correctly, causing some offset to the print):

20190117_173419-exif

From the following two labels:

screenshot from 2019-01-17 17-37-47

screenshot from 2019-01-17 17-37-37

So printing works indeed correct on labels with that kind of format(ie smaller width than height), but I'm still not clear on the issue with labels with wider width than height. However, I did discover an issue:

  1. The 11354 are created as 32x57mm. I belive they should be 57x32mm, since the 30252/11010 labels are created as 28x89 mm, and not 89x28 mm. That is, if 11354 was 32x57mm, it should be rotated 90 degrees on the roll. Its a bit confusing, but I would argue that width of the label is the width that it takes up in the printer, while height is the "length" of the label on the tape(that is, in the direction that the printer spits it out). That is, the "dimensional ratio"(width/height) should be smaller than 1 for 30252/11010)(28/89), while it should be larger than one for for 11354 (57/32).

  2. Try printing a PDF of a 99010 label in horizontal and vertical orientation. You will get two PDFs that look exactly the same(provided that you rotated the text):
    horiz-99010-portrait.pdf
    vert-99010-portrait.pdf

The label is printed correctly and has correct page size(if one assume that the paper should exit the printer in the "height" direction).

Now try printing two 11354 labels from gLabels template(32x57):

horiz-11354-portrait.pdf
vert-11354-portrait.pdf

The label now has correct page size and orientation(if the PDF printer is printing in "portrait"), but the text is rotated 90 degrees "out of the page" in both instances.

Now try creating a copy of the 11354 template, but with 57x32 dimensions(as argued in 1), this should be the correct dimensions):

horiz-11354(copy)-portrait.pdf
vertical-11354(copy)-portrait.pdf

In the PDFs, the label has the same "dimensional ratio" as 30252/11010, which I believe is incorrect, since its rotated differently on the label roll. For the horizontal orientation, the text is correct, but cut off due to the incorrect width of the page. For the vertical orientation, the text is now 180 degrees rotated, which I don't get. In any case, it should only be rotated 90 degrees, right?

Its almost as if the text is rotated differently, with regard to the "dimensional ratio". Could that be the case?

@jimevins
Copy link
Owner

So printing works indeed correct on labels with that kind of format(ie smaller width than height), but I'm still not clear on the issue with labels with wider width than height.

I'm having the same thought.

I would argue that width of the label is the width that it takes up in the printer, while height is the "length" of the label on the tape

This is exactly correct.

The 11354 are created as 32x57mm. I belive they should be 57x32mm, since the 30252/11010 labels are created as 28x89 mm, and not 89x28 mm.

These templates were user submitted and I have never tested them. I have only tested the 30252. I was having strange issues when trying to test the 30915, but ran out of the sample labels that came with the printer. Last night I went on amazon and ordered a few different sizes, including the30334 which I believe is the US version of the 11352. I should have these in the next couple of days and should be able to do some additional testing/debugging.

@petemate
Copy link
Author

Let me know if I can do anything to help out!

@jimevins
Copy link
Owner

Can you attach the Libre Office document that worked for you?

@petemate
Copy link
Author

Here you go.

label_11354.odt.zip

This is what the file produces, when sent straight to the label printer:

20190120_170520

@jimevins
Copy link
Owner

jimevins commented Jan 25, 2019

Okay. It's been quite a journey.

  1. I updated the product template for the correct values for height and width as discussed above.
  2. I removed an artifact from the PageRenderer from when I was battling what I believe to be the same issue when working on the Dymo 30915 postage stamp template.

I continued to have the same problems on my Ubuntu machine. However, it worked perfectly on a Windows 10 box. Finally, after many dead-ends, I decided to install the printer-driver-dymo-1.4.0-8 package and re-configured the printer and selected the correct media size. Now the corrected template above works correctly on my Ubuntu machine.

Long story, short: try the current snapshot of glabels-qt. I think it should now work correctly for you as long as you are using the correct driver and media size -- which I think you were doing -- I wasn't which compounded the issue. I think the problems were due to the reversed height and width in the old template plus the bad code in the PageRenderer.

@petemate
Copy link
Author

Hi, I just had a try with 3.99-snapshot(ff9188f 2019-01-28).

I'm sorry to report that it still doesn't work. Pinting "horizontal" and "vertical" will still produce content rotated 90 degrees clockwize on the label.

Here are my print settings:

screenshot from 2019-01-29 21-01-56

screenshot from 2019-01-29 21-02-16

screenshot from 2019-01-29 21-02-20

One odd part that I noticed is that if you use the printing dialog in g-labels and then press "properties", it shows different page sizes - but I can't select any. The field is always greyed out:

screenshot from 2019-01-29 21-02-43

(I have tried both portrait and landscape settings available in the screenshot above. It doesn't produce any changes)

@githuberTraderGrim
Copy link

githuberTraderGrim commented Jan 30, 2020

I am having this same issue. I am using a previously created .glabels file and data file. Thes files previously printed correctly but now they print rotated. When I try to rotate them they (I believe) retain the formatting of the label data but send it incorrectly to the printer. It is possible it is a printer issue but it prints correctly from other applications, including a pdf file created from these (.glabels & .csv) files. Just tried printing the erroring file(s) to pdf, that works correctly and the pdf prints correctly but printing to ANY actual printer, label printer or regular paper printer, prints the rotated messed up format labels. The preview on the printer job looks correct but prints rotated. I can only get this to happen in Glabels. Otherwise the printers all work correctly.

@githuberTraderGrim
Copy link

Just want to separate this work around from my last post. If you are having this issue print to a PDF before printing the labels. That will work until a developer looks into this and fixes it.

@jimevins
Copy link
Owner

I am having this same issue. I am using a previously created .glabels file and data file. Thes files previously printed correctly but now they print rotated. When I try to rotate them they (I believe) retain the formatting of the label data but send it incorrectly to the printer. It is possible it is a printer issue but it prints correctly from other applications, including a pdf file created from these (.glabels & .csv) files. Just tried printing the erroring file(s) to pdf, that works correctly and the pdf prints correctly but printing to ANY actual printer, label printer or regular paper printer, prints the rotated messed up format labels. The preview on the printer job looks correct but prints rotated. I can only get this to happen in Glabels. Otherwise the printers all work correctly.

I assume this is also on Dymo LabelWriter? Also, you say that you previously created this file -- can you try creating one from scratch with the current version of glabels and its templates?

@githuberTraderGrim
Copy link

It took me a lot of time to do this in the first place, I don't have time to redo it. I use this for work. This file pair has been working for 2 years until today. I am not using a dymo, it fails on Zebra label printers, Canon inkjets, an HP LaserJet, and a Lexmark laserjet. Works to printing to PDF. Ubuntu 18.04 up to date today.

@githuberTraderGrim
Copy link

githuberTraderGrim commented Jan 31, 2020

FWIW, the last time I printed this file was on 1-19-2020. IIRC the system was up to date that day also, so it is something that changed in the last 10 days in the official Ubuntu repositories.

@githuberTraderGrim
Copy link

Here are a file pair that are failing. All my files are doing the same thing on any printer.

location.csv.txt
location.glabels.txt

@jimevins
Copy link
Owner

This file pair has been working for 2 years until today.

What version of glabels are you using and has stopped working? This repository and this issue are for glabels-4 (i.e. glabels-qt version 3.99+). If you are using glabels 3.4.1 or earlier, this was released in April 2018 -- nearly two years ago. There have been no changes to it since. Any sudden changes in behavior would not be due to changes in glabels.

I printed your label and it prints exactly as it appears in the print preview. It is not laid out very well due to the conversion to the glabels-4 format.

@zyphlar
Copy link

zyphlar commented Jul 31, 2020

I'm having a similar issue, when I print vertical labels from PirateShip on 2x7 they come out fine, but using these return address labels I think the driver is auto-rotating them because the only way I can get a "good" orientation (text along the wide axis, landscape style) is to make a label in gLabels that is in portrait mode... which then prints only on the left half of the label. It's as if trying to print something in landscape is automatically detected as wrong and auto-rotated by the driver or device to be portrait. But I don't think this is a gLabels issue, I think it's a print driver issue. My print driver settings also don't have an "automatic rotate" option, just a landscape, portrait, and reverse landscape/portrait orientations.

Edit: I finally got decent prints by uninstalling/reinstalling the printer, and then making a custom label that was 2.25" wide by 2.5" tall. During the reinstall I now see the "automatic rotate" option, but what seems to be happening is that all labels are assumed to be portrait and force-rotated so that the longest dimension is along the length of the tape. But labels that are (slightly?) "too wide" for a given label just get cut off and don't print onto a second label, so I'm able to get text oriented the right way and filling the 2.25x1.25" label and the rest of the 1.25" extraneous portion is just "cut off."

@MichaelMichaelMichaelMichaelMichael

Same effects here: horizontal/vertical rotation messed up, there is no way to get the printout right.
Label: 11354, glabels version 3.99-unknown? (exported 2021-02-07)

@IhanaOlli
Copy link

IhanaOlli commented Jul 20, 2021

I had exactly same problem when printing to a label type 11354. I think that this is a driver issue and not releated to gLabels. Same problem exists when printing from LibreOffice for example.
I was able to fix this by adding that paper size to ppd (attached, rename to ppd extenson) file and then choosing Dymo11354 from Printer properties dialog. Please note that printable area used in this ppd file might not be 100% correct but it works, for me atleast.

LabelWriter-400-2.txt

@thomaskr
Copy link

Fixed the problem on Ubuntu 20.04 by installing printer-driver-dymo, going to the CUPS web interface (localhost:631) and changing the driver. The generic driver seems to be buggy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants