Barcode Font loaded but not embeded or used in PDF

#27034

Dear PD4ML Team,
We are trying to use your product (version pd4ml.pro.trial.398b2) to create a PDF with an embeded font from an HTML that displays a Barcode using the mentioned font.

We have managed to setup the PD4ML fonts properties file correctly and using the debug mode we can see that the TTF file for the Barcode font is actually loaded in cache during execution. However, the resulting PDF file does not have the font embeded and the Barcode is not visible.

An example HTML to test this would be as follows:

14CHEE000006316744.1sœ

14CHEE000006316744.1

The required “Code128bWinLarge” TTF font is freely available under: http://freebarcodefonts.dobsonsw.com/downloads/fonts/Code128FontWinInstaller.msi
(The Code128bWinLarge.ttf file can be extracted from the “.msi” file using a UNZIP tool).

Would you be able to have a look at this issue and see if we are doing something wrong or if it is a bug?

Thanks in advance,
Alex

#29796

Unfortunately WinZip does not recognize the .MSI as an archive. Also after I installed the tool, I found no traces of Code128bWinLarge on my workstation.

Could you please just send the TTF to support pd4ml com?

#29797

Hello,
Thanks for your reply and time to look into this issue.
The usual location for the font after the .MSI installation would be “C:WindowsFontsCode128bWinLarge.ttf”.
I have sent the font file to the PD4ML support e-mail address as requested.
Have a good weekend,
Alex

#29798

Thank you! We received the font. Hopefully we’ll have a chance to test/investigate the issue today.

#29799

After I copy-pasted your HTML snippet, I noticed the barcode data is followed (after ‘…744.1s’) by an invisible 0xC29C character. The character’s glyph is not defined by Code128bWinLarge.ttf. In the situation PD4ML unsuccessfully tries to find a TTF, which has a missing glyph data.

After I removed all content after the barcode data, it started to work correctly.

#29800

Hello Support Team,
Thanks for sharing your findings.
I believe the HEX character you mention (Hex: C29C, which is equal to ASCII: 156 and Unicode: 0153) is in fact the barcode’s End or “STOP” character and has in deed a graphical representation within the TTF. The list of all defined characters for this barcode font can be found here:
http://freebarcodefonts.dobsonsw.com/Code128Transformation.htm
Should PD4ML not accept this and other defined control characters?
Greetings,
Alex

[Anonymous]

#29801

Because of

Anonymous

#29802

Hello Support Team,
Unfortunately moving away from the Unicode UTF-8 standard is not an option in our project. The webpages to be converted will also hold international characters like the German umlauts (ö,ä,…) or the French accents (é,à,…) in other fonts.
In any case, what does not seem to be clear in your explanation of the solution is the problem itself. Why does PD4ML accept UTF-8 double char sequences for characters like “ü” which equals “c3 bc” in Hex, for example, but does not accept others like the STOP character “c2 9c” in the barcode example?
Greetings,
Alex

#29803

In your example document a character encoding is declared as UTF-8, but the barcode string itself is defined with windows-1251.

That inconsistence results some double byte sequences are interpreted wrong way (as Chinese glyphs, not present in the TTF font file).

There are two solutions:
1. to change the document encoding to windows-1251. As I see, it is not accepteble by you.

2. to represent the barcode string as correct UTF-8: to change 153 (0x99) -> 0x2122, 151 (0x97) -> 0x2014, etc
(See the bottom part of the code table on http://freebarcodefonts.dobsonsw.com/Code128Transformation.htm )

The codes can be written using HTML entities i.e. ™ — …

#29804

Thanks for the reply.
My understanding is that the barcode string our example is UTF-8 encoded. See, for example the “Encodings” section in the following webpage for the Unicode character 0x0153 (the barcode STOP character):
http://www.fileformat.info/info/unicode/char/0153/index.htm
The UTF-8 (hex) representation of this character is “0xC5 0x93 (c593)” which is exactly what can be found in our example file at the end of the barcode string.
Am I misunderstanding or overlooking something?
Regards,
Alex

#29805

In UTF-8 “0xC5 0x93 (c593)” corresponds to http://www.fileformat.info/info/unicode/char/c593/index.htm
which is definitely not correct.

> My understanding is that the barcode string our example is UTF-8 encoded.

The simplest test to ensure your doc is wrongly encoded would be to open the document in a web browser. After that change the encoding to windows-1252 and open the doc in another tab. Compare and you’ll see the barcode appears slightly different (prefixed and postfixed in the second case). In the first case the start-stop chars are not displayed (until CJK fonts pack installed).

> the Unicode character 0x0153 (the barcode STOP character)

It is not correct. 153 is not hex, but decimal ASCII value (= 0x99), which is in UTF-8 should be encoded as 0x2122

See
http://freebarcodefonts.dobsonsw.com/Code128Transformation.htm

[Author]

Posts