Added support for printing Aztec codes and setting left margin print position #217
Conversation
|
This is awesome! I'll give this a look soon and merge / release an update as soon as I get a moment. |
| /// <inheritdoc /> | ||
| public virtual byte[] PrintAztecCode(byte[] data, ModeTypeAztecCode modeType = ModeTypeAztecCode.FULL_RANGE, int size = 3, int correctionLevel = 23, int numberOfDataLayers = 0) | ||
| { | ||
| List<byte> command = new List<byte>(); |
There was a problem hiding this comment.
Are there any validations we could do for this command? Perhaps regarding the size of data, or min/max on correction level and layers?
Take a look at DataValidator class and see if you can implement some similar guardrails for this command.
There was a problem hiding this comment.
@igorocampos Hi, I finally had some time to look at this again.
I've added validation of the data size by using ZXing.Net.
There was a problem hiding this comment.
I see you added a new dependency to the project in order to validate the data size, is there other way of validating it? I don't think we want to add external dependencies like that in the project. The empty catch is not helping much either, you are just re-throwing the very same without any friendly details to the library user, in that case, why have the try at all? As a library user, if I provide an invalid size for the data, I would like to receive a message saying at least:
1 - The data I used was not in an acceptable size
2 - What is the acceptable size
Similar to what you have done to Module Size, I guess. Other than that I would just keep the empty new lines in the end of the files, but I can open new suggestion regarding that in the review, so you can solve them as easy as a button click :)
There was a problem hiding this comment.
@igorocampos If I'm not completely mistaken, the problem with validating the data length for an Aztec is that you need to start encoding it to see if it's too big when it's close to the maximum size.
It's not as simple as validating the length of a string or the number of bytes that translates to before encoding it.
I've tried to confirm this by generating random strings that are 3067 letters long, which is the maximum of an Aztec, and that will fail to print if I mix upper and lowercase letters but succeed if the string is either only upper or lowercase.
Encoding the strings with ZXing.Net matches the printer's behavior and throws an exception for the string that can't be printed.
So either I'd have to implement the entire logic for encoding the data or use a lib for it, unless there is something I'm missing of course.
There was a problem hiding this comment.
In that case, perhaps that one validation should not be implemented. I think the "price" is too high. @lukevp do you agree?
|
|
||
| public int MaxCorrectionLevel { get; set; } | ||
| } | ||
| } |
| } | ||
| } | ||
| } | ||
| } |
This PR adds support for printing Aztec codes and for setting left margin for print position.
Tested on an Epson TM-m30.
Based on Epson documentation.
Aztec Code: Set the number of mode types and data layers
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=161
Aztec Code: Set the size of the module
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=162
Aztec Code: Set the error correction level
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=163
Aztec Code: Store the data in the symbol storage area
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=164
Aztec Code: Print the symbol data in the symbol storage area
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=165
Aztec Code: Transmit the size information of the symbol data in the symbol storage area
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=166
Set left margin
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=60