QRCode - ECI and Structured Append

[Alex Dupre]

Hi All,
I'm going to use QRCodes to encode binary files. I know that zxing is
not suitable/designed for this scenario, but I'm looking for a guru
that could clear my doubts. I read the ISO/IEC standard (unfortunately
the 2000 revision, not the latest 2005) and also the ECI
specifications.

If I have understood all correctly, the "simplest correct way" to
achieve this is the use an ECI header to specify raw 8-bit data (ECI
000899 - no charset interpretation) and the structured append feature
to increase the total capacity. For every symbol it seems I have to
repeat the ECI header after the structured append codeword (I really
cannot get the reason for this requirement). All correct until now?

The "better correct way" to encode a file seems to need a few
additional features of ECI: instead of using the Interpretative
charset ECI header, I think I could use the Interpretative application
(launcher) ECI header (to save the encoded data as a file) and the
Transformation GZIP ECI header (to decrease encoded data length). The
application launcher header requires also an Interpretative Prefix ECI
header, to specify the file name or extension, but I could't find:
- how such "payload" should be encoded in a QRCode
- which character set should be used to interprete such "payload" (and
if can be changed)
- if such payload is to be considered in the structured append bit
parity
- what headers are required in subsequent structured append symbols

Anyone willing to help me? :-)

--
Alex Dupre

[Sean Owen]

I think that is all correct, up to my understanding. The library does not support Structured Append, but you could add it.

It is a lot easier to, say, point to a file with this data instead of encoding a bunch of bytes in a series of codes, but if you must do it this way yes I think you can do it. You would need a custom reader to do someting with the payload. That is, even with the right ECI, I would be surprised if any reader actually reads it as gzip. I don't know about specifying more metadata like the content type either, don't know if it's possible. 

Again, in comparison, an HTTP URL does this much much more easily, which is why nobody encodes a file in QR codes this way!

[Alex Dupre]

Sean Owen ha scritto:

> It is a lot easier to, say, point to a file with this data instead of
> encoding a bunch of bytes in a series of codes, but if you must do it
> this way yes I think you can do it. You would need a custom reader to do
> someting with the payload. That is, even with the right ECI, I would be
> surprised if any reader actually reads it as gzip. I don't know about
> specifying more metadata like the content type either, don't know if
> it's possible.

Well, I'm quite sure that 99.999% of the QRCode softwares/readers don't
support this approach (because they don't support structured append or
the processing of ECI designators other than standard character sets),
and this is the reason I have these doubts, I cannot compare/verify my
understanding with real codes produced via other systems.
Clearly it would be simpler to insert only a link to the file in the
qrcode, but my scenario has different requirements. I'm going to add
support for these features in both encodind/decoding, but to implement
them correctly I have to clear my doubts.
About the feasibility of the task, I have no doubts, but I have a few
about the ECI headers encoding.

First scenario: encoding raw binary data.

Using only the Interpretative Character Set ECI 000899 (8-bit binary
data) header seems quite straightforward, even if I don't understand why
the qrcode specification says such header should be put in every symbol
[1] (you have to decode all the previous symbols anyway, so it seems to
me just just a waste of space and an additional cause of confusion).

Sample meta-encoding of binary data ABCDEFGH:

First: (Structured append: 1 of 2) (ECI mode: 000899) (8bit mode: ABCD)
Second: (Structured append: 2 of 2) (ECI mode: 000899) (8bit mode: EFGH)

The parity data is to be calculated on "ABCDEFGH" [2].

Second scenario: encoding a compressed binary file.

For the compression, I have to use the Transformation Open Systems ECI
001800 (GZIP). I think this should be the last ECI Header before real
data encoding.
For the filename specification I have to use the Interpretative
Application Based ECI 800000 (Generic application launcher) [3] that
requires a previous Interpretative Prefix ECI [4] to specify the
filename. Such ECI header is a little different from the others, in the
sense that's not only identified by a number, but has also a payload
(the filename in this case), that's not part of the encoding data, but
should be encoded, too, in some way. I cannot find a description on how
to do it.

Sample meta-encoding of binary file "test.txt", assuming GZIP(test.txt)
= "ABCDEFGH":

First: (Structured append: 1 of 2) (ECI mode: 810899) [test.txt] (ECI
mode: 800000) (ECI mode: 001800) (8bit mode: ABCD)
Second: (Structured append: 2 of 2) [*] (8bit mode: EFGH)

The parts enclosed in [] are nebulous.

References:

[1] ECIs and Structured Append
Any ECI(s) invoked shall apply subject to the rules defined above and in
the AIM ECI specification until the end of
the encoded data or a change of ECI (signaled by Mode Indicator 0111).
If the encoded data in the ECI(s) extends
through two or more symbols in Structured Append Mode, it is necessary
to provide an ECI header consisting of
ECI Mode Indicator and ECI Designator number for each ECI in force,
immediately following the Structured Append
header, in subsequent symbols in which the ECI continues in force.

[2] Parity Data
The Parity Data shall be an 8 bit byte following the Symbol Sequence
Indicator. The parity data is a value obtained
by XORing byte by byte the values of all the original input data before
division into symbol blocks. Mode
Indicators, Character Count Identifiers, padding bits, Terminator and
Pad Characters shall be excluded from the
calculation. In ECI
Mode the 8-bit byte values obtained after any encryption or compression
of the data shall be used for the
calculation.

[3] Generic application launcher
The data within the scope of this ECI is in a standard file format
identified by the file name extension that is indicated by the
immediately preceding Interpretative Prefix ECI.

[4] Interpretative Prefix ECI
The interpretative Prefix ECI 810899 is invoked to provide a description
or tag or additional information which will apply to the following
Interpretative ECI. All of the test between the \810899 and the
backslash of the following Interpretative ECI is the prefix data.

[3] Publicly available ECI standard
http://www.aimglobal.org/standards/symbinfo/tsc-04-002%20eci%20pubrev.pdf

--
Alex Dupre

[Sean Owen]

I know little about Structured Append but if you have the spec I am sure you can add it; it's more a function of the client remembering it's expecting to concatenate the result of many scans.

The rest also sounds correct, though I also know little about ECI. The ECI stuff would apply with or without Structured Append.

If you have a custom reader that you control, I suppose you can do whatever you want, really, as long as your custom reader expects it. But yes I like the idea of trying to do the right thing with ECI anyway.

[Paulo Castro]

Good Morning,
I would like to know more about Structure Append, because I am doing a job where I want to create QRcodes with invisible characters, where only a certain APP can visualize, using the decode key. I would like to understand more and a framework or an example. Thank you in advance for your attention.

email: paullo...@hotmail.com