-
-
Notifications
You must be signed in to change notification settings - Fork 173
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
PDF417 max 255 characters #253
Comments
I see you mentioned something about your country's official ballots. Do they have to be PDF417? The reason I ask is if PDF417 is supposed to support larger data areas than ESCPOS currently supports then maybe we're doing something wrong. Another possible interpretation of the above is that you can store more than 255 bytes, but you can only write 255 bytes to the symbol storage area at once, and pL/pH are used as offsets, so the true max size is then 65535. If that's the case and that's the right way to interpret this, then I think you would split your byte array on every 255 bytes, so byte 256 would be in a second call, and byte 512 would be in a third call, etc. And you would increment pH each time by one (so pL would be 0 and pH would be 0, then 1, then 2). I'm not sure if that's really how it works, but I don't know why they would have an offset based system like this if it didn't work that way though. If you try this out and you're able to use the offset to print, then we could update the code around this QR format to take in longer bytes and auto split it and set offsets for the user (basically bake this into the code itself). That seems like a really helpful feature. We could have test coverage around this too. Let me know if you try this and if you run into any issues. |
This document from Star makes it sound like the true data max size is 1024, and that you have to write it 255 bytes at a time to the buffer. This is probably why it's a buffered command as well and not an immediate print command - essentially there's a 1024 byte (1KB) staging area set aside for this. you write your data into it with multiple commands, and then you issue a print command. If the max was 255 then there probably wouldn't be a way to feed data into a buffer at all and it would print directly from the command. Makes me wonder if this is a general thing across the other 2d code family or if it's only relevant to PDF417 because it stores more data? PRs are very welcome so if you get this working, please consider contributing back as a PR so others can use it! |
So you think we need to run the store command multiple times (255 chars each) and then in the end print out the barcode? It does make sense, but I would assume the printer just overwrites the stored bytes with a new command being sent... I would like someone to test it, if it works I can easily submit a PR with that change. |
Hmm, that actually makes sense! Ok, I can fix it then, and probably double-check other bar codes they may have mistakenly similar caps in place. |
Indeed, the electronic stamps of official documents must come stamped with
a PDF417, which contains a variable paragraph of the electronic signature
of the same document, this paragraph varies between 350 and 450 characters,
in previous systems the way to solve it was to generate the PDF417 as a BMP
graph and then drawing this on the receipt as an image.
El dom, 14 ene 2024 a las 20:08, Luke Paireepinart (<
***@***.***>) escribió:
… I see you mentioned something about your country's official ballots. Do
they have to be PDF417? The reason I ask is if PDF417 is supposed to
support larger data areas than ESCPOS currently supports then maybe we're
doing something wrong.
Another possible interpretation of the above is that you can store more
than 255 bytes, but you can only write 255 bytes to the symbol storage area
at once, and pL/pH are used as offsets, so the true max size is then 65535.
If that's the case and that's the right way to interpret this, then I think
you would split your byte array on every 255 bytes, so byte 256 would be in
a second call, and byte 512 would be in a third call, etc. And you would
increment pH each time by one (so pL would be 0 and pH would be 0, then 1,
then 2). I'm not sure if that's really how it works, but I don't know why
they would have an offset based system like this if it didn't work that way
though.
If you try this out and you're able to use the offset to print, then we
could update the code around this QR format to take in longer bytes and
auto split it and set offsets for the user (basically bake this into the
code itself). That seems like a really helpful feature. We could have test
coverage around this too.
Let me know if you try this and if you run into any issues.
—
Reply to this email directly, view it on GitHub
<#253 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOSEIR2WXSABIZGMAK5PKJDYORQOXAVCNFSM6AAAAABA66Y42CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJRGEYDIMRYHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
*Luis Perez Vasquez*
*Especialista en Proyectos y Soluciones **Tecnológicas*
*www.tokem.cl <http://www.tokem.cl>*
|
I double checked all barcodes, there was just a couple more that had different values based on EPSON's manual, However I've also had to use STAR's manual to get GS1 Barcode limitations (not sure way, but it's not part of EPSON's manual that I have). I also noted the library doesn't implement (0 |
I try to print a 2d code with the following command :
impresion.Print2DCode(TwoDimensionCodeType.PDF417, documento.Ted, Size2DCode.LARGE, CorrectionLevel2DCode.PERCENT_15)
but it returns an error "string has more than 255 characters", I need to print a string of 350 characters which is the official stamp for electronic ballots in my country, I am generating the pdf stamp as an image and then I print it with:
print.PrintImage(bytesPDF, true, true) , but the quality is blurry.
I take this opportunity to thank you for the great work you do, really thank you very much.
The text was updated successfully, but these errors were encountered: