Open sschueller opened 1 year ago
I can confirm similar behaviour with a clone "XP-490" roll printer, on glabels v3.99 on Ubuntu from 20.04 to 23.04
I'm suspecting there's an issue with a loop, or a nested loop, that's walking through the selected merge list improperly.
Here's the behaviour I saw on my setup, so that it can be reproduced, and perhaps, the bug can be found and squashed.
1 selection in the merge list: 1 label
2 selections in the merge list: 3 labels
3 selections in the merge list: 6 labels.
first is properly printed
The bug is such that many labels are both over-rendered (ergo, not useful), and over-printed... geometrically.
In the Print Preview, it only shows the "N" selections, not the higher count of actually printed / over-rendered labels.
Hope this helps clarify the issue, so the offending code can be sleuthed out and a fix applied.
I have the same issue when I print a PDF now without using glabels so I think it may actually be something in the xprinter filter. I am currently trying to find another way around that filter since it's closed source.
I have a very odd phenomenon on my "cheap" Chinese label printer when using glabels with merge. Individual labels printer perfectly.
When printing a merge regardless if I select to print 1 or all I get the number of rows in the CSV. So for example I want to print the first 5 out of 14 it will print 14 labels but each label stacked on additionally. So in evanescence first label is ok, second label has the first and second label on it, third label has first, second and third on it and so on.
I have the following setup:
If I reduce the CSV to 2 rows (no header), the printer will print 3 labels, also stacked. Selecting only one row in the merge window will print just that one label correctly.
Template
csv
ppd
Any ideas what could be wrong?