Code 128 - Possibly invalid output - Check digit shown, Code-C issues

[Zilhym]

The following are a few sample codes that seem to render incorrectly, and also there are a few differences between the .woff2 available on Google Fonts and the .ttf versions.

Encoded         Original        As displayed on web browser (.woff2)
-------         --------        ------------------------------------
Í  #;É-1ÈÎ      00000327-1      000327-1
Í  #<É-1!Î      00000328-1      000328-1
ÌPa-KKKBN-198UÎ     Pa-KKKBN-198    
ÌEC-10mDÎ       EC-10m
ÌEC-2myÎ        EC-2m
ÌEC-72mfÎ       EC-72m
ËBA-AP-LiÎ      BA-AP-L
ËASDL-260RÎ     ASDL-260
ÌBa-GBP-L9Î     Ba-GBP-L
ÌBa-GBP-SqÎ     Ba-GBP-S
ÌBA-P-RackÅÎ        BA-P-Rack
ÌBa-LBP-SÉÎ     Ba-LBP-S

The Code-C codes (first two) show up incorrectly on both Windows (Word/WordPad/Notepad) and Web Browser. Code-C sequences of zeros (00s) do not show up on web browser unless possibly followed by some other (non-space) character. The rest, except the last two display the check digit, which I believe should be suppressed/invisible. On Microsoft Edge, the print (i.e. Print Preview, Print to PDF) is garbled further.

The encoding was done using an algorithm ow my own devise, designed to attempt to produce optimal (shortest possible) codes when possible. I haven't yet found any problem or inconsistency in the encoder/decoder. One locale specific string-comparison issue recently discovered has already been fixed. The problems seem to be with your fonts.

I haven't yet published the Encoder/Decoder .NET libraries or the Source Code.

See also (for example):

Í "Î

[graphicore]

Hi @Zilhym, thanks for reporting.

The encoding was done using an algorithm ow my own devise, designed to attempt to produce optimal (shortest possible) codes when possible. I haven't yet found any problem or inconsistency in the encoder/decoder.

Good news first! I just cross checked your encodings with my Code 128 Encoder and the results are consistent. Despite of the two Code-A lines, where my encoder also uses Code-B, but it's equivalent in length and encoded value.

The problems seem to be with your fonts.

Since I have no issue displaying those codes in Firefox and Chrome (on Linux) and since Microsoft Software is known to be problematic in its support of OpenType features, I tend to think this is a duplicate of #34 i.e. missing support for the calt OpenType feature or something similar. Especially for Word have a look at https://github.com/graphicore/librebarcode/issues/28#issuecomment-745736391 maybe this can fix it.

What web-browser does produce incorrect renderings?

and also there are a few differences between the .woff2 available on Google Fonts and the .ttf versions.

This sounds not good to me, I'm not sure if it needs to be followed up. Of what nature are the differences?

In general, you can drop screenshots into these issues, that can greatly help with identifying what is going on.

[Zilhym]

Google Fonts

00000327-1 shows up as 000327-1

00000328-1 shows up as 000328-1

0000000000 shows up as 00

These results were on Firefox for Windows (and possibly on Microsoft Edge on Windows). This was one of the differences I mentioned between the .ttf rendering on Windows Applications and the .woff2 on the web browser. The workaround suggested, of substituting SPACE with  (LATIN CAPITAL LETTER A WITH CIRCUMFLEX) seems to fix this issue. If I find any other differences I'll post them later.

Is the space substitution really always necessary, even on Web Browsers? If the above substitution is always safe in all contexts. maybe I should update my encoder to always substitute spaces? Any other substitutions or workarounds I should be aware of (Any place I can find a complete list)?

If you think the .ttf issues are Microsoft Software bugs or Software Bugs in general, can you suggest an application (possibly available on PortableApps.com) for Windows, that does work correctly?

This is a sample of what I get on Word, and possibly WordPad as well as Notepad. Barcodes.pdf If I could at least get the .ttf working in Crystal Reports, I would be happy for now.

Do you believe the visibility of the check digit is also caused by the calt issue? It does seem to work correctly for at least two codes.

I did a few tests before, but didn't keep a record of all the results. Need to do more tests.

If you think I'm using your fonts incorrectly, please let me know...

[Zilhym]

Ah, I figured out what was wrong on the browser. It was just a white-space collapsing issue. Adding white-space: pre to the barcode display CSS style fixed that particular issue. Same issue on Google Fonts page, I expect. What gave me the hint was the CSS style of your encoder page.

[Zilhym]

Your encoder doesn't seem to encode control characters (Code-A ?). Have you tested that? I tried the implementation at graphicore.github.io

I got a null return. What did I do wrong?

console.log(encode('\x10ABCDEFG'))
console.log(encode('A\0B'))

[graphicore]

Is the space substitution really always necessary, even on Web Browsers? If the above substitution is always safe in all contexts. maybe I should update my encoder to always substitute spaces? Any other substitutions or workarounds I should be aware of (Any place I can find a complete list)?

I take this as a feature request to add an option to the encoder that outputs Â.

Your encoder doesn't seem to encode control characters (Code-A ?)

I don't think that type of input was really considered, because the use case was just user-input in a web browser. But I appreciate the suggestion and will look into it together with #46

It was just a white-space collapsing issue. Adding white-space: pre to the barcode display CSS style fixed that particular issue. Same issue on Google Fonts page, I expect. What gave me the hint was the CSS style of your encoder page.

This will have to be documented.

Do you believe the visibility of the check digit is also caused by the calt issue? It does seem to work correctly for at least two codes.

Well, since the invisibility of the check digit is actively made by a calt rule, I have to. But it's also possible that the rule itself is insufficient. More info would be appreciated.