Function Characters?

[Rex-On-GitHub]

Hello!

Sorry if this is the wrong place to ask this question. I would like to make a GS1 DataMatrix code, but it needs an FNC1 character to be encoded. Can I do this with iec16022?

Thanks! Rex

[rdoeffinger]

As far as I can tell FNC1 is simply a byte of the value 232. So all you need to do is pass it a string with that. On Linux, something like this should do it: ./iec16022 -f UTF-8 "$(printf \xE8test)" I don't have reader that understands GS1 data matrix though to check.

[Rex-On-GitHub]

Thanks for your response rdoeffinger.

I see that I am running 2.4, so I do not have the UTF-8 format. I am having trouble using make on my linux distro with the source code I downloaded from the releases page. Attempting to follow the INSTALL directions, I simply type "make" which results in "make: *** No targets specified and no makefile found. Stop." or "make -f Makefile.am" which results in "make: *** No targets. Stop."

Obviously I have never ran make before. Am I performing the install incorrectly?

In the meantime, I know that this site identifies the FNC1 and notes the DataMatrix as a GS1 code if you want to test your output before I get through the install: https://online-barcode-reader.inliteresearch.com/default.aspx .

Thanks for your help. Rex

[rdoeffinger]

You don't need the UTF-8 output, it's just more convenient than having to use an image viewer to see and test the result. Due to the numerous and somewhat serious bugs you'll probably want to use a newer version anyway though. I fixed the instructions, in particular autogen.sh and configure were missing. I hate autotools and the extra complexity they create but I don't want to replace the build system for now. In addition my comment was wrong. The GS1 specification is a mess. FNC1 is encoded as byte value 29 (\x1D), however that only applies if it is used as a separator. A FNC1 at the start is simply encoded as ]d2. Thus encoding the string "]d200123456780000000001" results in a GS1 datamatrix.

[rdoeffinger]

Sorry, was wrong. Those specifications are truly horrible. I added a --gs1 flag that adds a proper FNC1 at the start. It also removes any possible ]d2 identifier at the start. FNC1 in the middle still won't work, at least if they need to be encoded as FNC1 (some specs talk about using the GS ASCII code instead, but it is unclear if that is only the representation on the DataMatrix decoder output side or if it is allowed inside the DataMatrix code).

[Rex-On-GitHub]

Wow! Thanks rdoeffinger! I was able to update to the master file with your updated install doc (I did not have any of the autotools installed). You definitely have the GS1 tag working, thanks! I will do some attempts for the separation character and let you know.

Also, for that online code reader link I posted earlier, I needed to scale up the image in GIMP since it can't read the single-pixel PNG iec16022 generates. From what I recall on using other software, it should show {GS} if it is correct.

[Rex-On-GitHub]

Alright! I think you got it! I was able to duplicate the results from an image from a GS1 guidance doc. From guidance:

Generated:

The actual datamatrixes look a little different though. I plan to have access to a verifier soon so I can test it out more rigorously.

Thanks again for your help rdoeffinger!

[mgaffigan]

I was able to hack around this by adding an if to check s[sp] == 232, 233, 234, 236, 237 before jumping to high-ASCII at line https://github.com/rdoeffinger/iec16022/blob/aaa2a2c556eee4d81478cc48f708b9aef6fcc14e/iec16022ecc200.c#L405

else if (s[sp] == 232 /* FNC1 */ || s[sp] == 233 /* Structured Append */ || s[sp] == 234 /* Reader Programming */
    || s[sp] == 236 /* 05 Macro */ || s[sp] == 237 /* 06 Macro */)
{
    // Already a raw codepoint
    t[tp++] = s[sp++];
}

[rdoeffinger]

This is a closed ticket, so visibility of comments is pretty poor. It might make sense to open a new ticket instead. I am also unclear what the "this" is you could hack around, I guess you mean enabling to encode these special codes like FNC1? The problem is that it comes at the expense of not being able to encode these ASCII characters anymore. But since I seem to have added a --gs1 flag already, I guess what you did could make sense if you made it conditional on that flag being specified?

[rdoeffinger]

Let me reopen it. I think your code might in some cases still result in wrong encoding. I didn't test it at all, but could you check and test: https://github.com/rdoeffinger/iec16022/pull/21

[mgaffigan]

@rdoeffinger, thanks for responding. I was only adding it to this ticket in case someone else runs into it. I did attempt use of the --gs1 option, but did not find it to meet our needs since it did not seem to handle FNC1 characters other than at the first character.

I don't think I understand your comment about not being able to encode these ASCII characters (since the codes are all outside of the 0-127 ASCII space defined in the standard). For ISO-8859-1 characters in the range 128-255, I would presume the Base 256 encoding would be required.

[rdoeffinger]

It is not an encoding problem, the problem is on the input side. If you define a character value of 232 to mean FNC1, how would a user be able to encode the character è ? Same for UTF-8 sequences that might contain that character value. One option would be to come up with some kind of escaping scheme to allow to specify either, but that is a bit of a pain. So my proposal to get something that can be merged is to do it in such a way that the default behaviour is unchanged and 232 would be encoded as such (representing e.g. è ). But with --gs1 instead assume that if 232 appears it is meant to represent FNC1, like your patch does. Apart from that, your patch isn't comprehensive enough and you can still run into cases where FNC1 would not be encoded as FNC1. This I would like you to check/review/test my proposed patch, as that should be a better path to a reliable solution.