[texworks] Mac OS TeXworks + fontconfig

[Charlie Sharpsteen]

On Sat, May 28, 2011 at 1:11 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> 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)

Both builds were produced using Poppler 0.16.5. The Fontconfig-based
build was created using a Homebrew formula in my master branch:

    https://github.com/Sharpie/TeXworks/blob/master/cmake/packaging/mac/poppler.rb

A Homebrew Formula is just a Ruby class that contains information how
to download, patch, build and install a piece of software.  That
poppler.rb file is derived from the standard Hombrew Formula for
Poppler with some additions to apply the patch
`poppler-qt4-globalparams.patch` which enables us to bundle
poppler-data into the TeXworks app. It also disables some unneeded
Poppler features to reduce the number of dynamic dependencies in the
Poppler library.

The Quartz-based build was created using this formula in my
poppler-font-handling branch:

    https://github.com/Sharpie/TeXworks/blob/poppler-font-handling/cmake/packaging/mac/poppler.rb

This build applies `poppler-mac-font-handling.patch` to get rid of the
dependencies on Fontconfig.  This requires re-running the Autotools in
order to generate a new Configure script.  A new patch,
`poppler-mac-remove-iconv.patch`, is also applied to remove references
to libiconv in `configure.ac`---otherwise GNU gettext would need to be
installed in order to provide M4 macros required by Autotools.  This
build is also more aggressive in the number of extraneous backends and
other features that are disabled.


> - What Helvetica* fonts do you have in /System/Library/Fonts?

Here's what I have on my test systems (OS X 10.6.7 and 10.5.0):

Charlie-Sharpsteens-Mac-Pro:~ sharpie$ ls /System/Library/Fonts/Helve*
/System/Library/Fonts/HelveLTMM
/System/Library/Fonts/Helvetica LT MM
/System/Library/Fonts/Helvetica.dfont
/System/Library/Fonts/HelveticaNeue.dfont


> @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.

I will look into this when I get a chance.


> 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.

Thanks for pointing this out---it makes a lot of sense now. did a
quick grep for "backend" in the qt subdirectory of the Poppler source
and the only results referred to Splash or Arthur---so it looks like
those are our choices. It is too bad that the Qt backend is not more
tightly integrated with the Qt drawing system.

-Charlie


> HTH
> Stefan