[texworks] Mac OS TeXworks + fontconfig
Stefan Löffler
st.loeffler at gmail.com
Sat May 28 10:11:07 CEST 2011
Hi,
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.
On 2011-05-26 22:32, Charlie Sharpsteen wrote:
> On Thu, May 26, 2011 at 3:03 AM, Jonathan Kew <jfkthame at googlemail.com> wrote:
>> 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".)
Just to collect some basic information:
- Which version of poppler are you using (0.16.5 is the current one, AFAIK)
- What Helvetica* fonts do you have in /System/Library/Fonts?
@Jonathan: Any idea how one could work around the "mu" problem? Hack
poppler-data, maybe?
>> 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?
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):
Call ATSFontFindFromPostScriptName**to look for the font. If it's not
found, strip parts after "," and after "-" and try again.
Next, do what the following comments says:
// Currently support only TrueType fonts: check for presence of 'glyf' table
// if the font comes from a .ttf file, we can use that directly
// for .dfont or suitcase files, FoFiTrueType can't handle them, so we
extract
// the required font to a temporary .ttf file and then use that
> 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.
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
// for .dfont or suitcase files, FoFiTrueType can't handle them, so we
extract
// the required font to a temporary .ttf file and then use that
So, I see 3 possibilities:
1) The Symbol and ZapfDingbats fonts are not found by
ATSFontFindFromPostScriptName
2) They are only available in OpenType/CFF or other non-ttf formats and
are thus not handled
3) Some other problem
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.
> 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.
That I can explain. Tw explicitly sets the render backend to splash
(src/PDFDocument.cpp at 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.
HTH
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110528/86eb2b62/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: base14-fonts-symbols-only.pdf
Type: video/x-flv
Size: 973 bytes
Desc: not available
URL: <http://tug.org/pipermail/texworks/attachments/20110528/86eb2b62/attachment.flv>
More information about the texworks
mailing list