LUT based label size and offset handler

[tomek-szczesny]

Hopefully adding support to new printers will be easier with this.

Related issues: #30 #40 #44 #47 #80

[tomek-szczesny]

Now tests are failing because the test script has no Dymo printer, lol.

[maresb]

Haha, I guess we need to rework the tests.

Also, looking at the Python 3.7 tests, there's an issue with old versions of Python and the type hints:

Wherever you have something like tuple[int, int] you should add to the imports section

from typing import Tuple

and then change it to Tuple[int, int].

[tomek-szczesny]

So what do we do about the tests? Some sort of hidden parameter --no-conn to not even attempt looking for a printer?

[maresb]

The failing tests are rightfully hinting to us that our code structure sucks.

In my opinion, the proper way to do this would be to have various representations:

1. An abstract representation of the objects to be rendered which should roughly mirror the UI in dymoprint_gui
2. An image representation of what is to be printed
3. A representation of the commands that should be printed, roughly mirroring the technical specification of the protocol
4. A byte representation of the commands which is sent to the printer

Then Dymoprint should transform these various representations from 1 all the way to 4, and after the very last step the bytes should be sent to the printer.

Since we can't test the device itself, we should instead have a virtual mock device which receives the commands, emulates how we believe the printer works, and virtually prints them to an image representation (number 2. above).

There would be several benefits to this structure. We could write meaningful tests that we could, for instance, recover the image representation by virtual printing. We could also implement the "preview" as such. Then it would be a true preview instead of a separate code branch.

This would unfortunately require some substantial refactoring of the current code. I'm not sure how best to proceed here. Probably there is some clever incremental change which would require less effort.

[tomek-szczesny]

Indeed this code looks like it was meant for printing text, only later a plethora of other options was added.

I would agree that such a structure will work:

• A collection of objects representing printed items (like: "barcode, type: EAN, data: 123456")
• Each object transformable into a bitmap, maybe as a class property? But at this point, the tape size must be known. Maybe if no printer is detected we could assume PnP.
• Each object transformable into a printer bit stream, based on a bitmap subroutine.

As a matter of fact we don't have to stitch all bitmaps together and send a single large bitstream to the printer - it may think we're sending a few separate jobs and I think that should work exactly the same.

I suspect that you proposed creating image representations before the tape size is known, but unfortunately this won't work. Scaled down monochromatic graphics will look terrible and in most cases produce nonfunctional barcodes.

Would be really nice to have a working code interpreting printer bit streams, but that's a huge task, and we have limited understanding of Dymos. :) We could recreate what we think it does, but with comparable effort we could create a stable API for print engines, the most probable area of future developments. But that's just my opinion, I'm not a pro coder and never set up automated tests for my projects.

The test campaign on 420p has seemingly stalled, now I'm not sure what do we do with this PR. Just blindly accept it hoping it's doing more good than harm?

[maresb]

Ya, what I wrote was meant to be an outline, so there are still details to be worked out, for example as you astutely point out that tape size is a parameter from the bitmap representation, and likely there are others.

I don't think interpreting bit streams would be that difficult. We only use a limited subset of commands. And indeed, a stable print engine API is also important. I'm mainly just dreaming out-loud.

And yes, perhaps blindly accepting is the right move here.