From 22ba06a7cbe8e933b73cc55a9a18beb8f0450708 Mon Sep 17 00:00:00 2001 From: Harald Oehlmann Date: Mon, 6 Apr 2020 17:49:45 +0200 Subject: [PATCH] Add recent changes to README. Add a note to the manual to explain why --fullmultibyte may be an issue. I am not completely satisfied of the position of this note, as it is symbology specific comaction, but it interferes at least with ECI described below. --- README | 13 +++++++++++-- docs/manual.txt | 23 +++++++++++++++++------ 2 files changed, 28 insertions(+), 8 deletions(-) diff --git a/README b/README index a017072e..c142c5ca 100644 --- a/README +++ b/README @@ -132,7 +132,15 @@ Bugs: Version 2.7.2 Not released jet Changes: -(New) Tests for auspost, codablock, composite, dotcode, general, telepen, upcean +(New) Tests for auspost, codablock, composite, dotcode, general, telepen, upcean, + all output formats, +- QR, Han Xin, Grid Matrix: the multi byte compaction schemes (ex: Kanji) + are used by some decoders as codepage information (Ex: GB2312) and output + may be translated to UTF-8. This may destroy the data in a not controlable + manner. + In consequence, multibyte compaction schemes are disabled by default. + The new option --fullmultibyte (option_3 = ZINT_FULL_MULTIBYTE) enables this + optimisation. Bugs: - Ticket 181 penetration test found many bugs: - Auspost: null bytes in content caused segfault @@ -144,12 +152,13 @@ Bugs: - EANUCC: buffer overflow on multiple + (multiple extension bars) - Maxicode: index overrun on numeric compaction - CodeOne: Simple i indexing not sp + i in C1_ASCII numeric latch loop. - - Aztec: free memory, + - Aztec: free memory - Ticket 183: Databar stacked separator correction - Ticket 182: Output bitmap type was char, where some targets assigned 0 if pixel colour >127 (e.g. negative). API change to use unsigned char. - HanXin: wrong codepage, gb2312 instead gb18030. - PDF417: corrected alloced sizes to max characters +- Ticket 189: FNC1 encodation fixed (FLG(0) missing after FLG(n)) CONTACT US ---------- diff --git a/docs/manual.txt b/docs/manual.txt index 35cabb6e..5dc83fda 100644 --- a/docs/manual.txt +++ b/docs/manual.txt @@ -428,15 +428,26 @@ HIBC data may also be encoded in the symbologies Code 39, Code128, Codablock-F, Data Matrix, QR Code, PDF417 and Aztec Code. Within this mode, the leading '+' and the check character are automatically added. -The --binary option prevents Zint from performing any convertion of the data -before placing in the barcode symbol and should be used if you are encoding raw -binary or encrypted data. For an example involving QR Code and UTF-8 encoding, -see Ex3 below. +The --binary option encodes the input data as given. Automatic code page +translations to ECI pages is disabled. This may be used for raw binary +or binary encrypted data. +This switch plays together with the build-in ECI logic and examples may +be found in that section. The --fullmultibyte option uses the multibyte modes of QR Code, Micro QR Code, Rectangular Micro QR Code, Han Xin Code and Grid Matrix for binary and Latin -data, maximizing density. You should check your barcode reader supports this use -before enabling it. +data, maximizing density. +Please check your reader device for not having the following +non-standard property: this option may switch to multibyte (ex. Kanji) +compression within the code to obtain a smaller code matrix. The Kanji mode is +a compaction mode and does not inform about contained Kanji characters. +Nevertheless, some decoders take blocks which are encoded in Kanji +compaction and output them as Kanji characters, typically be applying a +transformation to UTF8. The result is unpredictable, as zint +--fullmultibyte chooses the compaction type only on the criteria to +obtain smaller codes and not to inform about the presence of Kanji +characters. +An example decoder with this property is the zxing decoder app. If your data contains non ISO-Latin-1 characters, you may encode it using an ECI-aware symbology and an ECI value from the table below.