Activity for Zint Barcode Generator
-
Git Lost committed [b43420] on Code
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...
-
Harald Oehlmann posted a comment on ticket #345
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
-
You're referring to https://www.gs1.org/standards/gs1-style-guide/current-standard#2-Applicable-to-all-GS1-documentation+2-18-GS1-prefix-952-for-examples ? Thanks, didn't know about it. For internal testing I don't think it matters, but should probably use them in the manual.
-
Sorry for the noise. It would be great to use the GS1 demo prefix for any testing, which is 952. Examples for ISO/IEC 15240:2024: EAN13: 9520123456788 EAN-8: 95200002 UPC-A: 012345000484 UPC-E: 01234558 GTIN-14: (01)09520123456788 This avoids conflicts with -gs1strict Just an idea, Harald
-
Hi Andre, thanks for checking this. There were (at least) 2 changes to the way ZXing-C++ returns data (none to do with zint per se!): UPC-A (and UPC-E) now return a 13-digit number that includes the implicit "0" at the beginning - - https://github.com/zxing-cpp/zxing-cpp/commit/c4f5647eadde5330855861f733f5c530d6eafad9 GS1 DataBar Omnidirectional (and Stacked version) now return the implicit "(01)" at the beginning - https://github.com/zxing-cpp/zxing-cpp/commit/36495ef0358c3d56d2e06e8a8ffdaac6afafcdb8...
-
Hi Harald, no, not in this case, "-gs1strict" isn't being used.
-
Is it possible, that those codes are filtered out by "-gs1strict" ? The first code "0000012345" will probably fail due to a zero company prefix error. But this does not apply to UPCA. Is there a 2D component?
-
UPC-A and GS1 Databar inconsistencies with Upstream zxing-cpp and zint versions
-
win32/vs2015: fix Release/Release_LIB sln files for MSVC2015,
-
Bump to version 2.16.0.9 (dev)
-
Zint Barcode Generator released /zint/2.16.0/README.txt
-
-
-
-
-
Version 2.16.0
-
frontend: workaround musl `getopt_long_only()` bug,
-
backend_tcl: readme.txt: mention distributed DLLs bitness
-
-
backend_tcl: make GS1 Syntax Engine non-optional for simplicity
-
GS1 syntax engine for TCL backend:
-
backend_tcl: enable "-gs1strict" for Unix
-
Add -gs1strict to TCL backend
-
-
DENG GOLD posted a comment on ticket #341
Hello Git Lost If it's just the compilation process, there's not much need to modify "CMakeLists.txt" at the moment. At least, using the default "CMakeLists.txt" for compilation is fine (it doesn't depend on the png library). However, if it's about running the application or packaging the software, the issues described in #342 and #343 become very important. In a development environment, there shouldn't be any missing DLL errors, but in a production environment, these errors will occur, mainly related...
-
GS1: update to latest gs1-syntax-dictionary (new AIs 717
-
ZBarcode_Encode crashes if passed too much data
-
Cool Christian, thanks for taking the time to raise the issue anyway, closing now...
-
Hi, the "win32\README" suggests adding stuff to your environment, not your system environment (though of course you can do that). The changes you suggest are specific to your setup, and I don't think they belong in the "CMakeLists.txt". You can use a ".bat" file or whatever to achieve the same thing. Thanks for your effort, but I won't be applying these changes.
-
Christian Schmitz posted a comment on ticket #344
Sorry, we'll update.
-
342 Fix missing DLL error when opening When compiling in dynamic library mode, running the generated .exe file from Frontend results in a missing DLL error. This can be resolved by modifying the frontend/CMakeLists.txt file. Add the following code ------------------------------------------------------- if(ZINT_SHARED) zint.dll add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_BINARY_DIR}/backend/$<config>/zint.dll" "${CMAKE_BINARY_DIR}/frontend/$<config>/"...
-
342 Fix missing DLL error when opening When compiling in dynamic library mode, running the generated .exe file from Frontend results in a missing DLL error. This can be resolved by modifying the frontend/CMakeLists.txt file. Add the following code ------------------------------------------------------- if(ZINT_SHARED) zint.dll add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_BINARY_DIR}/backend/$<config>/zint.dll" "${CMAKE_BINARY_DIR}/frontend/$<config>/"...
-
342 Fix missing DLL error when opening When compiling in dynamic library mode, running the generated .exe file from Frontend results in a missing DLL error. This can be resolved by modifying the frontend/CMakeLists.txt file. Add the following code ------------------------------------------------------- if(ZINT_SHARED) zint.dll add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy "${CMAKE_BINARY_DIR}/backend/$<config>/zint.dll" "${CMAKE_BINARY_DIR}/frontend/$<config>/"...
-
OK
-
OK
-
Sorry, I just looked at the "win32\README". I found that adding the ZLIB and PNG libraries following the steps is quite cumbersome; it's best to integrate them completely into the project. I've already managed to build and compile the project without these steps by modifying the relevant CMakeLists.txt file. I haven't tested whether adding the ZLIB and PNG libraries step-by-step according to the instructions in "win32\README" will succeed on the first try; I'll try it later when I have time. As for...
-
Oh ok, missed the version comment. The check was introduced in version 2.11.0. Is there some reason you're using such an old version?
-
We got a crash report with ZBarcode_Encode crashing with a stack overflow. Maybe you fixed it already in a newer version, but I would recommend to check against ZINT_MAX_DATA_LEN. I added such a check to the function for our copy of the source code. There is no reason why it should accept 2 MB.
-
Hi Christian, on what system are you getting a stack overflow, and in which function? Currently zint checks that input data length < 17400 (ZINT_MAX_DATA_LEN in "backend/zint.h"), which as the comment says is the maximum capacity of Han Xin, the most capacious barcode supported by zint. zint makes extensive use of alloca() (called z_alloca() internally). This use could be lessened at the cost of speed and ease of internal error handling by using malloc() instead, although that obviously transfers...
-
Version was Zint 2.9.2
-
ZBarcode_Encode crashes if passed too much data
-
Improve related build and compilation details
-
Please engage on ticket #341
-
Fix missing DLL error when opening
-
Please engage on ticket #341
-
It is entirely possible to add libpng and zlib to the build chain. I have already implemented this by modifying CMakeLists.txt on the basis of the original project.
-
It is entirely possible to add libpng and zlib to the build chain. I have already implemented this by modifying CMakeLists.txt on the basis of the original project.
-
Improve related build and compilation details
-
Fix missing DLL error when opening
-
Hi, did you read the section "CMake and Visual Studio" in the README file for Windows ("win32\README")?
-
Update: When building the project via CMakeLists.txt, the Qt 5/6 version could not be accurately identified. I have now modified CMakeLists.txt to accurately identify the Qt version. For example, adding set(CMAKE_PREFIX_PATH "D:/Qt6.5.3/6.5.3/msvc2019_64") resolves the issue. It's best not to add Qt to environment variables, as this may cause development environment pollution and conflicts. Next, I will try to resolve the issue of not finding the ZLIB and PNG libraries.
-
defeat win32 Compilation error
-
general: `raw_segs` -> `content_segs`, `BARCODE_RAW_TEXT` ->
-
ECI: ECI 899 binary in `UNICODE_MODE` now converted from UTF-8,
-
Ulrich Becker posted a comment on ticket #340
Hi Martin, thank you for your fast reaction, now all tests are running successfully in our CI Best Regards Ulrich
-
manual: use modified "haddock.theme" for nicer syntax highlighting;
-
general: suppress clang-tidy-21/22 warnings;
-
Hi Ulrich, thanks for pointing this out. Eventually got this working by reverting to setting the ENVIRONMENT directly and backslashing semicolons in $ENV{PATH}, rather than using ENVIRONMENT_MODIFICATION and path_list_prepend. It seems to work now in the CI and locally, regards, Martin
-
CI: windows: try env_path backslashing semicolons hack
-
CI: windows: try adding backend_qt to PATH
-
test_qzint: try setting CMAKE_CURRENT_SOURCE_DIR
-
test suite: Windows: use old-fashioned setting of ENVIROMENT PATH
-
gs1: Use new `gs1_encoders_init_ex()` API;
-
all windows tests using shared library are failing
-
win32: add "zint_dll_vc6" sub-directory with VC6 workspace for
-
Genricke posted a comment on ticket #339
Thanks for the help! The ZINT.DLL build in VC6 is in demand and used ! :)
-
Good to hear! Yes, it was built from the 2.15.0 source. I'll add the workspace to git in a while... thanks for the feedback, it's very useful to me to know how people are using zint, regards, Martin
-
Addition ! In your build ZINT.DLL no changes from 2025-04-16 in \backend\zint.h Buffer length of member errtxt in zint_symbol extended 100 -> 160 (will be sufficient for eventual translation and gs1-syntax-dictionary errors hopefully) I returned the size of 100 for errtxt and everything worked fine ! :)
-
Addition ! In your build ZINT.DLL no changes from 2025-04-16 in \backend\zint.h Buffer length of member errtxt in zint_symbol extended 100 -> 160 (will be sufficient for eventual translation and gs1-syntax-dictionary errors hopefully) I returned the size of 100 for errtxt and everything worked fine ! :)
-
-
Thank you very much! This is exactly what I needed and was included in the ZINT 2.13 package. But there is a problem. Accessing the data of the zint_symbol.bitmap structure ends in a crash. In your current build, do the fields of the zint_symbol structure match the description in \backend\zint.h ? Or are there any changes already? Please send me the file \backend\zint.h from your computer where the assembly was performed zint.dll . Thanks !
-
Thank you very much! This is exactly what I needed and was included in the ZINT 2.13 package. But there is a problem. Accessing the data of the zint_symbol.bitmap structure ends in a crash. In your current build, do the fields of the zint_symbol structure match the description in \backend\zint.h ? Or are there any changes already? Please send me the \backend\zint file.h from your computer where the assembly was performed zint.dll . Thanks !
-
Thank you very much! This is exactly what I needed and was included in the ZINT 2.13 package. But there is a problem. Accessing the data of the zint_symbol.bitmap structure ends in a crash. In your current build, do the fields of the zint_symbol structure match the description in \backend\zint.h ? Or are there any changes already? Please send me the file \backend\zint.h from your computer.
-
Oh I see. I've attached a Zint 2.15.0 "zint.dll" (and its "zint.lib") which was built with VC6, so should work on XP. If it checks out ok for you I'll add the VC6 workspace that created them to git.
-
Yes, I am creating my own Win32 application. I built a ZINT.DLL in VS 2022, but it depends on vcruntime140.dll and it doesn't work on Windows XP/2003. Previously, the ZINT 2.13 package included ZINT.DLL (Win32) without dependencies on Visual Studio libraries. Please help me to assemble such a ZINT.DLL (Win32) or return it to the ZINT 2.15 package. Thank you!
-
That DLL was for Tcl 8, so "zint2150t.dll" would be the equivalent. May I ask why do you need a "zint.dll"? What issue are you having? Note that none of the Tcl DLLs depend on Qt, and the "zint.exe" and "qtZint.exe" shipped are self-contained and do not require "zint.dll" or Qt DLLs. (If you're building your own app, see the first part "of "win32\README", "Visual Studio 2022", for how to build "zint.dll" (Win32) - only requires installing Visual Studio 2022 Community Edition.)
-
Thanks ! Yes, was available before Win32 tcl\zint.dll . I don't have TCL 8/9 and I can't get the DLL for the ZINT 2.15 version.
-
Hi, do you mean the "zint.dll" that used to be in the "tcl" sub-directory? This is now in the "tcl\zint2.15.0" sub-directory in 2 versions: "tcl9zint2150.dll" for Tcl 9, and "zint2150t.dll" for Tcl 8.
-
Build Request zint.dll (Win32)
-
CI: macOS: use homebrew Qt PATH
-
CI: macOS: add Qt PATH
-
CI: Windows: try GS1 Syntax Engine with fixed CMakeLists.txt; try Qt
-
CI: Windows: leave GS1 Syntax Engine out
-
CI: Windows: fix GS1SE_ROOT; free-bsd: try offscreen for qt test
-
CI: free-bsd: remove -C from ctest
-
CI: macos: try qt; free-bsd: try explicit --config Release
-
CI: macos: try homebrew; free-bsd: fix build, try ctest
-
CI: macos: try LD_LIBRARY_PATH; free-bsd: try building
-
CI: Windows: shell missing?; macos: shared zlib/lpng install
-
CI: Windows: try with updated CMakeLists.txt; macos: try with PNG
-
CI: Windows: try with BUILD_TYPE
-
CI: Windows: try no BUILD_TYPE
-
CI: Windows: GS1 Syntax Engine cmake
-
CI: Windows: fix ${} syntax
-
CI: Windows: try GS1 Syntax Engine install again
-
CI: Windows: try non-relative XXX_ROOTs
-
CI: Windows: don'try GS1 Syntax Engine install
