Adding "DYMO LabelMANAGER PC II" support (help requested)

[FaBjE]

I was trying to see if I can get my DYMO LabelMANAGER PC II to work with Labelle.
I saw that the "DYMO LabelMANAGER PC" is supported, so I gave it a shot.

It is not supported out of the box, but when adding the following line to constants.py:
0x001C: "DYMO LabelMANAGER PC II",
and setting up the udev rules, the printer is detected and I can print a label!

But...

The text is not aligned correctly. It is printed too much downwards. (the bottom part falls of the label) I think this is because it is a 24mm tape printer.
I did some digging around and found these lines in dymo_labeler.py

    LABELER_DISTANCE_BETWEEN_PRINT_HEAD_AND_CUTTER_MM = 8.1
    LABELER_PRINT_HEAD_HEIGHT_MM = 8.2
    SUPPORTED_TAPE_SIZES_MM = (19, 12, 9, 6)
    DEFAULT_TAPE_SIZE_MM = 12`

I added SUPPORTED_TAPE_SIZES_MM = (24, 19, 12, 9, 6) and can print a correctly aligned 24mm label!
But the 12mm sizes are still not aligned correctly.
Changing LABELER_PRINT_HEAD_HEIGHT_MM to 24 did not fix it.

My questions:

• How do I vertically align the text on the smaller tape sizes?
• How do I add these changes without breaking other printers?

My python knowledge is next to nothing, so patient please :)

[maresb]

That's amazing @FaBjE, thanks so much!!!

How are you with Git? Would you like to open a pull request with your proposed changes? That would help with the discussion.

For a very extensive discussion on vertical alignment, see computerlyrik/dymoprint#80.

[FaBjE]

Thanks for the link! I will do a read...

GIT and PR's are no problem. I though I should ask for some directions before starting.
I'll open a PR for this if I'm up to speed

[maresb]

Great, let me know if you have any questions.

[FaBjE]

@tomek-szczesny Continuing here. (Maybe its better to close the old issue)
Recap from the other issue:

I've got a "working" setup, working on the alignment now.

I've printed the test-pattern a couple of times on the largest 24mm tape:

It seems that the hardware printhead has 128 pixels.

The to-do for me is to print this test pattern on smaller tape sizes.
Question: I've used the --tape_size_mm=24 --sample_pattern=X "X" to print it on 24mm tape. How do I invoke the command for smaller tape sizes? Do I keep it the same and see what will be printed, or do I need to set the tape size to the smaller sizes?

I don't mind buying a couple of smaller tape rolls. I already have 9mm and 12mm. Maybe if I buy a 6mm it will come in handy to have all "edge cases". (They are not that expensive and I'm sure it will come in handy one day)

Sidenote: I already did some "alignment" on the original windows software. The original old software was pretty crappy at aligning smaller smaller labels for this printer. They keep insanely huge safety margins to compensate for misalignment. So I defined a couple of 24mm label templates with margins set to match the smaller tape sizes. Unfortunately the settings make no sense to me regarding the input we need now.
What I can say is that the smaller tape sizes are "centred" relative to the 24mm tape. aka: it just prints in the middle.
Any inconsistencies with that were either caused by not putting in the tape cartridge correctly or the tape cartridge itself having a defect in some way.

[tomek-szczesny]

For smaller tape size test prints, use the 24mm setting - after all this is the most raw output we can get. That is 128 dots in your case.
Based on the scan of these sample prints we should be able to come up with the LUT parameters for all tape sizes.
IIRC the LUT parameters are: bottom side padding and total print height, in dots.

There was some debate about the print cartridge alignment in Dymo printers that go >12mm and since I don't have one I can't tell really. If you're sure you install cartridges correctly then I see no point in debating that any further.
One thing is sure: 6,9 and 12mm tapes are center aligned with each other because their housings are of the same size.

[FaBjE]

Here is the same test-pattern on smaller tape(s). I stuck it on a black piece of cardboard to be able to see the white-on-transparent tape. (so look at the white pieces, not the black!) They look a bit sharper in person but it's hard to get a decent scan.

For your reference, here is a series of tapes aligned how they would sit in the printer. You are indeed right on the cartridge side.

Is this enough information? I can order some tape from AliExpress, but it will take some time to arrive.

[maresb]

That's excellent information!!!

From the 12mm tape, I can see by overlaying on the 24mm printout that there are 23 pixels missing from the top (the 12mm tape printout starts below the gray segment):

and also 23 pixels missing from the bottom (the 12mm tape printout starts above the topmost gray blocks):

(Note that the dyadic squares pattern is all-white along the last row, which is a bit confusing.)

Thus the 12mm tape has 82 printable pixels and is centered.

From the 9mm tape (with inverted colors), there are 37 pixels missing from the top (the 9mm tape printout starts below the gray segment):

and 27 pixels missing from the bottom (the 9mm tape printout starts above the gray strip):

Thus the 9mm tape has 64 printable pixels.

EDIT: Summary: 9m has 27 pixels below + 64 printable pixels + 37 pixels above, 12mm has 23 pixels below + 82 printable pixels + 23 pixels above. (128 = below + printable + above = 27 + 64 + 37 = 23 + 82 + 23.)

[tomek-szczesny]

If I remember correctly, offsets as defined in LUT were the distance from the lower side.
@maresb has just produced all the necessary numbers. :)

I remember that I added +2 to the offset and subtracted -4 from the printable area width to compensate for minor misalignments.

I also remembered that print area on those tapes is limited by the coloring ribbon size, which also may vary across manufacturers.

Yay, that test pattern actually works in the field. My humble contribution :)

[FaBjE]

@maresb Thanks for your analysis!
@tomek-szczesny You are right about the colouring ribbon. it is also not/never perfectly aligned with the backing tape so you can easily miss the edges.
and yes it your test-pattern works great! it was really easy for me to make the prints and (I guess) for you to do the analysing.

Speaking about contributions, can somebody point me to the lookuptable in the sourcecode?
I don't see it...

I can find it in this old PR of the obsolete repo: computerlyrik/dymoprint@c9ff02d#diff-a5f5b75891a528e1eec31586669a127c0ee4ea76e8d5ffbcb5263e95f6f8e1e2
But it is never merged?

[maresb]

@FaBjE, you're correct that the PR was never merged. While the idea was correct, the old code was tied up in knots, and the lookup table couldn't be properly implemented. Thanks to @tomers's epic effort, the code is in much better shape, but it still remains an open task to reimplement @tomek-szczesny's lookup table on the new codebase.

Want to learn some Python? 😁

[tomek-szczesny]

Damn, I didn't even remember it wasn't merged in the end, I thought it was!

[FaBjE]

I am hesitant to ask, but is @tomek-szczesny willing to give this another shot? (Implementing the LUT on the current codebase)

I feel like the best I can do if I find any time is quickly hack something into it if I manage at all...

[tomek-szczesny]

There's no harm in asking. I've got two jobs at the moment so I am unable to spend much time on Labelle. Moreover I'm not fluent in Python so everything I do is just as hacky and amateur as it gets.
I encourage you to give this a try. The other owners may be able to do the proper review of your code, so any proficiency level is welcome.

I may be able to answer questions about my old implementation, I guess I will know what I had in mind :)

[FaBjE]

I'm not promising anything, But I'm giving it a shot.

Edit: I'm in conflict with your formatter/pre-commit checks.
I have a line which was too long. So I line-breaked them.
But now the formatter removes the line break in my first commit attempt, the second it complains again the line is too long again...
I disabled the formatter with a pragma but this is really annoying...

[maresb]

Sorry about that @FaBjE. You can use git commit --no-verify ... to skip the checks.

Also, if you include the specific lines you're working on I should be able to advise you on how to appease the linter.

[FaBjE]

I think I found a pretty nice way to handle things.

(long story short) I have added a DeviceConfig object that contains a configuration for each type of printer/labeler.
I started out with the lookup table, but puzzeled by the "random" margins I figured it out how the principal works.

For every printer we now need a "print head size in pixels" and "print head active size in mm" the rest is calculated.
I think there might only be two versions (128px/18mm and 64px/9mm).

Based on my scans we determined a label-position inaccuracy of 0.7mm. I rounded it up to 1mm to use as safety margin for now.

My current code state is at: main...FaBjE:labelle:feature/deviceDependentMargins

I´d like to hear your thoughts.
I've tested it on my LabelManager PC II and a LabelManager PnP both can print valid labels 12mm (and 24mm on the PCII)

I have identified a couple of issues so far:

• Supported tape sizes dropdown not cleared in GUI, making a mess. With the config object it should now show only the options supported by the printer
• Margins preview in GUI are not correct
• Boxed text, left border 1px missing
• mm_to_px functions are maybe not accurate. Look into/refactor those?

[maresb]

Thanks @FaBjE! Could you please open a pull request with your branch?

[FaBjE]

Made a draft PR as I don´t feel it is ready to merge yet
#54

[tomek-szczesny]

Hm. The point of LUT that I developed was to be prepared for any future Dymo printer. That is why I proposed to measure print area in dots, as well as a single necessary offset, and then only name this settings in mm for user's convenience.
No millimeters handled in the code because frankly we don't need them there at all.

I'm afraid that although your solution is convenient for supporting a subset of Dymo products known to us at the moment, I'm not sure how well this will scale with printers of other brands or series.

[maresb]

I agree we should use px instead of mm wherever possible. @tomek-szczesny, would you please move your comment to the PR so that we have all reviews in one place?