[texworks] Mac OS TeXworks + fontconfig

[Charlie Sharpsteen]

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

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

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