Normalizing Carriage Returns and Line Feeds

[Phunky]

Is it common to normalise Carriage Returns and Line Feeds within data before producing a symbol?

If not this would mean that the value of the symbol could differ depending on the OS it was produced on and that feels a little off.

Has anyone even hit this problem themselves before?

[terryburton]

Think of BWIPP (an barcode symbologies themselves) as being too fundamental for this concern and of this being an application-level issue.

Essentially BWIPP passes a PostScript string (byte array) to each encoder which faithfully stores what it is given in a barcode symbol. Compliant scanners simply return the byte array, unless ECI is present and supported: https://www.linkedin.com/pulse/enhanced-channel-interpretation-terry-burton/

Some of the encoders in BWIPP are "helpers" that process the data (e.g. convert bracketed GS1 AI syntax to a raw message) before sending it to a base symbology, but these relate to industry-specific formats rather than general character/string encoding.

The following shows an example of how frontends can hexlify a string to pass it precisely to BWIPP:

https://github.com/bwipp/postscriptbarcode/wiki/Developing-a-Frontend-to-BWIPP#safe-argument-passing

As far as storing structured data such as VCARD within a symbol (of any type), then refer to the specification itself which is typically under specified. Then do whatever is necessary to ensure interop. The barcode is just a dumb medium: bytes in, bytes out.

[Phunky]

Think of BWIPP (an barcode symbologies themselves) as being too fundamental for this concern and of this being an application-level issue.

Understood, they just take the data provided and output the symbol. It's up to the user to ensure this is consistent, which sadly isn't possible via the web as the DOM will automatically normalise \r\n to \n which can then produce a different visual symbol, but the underlying value would be the same apart from the line ending.

Essentially BWIPP passes a PostScript string (byte array) to each encoder which faithfully stores what it is given in a barcode symbol. Compliant scanners simply return the byte array, unless ECI is present and supported: https://www.linkedin.com/pulse/enhanced-channel-interpretation-terry-burton/

Thanks for the link to the ECI, i'll have a proper read of that now as that maybe the correct way of handling this.

[terryburton]

ECI isn't supported by all readers, especially mobile app components since the "channel" (reader-host interface) is abstract in this use case.

Many/most mobile app readers simply stuff the extracted bytes into the GUI toolkit's text widget then rely on the toolkit or OS's heuristics to select a character encoding for the string, completely ignoring the intent provided by ECI. It's the worst case as things seem to work fine until they don't! Things are slowly improving in this regard.

Processing the user-provided text and passing a hex string to PostScript is likely to be the most robust approach for dealing with line endings.

ECI however is certainly something to consider if your data isn't provided as (or cannot be mapped to) Latin-1.