[texworks] Mac OS TeXworks + fontconfig

[Charlie Sharpsteen]

On Thu, Jun 2, 2011 at 8:00 AM, Stefan Löffler <st.loeffler at gmail.com> wrote:
> Hi,
>
> On 2011-06-01 23:38, Charlie Sharpsteen wrote:
>> I cleaned the implementation up a little bit by placing the
>> substitution inside the first `while` loop along with the other tricks
>> that get tried if `ATSFontFindFromPostScriptName` returns
>> `kATSUInvalidFontID`:
>>
>>     https://github.com/Sharpie/TeXworks/commit/037a148
>
> Looking good, thanks.
>
>> I also bumped up the debugging verbosity a bit and extended the
>> messages to the `getDisplayFont` method which is what calls
>> `loadPlatformFont`---this includes messages that get printed every
>> time the variable `myName` is altered so that it is different than
>> what was copied from `fontName`.  The results were interesting:
>>
>> Lookup font: ZapfDingbats
>> Loading font.
>>    Substituting ZapfDingbatsITC for ZapfDingbats.
>>    ATSFontFindFromPostScriptName found fontRef
>>    found 'glyf' table
>>    found in file: /System/Library/Fonts/ZapfDingbats.ttf
>>    returning TTF file.
>> Finished getDisplayFont.
>>
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>> Bogus memory allocation size
>>
>>
>> ZapfDingbats is the only font for which `loadPlatformFont` has to
>> alter the `fontName` in order for `ATSFontFindFromPostScriptName` to
>> get a match. It looks like whatever is happening to produce the memory
>> errors is happening outside of `GlobalParamsMac.cc`, but may be
>> influenced by the substitution that occurs within `loadPlatformFont`.
>
> Yes, it's quite definitely happending outside our code. Whether it's
> influenced by the substitution I'm not so sure, though. As far as I can
> see, all those substitutions work on a local copy myName of fontName, so
> I don't see how this should cause problems.
> Anyway, this is quite easy to test:
> Could you open the testcase pdf file (in a text editor) and replace all
> occurrences of ZapfDingbats by ZapfDingbatsITC? That way, I hope poppler
> will look for the correct file straight away and the substitution should
> not kick in (though checking with some debugging output lines can't
> hurt). If the "Bogus..." lines still occur the problem probably is in
> the font file itself...
> Alternatively, you can replace another font (e.g., "Times-Roman" >
> "Times-RomanTest") in the pdf and add subsitution lines for replacing
> "Times-RomanTest" back to "Times-Roman" in the poppler source.
>
> HTH
> Stefan
>
> PS: Thanks for persevering :).

Allright, I did some poking around:

  - Changing ZapfDingbats to ZapfDingbatsITC in base-14-font.pdf does
not solve the Bogus memory allocation errors, however it does cause
all the dingbat glyphs to be replaced with .notdef boxes.

  - Changing Helvitical to HelviticaFoo and altering the ZapfDingbat
substitution to operate on it instead had no effect.

  - The errors are coming from the memory allocator for the Goo
objects that Poppler uses.

  - I followed the function calls out of GlobalParamsMac.cc and into
SplashOutputDev.cc.  They don't occur in
`SplashOutputDev::doUpdateFont` which is the function that calls
`getDisplayFont` from GlobalParamsMac.cc.

Not sure what else to do at this point.


-Charlie