Hi!

I'm running Prince v7.0b1 on Mac OS 10.5.8. I'm working on an XHTML document with an external CSS file that uses only two fonts: Garamond and Myriad Pro, both of which are installed locally. Myriad Pro is only used for headings (h1-h6) and a few other elements.

I'm having a problem in which text set in Myriad Pro fails to render-- instead, the Prince PDF displays characters that look like boxes with Xs in them.

I've checked everything I can think of-- there is an xml declaration, valid doctype, and my encoding is declared as UTF-8. I've even validated the html. I've never bothered with these things for Prince documents before, as I've found Prince to be pretty lenient. The problem seems to be triggered when I add headings to the document-- an earlier version with fewer headings displays perfectly.

I even ecopied my font files to the project directory and used "prince --scanfonts" to generate a CSS file with @font-face rules, which I imported into my main file, but that didn't help.

I'm not sure how to even troubleshoot this issue to identify the source of the problem. Running Prince in verbose mode didn't return any errors. Any ideas?

Thanks!

Does the text in Myriad Pro fail to render all the time, or only in some situations? Can you email me (mikeday@yeslogic.com) a sample PDF file that you are generating, and perhaps the log obtained when you run the conversion with the --debug option?

Thanks, Mike. I just posted the eMail, with sample PDF files and debug info.

In my troubleshooting, I found that Myriad Pro only fails to render when I use a specific word in one of the headings that uses that font.

I look forward to hearing from you at your convenience. Thanks for making such an awesome product-- even though it's behaving strangely now.

Are you testing only with Preview.app, or with Adobe Reader as well?

It seems to be the Apple PDF Preview problem again, caused by a ligature in the heading requiring the font to use a different encoding. We might need to discuss this issue with Apple, as it's getting pretty annoying.

Indeed, I was-- Preview refreshes the open document immediately when Prince runs, without mousing over to 'Revert' under the 'File' menu.

Acrobat renders the fonts correctly. Thanks for your wisdom and support!

I found this possible workaround: Use the invisible soft hyphen character & #173 ; between characters when lowercase f and i appear together. Obviously, this method sacrifices the beautiful ligature offered by the font.

You could use the zero width space (U+200B) or better yet zero width non-joiner (U+200C) to inhibit ligatures without adding unwanted line-break opportunities. This could even be done from CSS to avoid modifying the source document, like this:

h3 { prince-text-replace: "fi" "f\200C i" }

Keeping in mind that there may be other ligatures that need to be handled, and some accented and non-Latin characters will also trigger this encoding issue. The only long-term solution is to get Apple to fix Preview.

Aha! Three cheers for separating content from presentation, and not modifying the source to fix an Apple display bug. Thanks!

This worked for us:

h1 {
	prince-text-replace: "ffi" "f\FEFFf\FEFFi" "ffl" "f\FEFFf\FEFFl" "ff" "f\FEFFf" "fi" "f\FEFFi" "fl" "f\FEFFl" "ft" "f\FEFFt" "ij" "i\FEFFj" "IJ" "I\FEFFJ";
}

(based on http://www.princexml.com/bb/viewtopic.php?p=4439#p4439)

Our font didn't support U+200C (ZERO WIDTH NON-JOINER), and U+200B (ZERO WIDTH SPACE) was out of question because it generated unwanted line breaks. U+FEFF (ZERO WIDTH NO-BREAK SPACE) worked just fine.