Activity for Git Lost
-
Git Lost committed [a3f6c7] on Code
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
-
github ci: ubuntu: try installing GS1 Syntax Engine
-
And in tests cmake
-
cmake: fix GS1SE NOTFOUND test
-
Integrate GS1 Syntax Engine
-
general: fix some typos using https://github.com/crate-ci/typos
-
RAW_TEXT: change `source` to be unconverted, i.e. UTF-8 (unless
-
library: use "filemem" for TXT `dump_plot()` -> `txt_hex_plot()`
-
(Your posts got marked as requiring approval for some reason, hence the delay in them appearing.) Yes, it would mean the code would have to be written from scratch. As far as I understand things, it being LGPL and not GPL doesn't change things - it still has a viral effect at source level, so can't be integrated without the license applying.
-
Hi, yes it would be nice to support JAB Code and it is on the agenda at some stage. It having an open source encoder and decoder available already is huge, but the main problem is that the code is GPL licensed so we'd have to implement are own version to comply with our BSD-3-Clause licence.
-
Thanks Ulrich, done with commit [39380d]. It makes some of the source a bit "chunky" (e.g. bmp/emf/gif etc) but overall it clarifies it quite a bit I think. Went with just z_ prefix for "common.h" functions. Best regards, Martin
-
Tcl: run "autoconfig" and "./configure" after committing PR #9
-
backend_tcl: add tcl 9.0 compatibility define (CONST)
-
backend_tcl: configure tk
-
general: prefix all `INTERNAL` funcs/tables with `zint_`, except
-
Oh I see, I didn't know that. That's pretty crap from a library point of view - and it's quite surprising this issue hasn't been run into before. Will follow your advice, and prefix all INTERNAL functions with zint_, except probably the ones in "common.h" - will prefix them with just z_ - hope this will be enough. Thanks
-
Hi Ulrich, channel is marked INTERNAL, which is defined in "backend/common.h" as hidden, as long as ZINT_TEST and __MINGW32__ aren't defined, so shouldn't be visible outside the library. Could you do e.g. readelf -s ../../libs/libzint.a | grep channel on your zint library? It should list channel as GLOBAL HIDDEN. Thanks, Martin
-
gs1: update to latest gs1-syntax-dictionary (key -> gcppos1,
-
gs1: update to latest gs1-syntax-dictionary (keyoff1 for 8006/8026)
-
AZTEC/PDF417: stripf ecc feedback (was getting 32-bit difference)
-
iso4217: add 396 (XAD) ISO 4217 AMENDMENT NUMBER 179
-
DBAR_OMN/LTD: replace unnecessary `large_uint` with `uint64_t`
-
GS1PARENS_MODE: allow parentheses in AI data if backslashed and
-
Re commit [789e04] and [86363f] allow prefixes without check digit
-
- Add new symbologies `BARCODE_EAN8`, `BARCODE_EAN_2ADDON`,
-
Fix installation of cmake files
-
test suite: testcommon.c: NOLINT clang-tidy-20.1.2 false positive
-
EAN-8: specify in check digit error
1 >
