Activity for Git Lost
-
Git Lost committed [3b24d1] on Code
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
-
Re encodation, almost optimal algorithm added with commit [bcb3ce].
-
AZTEC: add almost optimal encoding algorithm, previous algorithm
-
Hi Harald, Terry, suggested change implemented with commit [cf5ef9], thanks!
-
GS1SE: exclude GS1_128 from requisite AIs check as may be spread
-
Excellent, thanks!
-
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
-
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.
-
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
-
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.
-
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 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, ...
-
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...
-
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.
-
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.
-
win32/vs2015: fix Release/Release_LIB sln files for MSVC2015,
-
Bump to version 2.16.0.9 (dev)
-
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
-
backend_tcl: enable "-gs1strict" for Unix
-
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.
-
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?
-
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...
-
Improve related build and compilation details
-
Please engage on ticket #341
-
Fix missing DLL error when opening
-
Please engage on ticket #341
-
Hi, did you read the section "CMake and Visual Studio" in the README file for Windows ("win32\README")?
-
general: `raw_segs` -> `content_segs`, `BARCODE_RAW_TEXT` ->
-
ECI: ECI 899 binary in `UNICODE_MODE` now converted from UTF-8,
-
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;
-
win32: add "zint_dll_vc6" sub-directory with VC6 workspace for
-
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
-
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.
-
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.)
-
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.
-
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
-
CI: Windows: try GS1 Syntax Engine install
-
CI: Windows: specify WIN32 for zlib/libpng
-
CI: Windows: try using libpng
-
CI: Windows: try slashes
-
CI: Windows: try installing libpng
-
CI: Windows: wot's in build?
-
CI: Windows: leave out zconf.h mv
-
CI: Windows: separate cmds
-
CI: Windows: try zlib again
-
CI: Windows: leave for now
-
CI: Windows: try installing zlib
-
CLI: `--gs1XXX` args now imply `--gs1
-
GS1 Syntax Engine: update Windows README and various project files
-
Suppress gcc-15 warning -Wunterminated-string-initialization
-
github: macos: forget it
-
github ci: macos: try hack around ldconfig not found
-
github ci: macos: try installing GS1 Syntax Engine
1 >
