ZPL, QR, and Carriage Return

[johnsont53]

Is there a way to insert a carriage return into a QR barcode?

I'm looking at an example from a customer's other supplier and I just can't figure it out. My data string is tied together and does not scan like the example barcode does, where each element is a new line. Say I need five elements of data in the QR code; I can't make a new ^FO/^BQ because that would be a new barcode. So, I've run out of talent on how to decipher this. One thing I did obviously try is scanning the other label for clues and nothing...

I'm not sure how to make this more clear if it is confusing so I apologize and can certainly rephrase my question if needed.

 

[JRB-Bldr]

Is there a way to insert a carriage return into a QR barcode?
By doing a Google search for: "QR barcode" "Carriage Return" I found the following:
You simply encode it by putting the correct byte sequence into the QR code. Assuming you're using the default ISO-8859-1 encoding, that's just the single byte 0x0D.

You might want to look at:

http://www.yulebiao.com/questions/8422042/qr-barcode-carriage-return

Good Luck,
JRB-Bldr

 

[johnsont53]

I see that the Google chart link puts in the line feeds and does scan just fine but that is their API doing the magic.

I need to know how to generate the same carriage return/line feed behavior using ZPL and I can't figure it out.

 

[DansDadUK]

A quick perusal of the ZPL II Programming Guide manual (

http://www.zebra.com/content/dam/zebra/manuals/en-us/printer/zplii-pm-vol2-en.pdf

) describes (on page 105) how to disguise control-code characters (which could otherwise be unintentionally interpreted by the transmission protocols) in such a way that the Zebra printer can recover the disguised control-code byte in the data.

In essence, you have to send a <SUB> control-code byte (hexadecimal 1A), followed by a byte which has a value of hexadecimal 40 greater than that of the required control-code character.

So to transmit a <CR> (Carriage Return) control-code byte (hexadecimal 0D) would seem to require that the data stream contains two bytes:

hex 1A
hex 4D

Note that hexadecimal 4D is the upper-case M in coded-character sets based on ASCII.

I know very little about ZPL, so have no idea if this applies to your situation. It seems to imply that all of the hard work of generating the bar-code (which is considerable for 2-D codes such as QR Code) is done within the printer.

 

[JRB-Bldr]

ID Automation (

http://www.idautomation.com/barcode-faq/2d/qr-code/#Encoding_Double_Byte

) says the following:
QR Code allows ASCII codes to be easily encoded for various functions such as Tabs and Returns (a.k.a. Carriage Returns). These functions are not usually visible when scanned unless the Barcode Scanner ASCII String Decoder is used with a scanner that has lower ASCII capability such as the Metrologic Focus, the HHP 4600 Imager or IDAutomation 2D Barcode Scanner with Control + ASCII mode enabled.

In all IDAutomation products, the tilde (~) may be used to encode ASCII functions according to the documentation. For example; ~d009 is used to encode a tab and ~d013 encodes a return (a.k.a. Carriage Return). In many development environments, Chr or Char may also be used to encode the ASCII value directly. For example, the programming examples below encode "ECC" <tab> 200:

Examples
* Java: DataToEncode= "ECC" + (char)9 + "200";
* Visual Basic: DataToEncode= "ECC" & Chr(9) & "200"

So I guess that the issue comes down to - what software are you using to write to your barcode printer?

Some software applications will want you to use one method to send the Escape character and another might require something different.

If you have written your own code, you can make it do what you want.
If you are using someone else's off-the-shelf application, then you need to contact them for an answer.

Good Luck,
JRB-Bldr