I'm trying to find a solution to print superscript using ZPL.
Example, if I have this string of ZPL:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FDHello, World!^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
Since there aren't any superscript characters, I could send this to my printer without issue. But if I wanted to use this string:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FDe = mc²^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
The superscript won't print natively. I think I need to access an international character set or something but I'm not sure how to do this, especially if I only need it for the one character. Do I need to change my entire character set, or do some sort of "replace" on it?
Note, we are generating ZPL code manually and shooting it directly at the printers (unfortunately this is our system), bypassing any drivers or 3rd party dev components of any kind.
Mark's answer gave me exactly what I needed to solve my issue. Here is additional information to further clarify the solution:
To use the hex code in your data you need to prefix the ^FD command with ^FH_ (where ^FH tells the printer the data in ^FD will contain hex values and the _ defines the hex code identifier so it knows which data is or is not defined as a hex code instead of standard text)
I got this to work immediately exactly as you mentioned. Then testing against additional printers I found (but not sure why) that I didn't need to actually send in the ^CI13 to specify code page 850. The ² appeared on all printers even when I didn't send the ^CI13
In my .NET application, for some reason the ² didn't map to the correct hex code that the ZPL code page expected (the .NET app converted ² to hex code b2 instead of fd, but for most standard characters converted to the same code as the ZPL map) so in my application I created a conversion table where any character I defined in my table I mapped to the ZPL hex code and any character I didn't define I allowed to remain as converted by the application).
I'd never used information from the non default code page and I didn't realize when using ^FH that you could mix standard text with hex (I thought if you used ^FH that "all" of the information in ^FD had to be hex). So the information Mark provided let me right down the correct path.
The final example to solve the problem, using the information Mark provided, is:
string ZPLString =
"^XA" +
"^FO50,50" +
"^A0N50,50" +
"^FH_" +
"^FDe = mc_fd^FS" +
"^XZ";
sendToZebraPrinter(ZPLString);
Try using ^CI13 to select code page 850, then use _fd in your string for the superscripted 2. The underscore is used to designate a hex character.
Related
In the past, we've used ZPL to create Code39 barcodes with a TAB character encoded in the middle using something similar to the following:
*USERNAME$IPASSWORD*
The $I in the middle gets translated to a TAB by the barcode scanners we use.
Now we have a need to do the same thing, but using Code128. With Code39, all the text needs to be uppercase (unless you're using Code39Extended, which supports lowercase letters). Because some of the data that is going to be encoded will be lowercase, we need to use Code128 B for most of the barcode, switching to Code128 A in the middle to encode the TAB character, then back to Code128 B for the final part.
Looking through the "ZPL II Programming Guide", it should be as easy as:
>:username>7{TAB}>6PA55w0rd
The >: at the beginning sets the subset to B, the >7 changes the subset to A, and the >6 changes the subset back to B. The problem I'm having (and haven't found a solution after almost a week of searching) is: How do I encode a TAB character using only text?
Use the ^FH (field hexidecimal encoding) command immediately prior to your field data. Based on your example:
^FH_^FD>:username>7_09>6PA55w0rd^FS
Where the underscore '_' is used as the escape character and 09 is the hex value for tab.
Also note that if the chosen escape character appears in the user name or password, you will need to escape it as well.
I tried what Mark Warren suggested, but unfortunately, it didn't work. It did, however, get me looking back through the ZPL II Programming Guide and I found the following, which I had overlooked before:
Code 128, Subsets A and C are programmed in pairs of digits, 00 to 99, in the field data string.
...
In Subset A, each pair of digits results in a single character being encoded in the bar code...
So, since 73 equates to a TAB in Subset A, I tried the following:
>:username>773>6PA55w0rd
And it worked!
i was expecting this command
^FO15,240^BY3,2:1^BCN,100,Y,N,Y,^FD>:>842011118888^FS
to generate a
(420) 11118888
interpretation line, instead it generates
~n42011118888
anyone have idea how to generate the expected output?
TIA!
Joey
If the firmware is up to date, D mode can be used.
^BCo,h,f,g,e,m
^XA
^FO15,240
^BY3,2:1
^BCN,100,Y,N,Y,D
^FD(420)11118888^FS
^XZ
D = UCC/EAN Mode (x.11.x and newer firmware)
This allows dealing with UCC/EAN with and without chained
application identifiers. The code starts in the appropriate subset
followed by FNC1 to indicate a UCC/EAN 128 bar code. The printer
automatically strips out parentheses and spaces for encoding, but
prints them in the human-readable section. The printer automatically
determines if a check digit is required, calculate it, and print it.
Automatically sizes the human readable.
The ^BC command's "interpretation line" feature does not support auto-insertion of the parentheses. (I think it's safe to assume this is partly because it has no way of determining what your data identifier is by just looking at the data provided - it could be 420, could be 4, could be any other portion of the data starting from the first character.)
My recommendation is that you create a separate text field which handles the logic for the parentheses, and place it just above or below the barcode itself. This is the way I've always approached these in the past - I prefer this method because I have direct control over the font, font size, and formatting of the interpretation line.
I am maintaining a program that outputs ZPL to a label printer. Today, the character sequence ~Ja came in as part of a string to be printed, which is ZPL's "cancel all" command. Needless to say, the label did not print.
Is there an easy way in ZPL to escape a tilde?
You can use ~CT or ^CT to change the tilde control character to any other ASCII character, and then you can print tildes normally. However, the new control character won't be printable. This is probably going to be quite a hassle to maintain.
An example changing the control command prefix to +, taken from page 165 of the ZPL II programming guide:
^XA
^CT+
^XZ
+HS
If your string is represented as field data with ^FD, ^FV, or ^SN, you can use ^FH to encode the tilde in the string with its hex value, 7E.
An example, taken from page 192 of the ZPL II programming guide:
^XA
^FO100,100
^AD^FH
^FDTilde _7e used for HEX^FS
^XZ
Output:
Tilde ~ used for HEX
~ can be printed by replacing to \7E
It seeems like replacing these three characters will allow any key on the keyboard to print fine. I figured this out using ZebraDesigner, printing to a file and seeing what characters they escape.
\ to \1F - do this first or it will break the two below
~ to \7E
^ to \5E
Here is the code in C#
private static string escapeChars(string working)
{
working = working.Replace(#"\", #"\1F");
working = working.Replace(#"~", #"\7E");
working = working.Replace(#"^", #"\5E");
return working;
}
I have my database results (áéíóúàâêô...) and when I display any of this characters I get codes like:
á
My controller is like this:
ViewBag.EstadosDeAlma = (from e in db.EstadosDeAlma select e.Title).ToList();
My cshtml page is like this:
var data = '#foreach (dynamic item in ViewBag.EstadosDeAlma){ #(item + " ") }';
In addition, if I use any rich text editor as Tiny MCE all non-latin characters are like this too.
What should I do to avoid this problem?
What output encoding are you using on your web pages? I would suggest using UTF-8 since you want a lot of non-ascii characters to work.
I think you should HTML encode/decode the values before comparing them.
Since you are using jQuery you can take advantage of the encoding functions built-in into it. For example:
$('<div/>').html('& #225;gil').html()
gives you "ágil" (notice that I added an extra space between the & and the # so that stackoverflow does not encode it, you won't need it)
This other question has more information about this.
HTML-encoding lost when attribute read from input field
I'm trying to save variables into text files and the Czech typographic rules drives me crazy.
The program I'm tuning is dedicated to work on Czech localized computers where decimal comma is used but the VB is working with normal, standard decimal dot.
When loading files "US" decimals are loaded correctly and showed as Czech decimals. In TextBoxes "Czech" decimals are required. My problem is that program generates Czech decimals and require the "US" ones.
How can I force VB program to read comma as decimal sign instead of delimiter or how to export data with dots instead of commas?
Yes I can load 123,456 as a=123 and b=456 and then return value as a + b/1000 but is there more elegant solution?
Pick the right function.
Val, Str will always use US settings (dot as decimal)
CDbl, Format will take account of the regional settings.
It's all in the manual section on international programming.
Your trouble might be due to use of the Val function; that isn't international. The help text recommends the use of CDbl when converting from strings to numbers.
Thanks for your advices, I'm not sure if I did something wrong, but I've obtained only errors (ie. type mismatch) or "Czech" decimal comma.
I've tried 'Got slapped? Slap him harder!' aproach with this code:
Dim PpP As String, SaveFile As Integer
PpP = Form1.TxtA10.Text & " " & Form1.TxtA11.Text
PpP = Replace(PpP, ",", ".")
Print #SaveFile, PpP
edit:
something means trying those functions at the output, not at the input. (like trying Double as String parameter).
This code:
Input #1,TempString
Form1.TxtA10.Text = CDbl(TempString)
works aswell.
Try,
Format$(CDbl(Text1.Text), "#,##0.00")