Activity for Zint Barcode Generator
-
Git Lost committed [f9a493] on Code
DATAMATRIX: add new options `DM_B256_START` and `DM_C40_START` to
-
raster/vector: EAN/UPC: fix calculation of image/vector height to
-
raster/vector: fix BARCODE_BIND_TOP trumping BARCODE_BOX
-
Batch printing function
-
Closing this as not planned.
-
prefix for global symbol names to avoid collisions
-
Fixed in release 2.16.0, thanks again Ulrich.
-
Mailmark 2D postcode format.
-
Fixed in release 2.16.0 Milton, thanks.
-
GS1 linter: alpha checksum is 2 characters, not one
-
Closing as fixed in release 2.16.0 - doing some housework Harald!
-
all windows tests using shared library are failing
-
Fixed in release 2.16.0 with commits [700705] and [d41325], thanks Ulrich.
-
"H" is in the unallocated list in UPU S10 code.
-
Closing as was fixed with release 2.16.0, thanks Milton.
-
raster/vector: allow for separator height being > twice row height
-
debian/copyright: some more missing attributions
-
Hi Robin, great to hear from you! Re "pdf417_tab.h", yes, I noticed that the info is just transcriptions of the ISO/IEC standard and adjusted the comments accordingly (if not always correctly) in commit [df64a0] - however I forgot to remove the Copyright notices in "pdf417_tab.h" & "pdf417.h" - have rectified that (plus some fixes & expansion of the comments) with commit [a9eef1]. Interesting to hear about the evolution of the code, however looking at "pdf417.frm" and at the line numbers in "pdf417.c"...
-
pdf417.h/pdf417_tab.h: remove Copyright (C) 2004 Grandzebu and fix
-
Robin Stuart posted a comment on ticket #147
Hi - just dropping in to see if I can fix that PDF417 problem. My fault - I should have sorted that out years ago! There is no code from Grandzebu's project in Zint so I'm confident his copyright can be removed. When the header says it was "adapted from" his code that is, in retrospect, incorrect. Today I would say it was "inspired by" his code - the algorithm started off being the same but the code was completely re-written. The only thing that remains is some of the variable names. I think the...
-
Hi John, eventually got something that "works for me" with commit [df64a0]. Added a "README.deb" which might be useful. The cmake issue was down to a change to accommodate Nix (commit [9265ab] last year). Thanks for the pointers, had to do a lot of reading to work it out. There's still some issues, e.g. support for the GS1 Syntax Engine isn't enabled. I haven't contacted the maintainers yet (though I copied a lot of their stuff), but may do in future. It also prompted an audit of copyrights which...
-
debian: updated using https://salsa.debian.org/debian/zint as
-
gs1_lint_parse_raw_caret: check that data of AIs with non-predefined
-
AZTEC: use algorithm adapted from ZXing for optimized encodation
-
John Crisp posted a comment on ticket #147
Ah cool!! Thanks Martin. I would suggest a look at their package stuff as it clearly worked on 2.15 as described above. I essentially just removed your old debian build stuff and added theirs (I am no guru at this build stuff!) I kind of followed from here: https://packages.debian.org/search?keywords=zint&searchon=names&suite=testing§ion=all Might be worth keeping in contact with the maintainers there who would probably help. Mnay thanks, John
-
Debian build fails
-
Hi John, re-opening this. Yes the debian stuff is way out of date. I've never looked at it myself and never used dpkg-buildpackage. But am interested in getting it to work and this won't be a wontfix. However it will be a few days before I can look at it. Thank you for taking the time and effort to respond here, and for raising the issue in the first place, your feedback is genuinely much appreciated, best regards, Martin
-
A follow up to this. Adding this for reference as no point in a new bug as it will be a wontfix. Same issues as the debian directory is way out of date. I just built 2.15 from Debian sources on a buntu 24.04 box mkdir zint cd zint wget http://deb.debian.org/debian/pool/main/z/zint/zint_2.15.0.orig.tar.xz wget http://deb.debian.org/debian/pool/main/z/zint/zint_2.15.0-1.dsc tar -xf zint_2.15.0.orig.tar.xz cd zint-2.15.0-src wget http://deb.debian.org/debian/pool/main/z/zint/zint_2.15.0-1.debian.tar.xz...
-
manual: clarify API GS1 flags require `GS1_MODE`
-
Fix some typos; add _typos.toml
-
Hi, implemented option 2, with GS as the FNC1 stand-in, hidden behind the input_mode flag GS1RAW_MODE (CLI "--gs1raw") with commit [9ef5bc] (bug fix -initially [0a8a79] ). Also implemented the GS1 Syntax Engine "Unbracketed AI" caret mode I mentioned, triggered by an initial caret. They're documented in the manual in Section "4.11.3 GS1 Data Entry and Options" . Any testing or feedback would be most welcome, regards, Martin
-
Thanks, suppressed the "-Wshorten-64-to-32" ones with commit [bd3395], but not the "-Wconditional-uninitialized" ones, at least not for now, as don't agree with it.
-
general: add -Wshorten-64-to-32 compiler flag & suppress warnings
-
GS1SE: fix bug in allowing initial GSs in GS1RAW_MODE in composites
-
Axel Waggershauser created ticket #351
xcode complains about -Wshorten-64-to-32 (mostly)
-
GS1: new `GS1RAW_MODE` (CLI "--gs1raw") and GS1 Syntax Engine
-
Hi, nice to hear from you again. Good to hear - Data Matrix is first on the list!
-
codemonkey82 posted a comment on ticket #350
Hi Martin, Just as info. This feature would be very convinient for me too: "Currently only Code 128 supports manual FNC1s, though there are plans in the fairly short term to extend it to all other barcodes that can encode FNC1s." For context: I have gotten this abomination from a customers site: "^FD>;>80014009895220145656910>600326316^FS" It begins in GS1 in subset C, but then switches back to subset B while still using GS1. I have never seen this before, but I will have to support it at some point...
-
Hi, yes, option 2 sounds good for GS1 data. Will give that a go. Will initially accept GS as a separator. I also like the GS1 Syntax Engine "Unbracketed AI element strings" using carets. This has the advantage of being a recognized GS1 format, and as the code to parse the AIs is basically the same as option 2, will probably implement at some stage. Option 1 is useful for scenarios other than GS1 also, so will be implemented at some stage. Thanks for the feedback, Martin
-
GS1 DataBar inconsistencies
-
Done!
-
Hi Martin, please close this issue.
-
Mario Verbruggen posted a comment on ticket #350
Hi Martin, Harald, The customer of our customer specified that DataMatrix shall be used . So Code128 is not an option. The sample code I provided didn't start with FNC1 and uses GS as separator. So in a manual mode, I call it pre-encoded or raw data, Zint and other encoders does not create a GS1 compliant DataMatrix (without manipulating customer data). In my opinion there are a few solutions: Add FNC1 start character to the raw data and use a regular DataMatrix. This has a downside, there will be...
-
Hi Mario, you can actually do this for Code 128 with the option --extraesc and using"\^1" for FNC1s instead of literal <GS>s. The data must also be prefixed by "\^1" to indicate GS1 mode, e.g.: zint -b CODE128 --extraesc -d "\^10108033196601203215dqshh(D)h/VT\^191EE11\^1926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw=" Note the use of CODE128 (20) not GS1_128 (16) as GS1-128 expects bracketed data. Also zint will not verify the data as valid GS1. If this doesn't suit and/or you prefer your solution...
-
Harald Oehlmann posted a comment on ticket #350
Thanks, for this use-case the --gs1parens is not suitable. You may use plain Data Matrix with a verbatim FNC1 at the front. Nevertheless, the data is IMHO not unique. At the end of [21] data, there must be an information to include a FNC1/GS. I don't see that. Is it me? THanks for all, Harald
-
The use case is as followed: pre-encoded data = 0108033196601203215dqshh(D)h/VT 91EE11 926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw= and should give following AIs [01]08033196601203 [21]5dqshh(D)h/VT [91]EE11 [92]6FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw= Between ..VT91.. there is a x1D character and also between ..1192.. with kind regards, Mario
-
The use case is as followed: pre-encoded data = 0108033196601203215dqshh(D)h/VT 91EE11 926FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw= and should give following AIs [01]08033196601203 [21]5dqshh(D)h/VT [91]EE11 [92]6FD99cQGfQchHEfcaOF2tTbByJw0TywDRzOJNtCV8Fw= with kind regards, Mario
-
Are you aware of this syntax (manual, page 58): zint -b 16 --gs1parens -d "(01)98898765432106(3202)012345(15)991231" Then, you only need to ignore any included gs. Perhaps, you do a pre-processing by removing all "gs"... Take care, Harald
-
accept pre-encoded GS1 data
-
CODE32/PZN: fix not restoring `option_2` (props axxel)
-
AZTEC: az_punct_size(): small perf. improvement
-
You might want to check out https://github.com/j-evins/glabels-qt
-
Thanks for the proposal. There is currently no print support at all. Proposed code welcome. Take care, Harald
-
Sergio created ticket #349
Batch printing function
-
Re encodation, almost optimal algorithm added with commit [bcb3ce].
-
AZTEC: add almost optimal encoding algorithm, previous algorithm
-
Great, thanks, I appreciate ! Take care, Harald
-
Hi Harald, Terry, suggested change implemented with commit [cf5ef9], thanks!
-
GS1SE: exclude GS1_128 from requisite AIs check as may be spread
-
As a side note, also see discussion at the end of https://github.com/gs1/gs1-syntax-dictionary/issues/23 The most recent specification file may be imported to have more precise error messages.
-
Terry has proposed the following for Code128 symbology: gs1_encoder_setValidationEnabled(ctx, gs1_encoder_vREQUISITE_AIS, false); I think, that would be a great enhancement. Thanks, Harald
-
GS1 syntax engine extension for GS1-128 Symbology
-
Excellent, thanks!
-
Bryce Harrison posted a comment on ticket #346
It worked! Thanks for the update!
-
Thanks for that Bryce. I found out that the previous commit didn't actually work on Sonoma either, must of got myself confused somehow. Could you try commit [1ba5ba] when you get a chance? This sets rpath for both macOS and UNIX (in fact regardless of OS), and for both the CLI and GUI.
-
cmake: rpath take 2, re previous commit [eea16e], use global
-
Here's the output from --trace if it helps.
-
Oh dear, thanks for letting us know Bryce, I'll see if I can set up a Tahoe VM as well to check it out. I suppose using the CMake --trace options might also be a way to debug this.
-
Hi Martin, I'm on Tahoe 26.2 with an M4 CPU and I'm having the exact same library error. I just cloned the repo today and it's on commit 0efc4f. Also, I needed to use a different QT5 path. /opt/homebrew/opt/qt@5/bin Let me know if there's any more info I can provide to help. /usr/local/bin % ./zint dyld[27431]: Library not loaded: @rpath/libzint.2.16.dylib Referenced from: <10F3B78D-87F5-38D9-8B19-785A19126299> /usr/local/bin/zint Reason: no LC_RPATH's found zsh: abort ./zint
-
Hi Martin, I'm on Tahoe 26.2 with an M4 CPU and I'm having the exact same library error. I just cloned the repo today and it's on commit 0efc4f. Also, I needed to use a different QT5 path. /opt/homebrew/opt/qt@5/bin Let me know if there's any more info I can provide to help.
-
Re error correction, adjusted with commit [0efc4f].
-
AZTEC: fix ECC to be at least advertised percentages (ticket #347,
-
Good stuff, thanks for checking it out Hagen, and for the report, all the best, Martin
-
Hagen Röwer posted a comment on ticket #346
Hi Martin, this commit fixes the installation. Thanks for the solution, Best regards, HR
-
Re optimal encodation, yes, this has been on the to-do list, will see what I do over the coming week or so. Re error correction, thanks for pointing that out, will adjust the calculations.
-
Francois Grieu created ticket #347
Wasteful encoding of AZTEC symbols reduces capacity by 25% for random data
-
Finally got an in-date macOS VM running (courtesy of OSX-KVM), running 14.8.3 Sonoma, and reproduced your issue, but only for the CLI (zint), not the GUI for some reason. Anyway commit [eea16e] sets the rpath for macOS on the CLI - if you get a chance let us know if that fixes things for you, regards, Martin
-
DOTCODE: fix not emitting FNC1 (signalling non-GS1) when input
-
Hi, yes, try -DCMAKE_INSTALL_RPATH=/usr/local/lib. If that works I'll add it to the "CMakeLists.txt" using the install variable instead, thanks
-
Hi Martin, thanks for the tip. I'll give that a try. Should I use the absolute value for the path "-DCMAKE_INSTALL_RPATH="? Best regards und thanks, HR
-
Hi Hagen, thanks for reporting this. Unfortunately I've only got an old macOS 12.7.2 VM at the moment, and can't reproduce the issue on that. I see the Homebrew formula https://github.com/Homebrew/homebrew-core/blob/main/Formula/z/zint.rb invokes cmake with "-DCMAKE_INSTALL_RPATH=" - if you cmake with that, setting it to "/usr/local/lib", does that fix the issue? If so I'll add it to the "CMakeLists.txt". Hopefully I'll have a more modern macOS VM soon and can check it out myself. Best regards, ...
-
macOS 15.7.3 - Library not loaded: @rpath/libzint.2.16.dylib
-
BWIPP: need to set enabledontdraw in "bwipp_dump-barcode.ps.cat";
-
CODE128: fix not handling FNC1 at end of data when in manual
-
ZBarcode_Encode_Segs: fuller debug output (all input fields)
-
QRCODE: implement pre-calculated QR/MICROQR masks ala BWIPP for a
-
GUI: DAFT: re-squash tracker examples back to 2 lines so should
-
CLI: test: suppress clang-tidy warning
-
CLI: fix bug in "--scalexdimdp" in converting from "in" to "mm"
-
backend_qt: new method `save_as_memfile()` to save as
-
CLI: add `ZINT_TEST`-only "--test" option (currently just ensures
-
I think the ZXing-C++ data return format has settled down and won't be changing much (or very little) in the future. Version 2.4.0 is also pretty imminent which would cement the data return format at least for that release. Re EANX_CHK being tagged as "legacy" and UPCA_CHK not, it's because EANX_CHK also accepted EAN-8, which made it problematic to distinguish input with separator-less add-on data, which was needed by ZXing-C++. Splitting EANX etc. into EAN13 and EAN8 also makes everything a lot...
-
Andre Maute posted a comment on ticket #345
Hi Martin, thanks for posting your insights, I wonder if it would be possible to let the two projects converge a little bit more, so my fix functionality isn't needed anymore. Perhaps Axel reads this. https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L336 int zintFixZintSymbology(const std::string& input, int zintsymbology); and https://github.com/a3emdot/zintzxingcppdemo/blob/e025de87460cd88769a2ef289a5401b5f37c66ba/src/barcode.cpp#L509 std::string...
-
Yes, and I am wrong. The code [01]00000000000000 is not seen as error by -gs1strict. Strange, I had this discussion with Terry and we first did not accept a 0 GCP... Sorry, Harald
