<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
first of all: I don't have much experience with the guts of font
handling, either, but maybe some of my comments can still help.<br>
<br>
On 2011-05-26 22:32, Charlie Sharpsteen wrote:
<blockquote
cite="mid:BANLkTimA7ZudPHKsjdrQSJ8BYW7eKZW2_A@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, May 26, 2011 at 3:03 AM, Jonathan Kew <a class="moz-txt-link-rfc2396E" href="mailto:jfkthame@googlemail.com"><jfkthame@googlemail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Interesting.... neither of these is entirely successful. (Thanks VERY much for your building and testing efforts!) The fontconfig/X11-fonts version fails to handle Helvetica Bold [Oblique], it just renders the non-bold faces. (And it's got a .notdef glyph in place of the "mu" in the middle of the Symbol line. That's probably an encoding mismatch related the "micro" symbol and the Greek letter "mu".)
</pre>
</blockquote>
</blockquote>
<br>
Just to collect some basic information:<br>
- Which version of poppler are you using (0.16.5 is the current one,
AFAIK)<br>
- What Helvetica* fonts do you have in /System/Library/Fonts?<br>
<br>
@Jonathan: Any idea how one could work around the "mu" problem? Hack
poppler-data, maybe?<br>
<br>
<blockquote
cite="mid:BANLkTimA7ZudPHKsjdrQSJ8BYW7eKZW2_A@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Meanwhile, the Quartz one gets Helvetica right, but doesn't find either Symbol or ZapfDingbats, and just falls back to Helvetica glyphs for both of those lines. I don't recall the details of the patch for finding Quartz fonts, but maybe this could be fixed?
</pre>
</blockquote>
</blockquote>
<br>
Hopefully. The way I see it ATM, the patch works as follows (all of
this applies to loadPlatformFont(), font substitution if no suitable
candidate is found is performed elsewhere, but shouldn't matter here
as we expect all fonts can be found):<br>
Call ATSFontFindFromPostScriptName<b> </b>to look for the font. If
it's not found, strip parts after "," and after "-" and try again.<br>
<br>
Next, do what the following comments says:<br>
// Currently support only TrueType fonts: check for presence of
'glyf' table<br>
<br>
// if the font comes from a .ttf file, we can use that directly<br>
<br>
// for .dfont or suitcase files, FoFiTrueType can't handle them, so
we extract<br>
// the required font to a temporary .ttf file and then use that<br>
<br>
<blockquote
cite="mid:BANLkTimA7ZudPHKsjdrQSJ8BYW7eKZW2_A@mail.gmail.com"
type="cite">
<pre wrap="">
I could take a look at the font patch to see what needs to be fixed,
but I have never really dug into the guts of any font handling system
so it would probably take a while.</pre>
</blockquote>
<br>
I took a look at the font patch. I can't claim I understood all the
Mac-specific stuff, but from your screenshot, all fonts come from
/tmp. This suggests we're in the section started by the comment<br>
// for .dfont or suitcase files, FoFiTrueType can't handle them, so
we extract<br>
// the required font to a temporary .ttf file and then use that<br>
<br>
So, I see 3 possibilities:<br>
1) The Symbol and ZapfDingbats fonts are not found by
ATSFontFindFromPostScriptName<br>
2) They are only available in OpenType/CFF or other non-ttf formats
and are thus not handled<br>
3) Some other problem<br>
<br>
I've attached a symbol/zapf only version of the testcase so it's
easier for you to debug (not so many other fonts that are loaded).
I'd suggest adding some debug output lines to poppler
(poppler/GlobalParamsMac.cc, the file the patch modifies) to check
if possibilities 1 or 2 above apply.<br>
<br>
<blockquote
cite="mid:BANLkTimA7ZudPHKsjdrQSJ8BYW7eKZW2_A@mail.gmail.com"
type="cite">
<pre wrap="">One interesting thing I noted is
that Poppler needs to be build with the "splash" backend enabled in
order to get any font output at all.
</pre>
</blockquote>
<br>
That I can explain. Tw explicitly sets the render backend to splash
(src/PDFDocument.cpp@1420). Maybe this is outdated (cairo might give
good results?) but the arthur backend (which apparently was the
default at least in earlier versions) was crap, so that's why this
is there.<br>
<br>
HTH<br>
Stefan<br>
</body>
</html>