Hi, Esteban -
First, I want to thank you for including the zip file in your question, it was very helpful. I wish more people were as thoughtful as you when asking a technical question.
I think I have an explanation for you, but there are several factors in play that I need to explain in order that you gain an understanding of the "big picture", so please forgive the length of this reply:
1. The "Bars 2 Font" TrueType font named "B2Fi25HRc.ttf" is dated 2003 (Right-click the .ttf file and view properties, then the Details tab), and because of its age, I suspect this font was designed as an ASCII font.
2. After installing the font, I used the Windows Character Map utility to examine the code points for the 102 glyphs (the displayable character patterns) that are required for a Code 2 of 5 Interleaved font. There are 100 glyphs for the barcode characters representing the digit pairs "00"-"99", along with the Start and Stop barcode characters.
3. Having previously looked at several barcode TrueType fonts with the Character Map utility over the last couple of years, I noticed immediately the very unusual mapping of the code points. The glyphs for "00" - "49" are mapped to a sequential set of code points: 0x30 - 0x61 (Decimal 48-97). The start barcode character maps to 0x7B (123) and the stop barcode characters maps to 0x7D (125). The remaining 50 glyphs for "50" - "99" are mapped to another sequential set of code points: 0x96 - 0xC7 (Decimal 150-199).
4. While looking at the PDF (the image in your post), I noticed the barcode characters that did not render correctly were the characters for "60", "59" and "51", all reasonably close to one another.
5. This made me curious as to what the character map code points for a "normal" TrueType font look like, and I chose Calibri to start with. Interestingly, it has no glyphs assigned to code points in the range of 0x7F - 0xA0 (Decimal 127-160). Other similar fonts (Tahoma, Segoe UI) were laid out in a nearly identical pattern with only minor differences.
6. The first 11 glyphs in the second set of 50 in the B2Fi25HRc.ttf font are assigned to 0x96 - 0xA0 (Decimal 150 - 160). These happen to be the glyphs for the barcode characters "50" through "60", which is the range that includes the barcode characters that do not render correctly for you. That clue resulted in the A-ha! moment.
It appears that somewhere in the DataWindow to NativePDF rendering process when an ASCII-based font is being used, there are some characters that do not make it through the various translations correctly. I presume it is because the code table being used by the NativePDF generator does something that causes the characters to render incorrectly.
It's not clear from your post as to how you are encoding the numeric sequence for the barcode, but I will assume you are using normal (Unicode) string operations. I believe if you construct the encoded barcode data as an ASCII string, you'll find the results more to your liking.
To illustrate, here is the DataWindow expression for a computed field that constructs a (Unicode) string containing your barcode font's code points for the characters "48" through "61":
/* "48" "49" "50" "51" "52" "53" "54" "55" "56" "57" "58" "59" "60" "61" */
Char(96) + Char(97) + Char(150) + Char(151) + Char(152) + Char(153) + Char(154) + Char(155) + Char(156) + Char(157) + Char(158) + Char(159) + Char(160) + Char(161)
And here's how this computed field displays with the B2Fi25HRc font:
If I change all of the Char(nn) functions in the expression to CharA(nn) to produce an ASCII string:
CharA(96) + CharA(97) + CharA(150) + CharA(151) + CharA(152) + CharA(153) + CharA(154) + CharA(155) + CharA(156) + CharA(157) + CharA(158) + CharA(159) + CharA(160) + CharA(161)
This renders a little better:
I hope this helps. Let me know if you have additional questions.
Best regards, John
