Log in / Register

Forum › Bugs

Unicode dingbat renders OK on Mac; glyph not found on Linux

Chris Thorman 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<body>
<p>Maltese cross: <span style="font-family: Zapf Dingbats">&#x2720;</span></p>
</body>
</html>


The above test file correctly renders a maltese cross dingbat using the Zapf Dingbats font, using prince 6.x on Mac OS X.

On my Linux box, I installed the ITC Zapf Dingbats font from http://fonts.com/ (along with some other non-symbol fonts). The other fonts (e.g. Sabon, etc.) work just fine with prince 5.1 and 6.x.

I can verify that Zapf Dingbats is installed under that name:

fc-list | grep -i ding
Webdings:style=Regular
Dingbats:style=Regular
Caladings CLM:style=Regular
Zapf Dingbats:style=Regular

Yet when I use prince to render the test on Linux, I get this error:

prince: warning: no glyphs for character U+2720, fallback to '?'

(And of course a ? appears in place of the intended glyph.)

Could it be that the .ttf version of Zapf Dingbats sold by http://fonts.com/ does not contain the entity encodings required to map Unicode dingbats to the proper glyphs? If so,

1) What is the solution for rendering this glyph?

2) What is the recommended way of inspecting the capabilities of .ttf fonts on the Linux side? Does Prince have any debugging options that will help troubleshoot the font environment?

-c
mikeday
If the font does not have a UNICODE character map then Prince will not be able to find a glyph for U+2720, so that could be the reason. Glyphs in fonts with no UNICODE character map can sometimes be accessed via the private use area codepoints, from U+F000 onwards, so you could try referencing a few characters like U+F020 and U+F040 and see what you get.

Running Prince with the --debug option will print a list of the fonts that it has picked up from Fontconfig, which can at least confirm that it can see the font that you're trying to use. There are also font editing programs like Fontforge that can load TrueType font files for inspection, or you can send it to me to take a look at if you like.
Chris Thorman
Hi Mike,

Thanks for the advice. --debug confirmed that fc-list was correct: Zapf Dingbats is properly installed on Linux.

I created pangrams for 0020-00FF and F000-F0FF and as you predicted, F040 worked on the Linux side. The hack didn't work on Mac, so my current results are:

<p>F040 works on Linux: <span>&#xF040;</span></p>
<p>2720 works on MacOS: <span>&#x2720;</span></p>

I think right now my best option is to find a version of Zapf Dingbats that will work with the unicode encodings under Linux. Next I will try converting the dfont that comes with Mac to a ttf I can try on the Linux side. (So much for ITC! :-))

Thanks & I'll report back.

-c
Chris Thorman
Followup:

Converting the Mac ZapfDingbats.dfont to ZapfDingbats.ttf and installing that version on Linux in place of the commercial ITC version, fixed the problem. Now the tests I posted above render the same on Mac and Linux.

Updated version of test doc that now works in all cases is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Dingbat test</title>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  </head>
  <body>
    <p>Maltese cross: <span style="font-family: Zapf Dingbats">&#x2720;</span></p>
  </body>
</html>


Thanks for the hints,

-c[/code]
Chris Thorman
Update here in 2023: Mostly due to laziness and because the .dfont was the "source", I had been deploying both the dfont and ttf versions of the same font to the same unix dir along with the other ttf fonts. (on Linux) This didn't cause a problem in until updating to latest princexml (we jumped from version 9 to version 2023). At that point, the presence of the .dfont file was causing prince to report an error loading the .dfont file, then another font would get substituted. Removing the .dfont file caused prince to correctly load the .ttf file, and things started working again.

HTH anyone finding this thread....