[texworks] Mac OS TeXworks + fontconfig

Charlie Sharpsteen chuck at sharpsteen.net
Wed Jun 8 22:07:36 CEST 2011

On Tue, Jun 7, 2011 at 7:27 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
> On 2011-06-05 21:56, Charlie Sharpsteen wrote:
> On Sun, Jun 5, 2011 at 12:22 AM, Stefan Löffler <st.loeffler at gmail.com>
> wrote:
>> Just for the record (and for submitting the patches upstream): did this
>> happen with an unpatched poppler as well? I.e., are those zero-height glyphs
>> picked up by fontconfig as well, or do they require/use other font files
>> that don't show this issue?
> I never noticed it before, but this error *do* happen with the Fontconfig
> build as well. Makes sense as Fontconfig is using the same Font file.  Your
> patch also fixes the Fontconfig build.
> I guess the last remaining issue that plagues (sort of) the Mac build of
> Poppler are the .notdef glyphs that show up in the Symbol font:
> One on Snow Leopard:
>     http://i.imgur.com/m0BCk.png
> Two on Leopard:
>     http://i.imgur.com/LEBbh.png
> I don't know if it is really worth hunting these down and eliminating them
> as TeXworks is not a general-purpose PDF viewer.  It might help with getting
> patches accepted upstream, but these issues are present in the Fontconfig
> build as well so we're not really upsetting the status quo by leaving them
> alone.
> I'm inclined to close this matter. If Apple changes font encodings between
> releases (it's not even the same glyphs that are .notdef'ed!) we can't help
> it. Besides, as I pointed out before, TeX documents normally have their
> fonts embedded, AFAIK. Fixing this would probably need some digging through
> the encoding tables and adding OS version switches there (though I'm not
> even sure if it's (easily) possible to have a conditional compilation
> depending on the OS version...).

It appears there was more to the Symbol font situation on Leopard.
When testing a new binary, I noticed that Helvetica was being
substituted for Symbol, but only on OS X 10.5.x.  I re-applied the
debugging patch and it turned out that for the Symbol font, the check
for a TrueType font:

    version != TAG('t','r','u','e')

Was evaluating to false for some reason.  It shouldn't have as the
value of `version` was 1953658213 which does decode to "true" when
split into char values. The `TAG` macro expands to four separate
bitwise operations--so possibly the logical comparison was not being
made against the total result of the `TAG` computation.  I added a set
of perentheses around the entire `TAG` definition and TeXworks stopped
substituting Helvitica for Symbol.  The result still has one .notdef
character, but at least it is in the same place as the Snow Leopard

Attached is a patch that I think fixes the preprocessor definitions in

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fix-preprocessor-definitions-in-GlobalParamsMac.cc.patch
Type: application/octet-stream
Size: 2917 bytes
Desc: not available
URL: <http://tug.org/pipermail/texworks/attachments/20110608/4ec6e1a4/attachment.obj>

More information about the texworks mailing list