[texworks] Mac OS TeXworks + fontconfig

[Charlie Sharpsteen]

On Thu, Jun 2, 2011 at 2:29 PM, Stefan Löffler <st.loeffler at gmail.com>wrote:

 On 2011-06-02 18:19, Charlie Sharpsteen wrote:
> >   - 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.
>
> Hm, this is unexpected (for me, anyway). Am I right in assuming that in
> this case, none of the substitution, .dfont handling and stuff kicks in
> but it simply returns the .ttf file? If that is the case, I don't
> understand why all glyphs come out as .notdef. Unless there is some
> other ZapfDingbats-specific code somewhere... Does anyone with more
> experience with/knowledge about fonts have any ideas?


On OS X 10.6.x, there is no .dfont file, just a .ttf file. I haven't done
much bug hunting on 10.5.x where ZapfDingbats is a .dfont, but some quick
tests I did there shows that the behavior is mostly the same.


>   - The errors are coming from the memory allocator for the Goo
> > objects that Poppler uses.
>
> Yes, I found the error message there as well. Could you find out which
> one of the *malloc it is (e.g., by simply altering the different error
> messages so they are unique)?


The errors all come from the `gmallocn` allocator.


On Fri, Jun 3, 2011 at 3:31 AM, Stefan Löffler <st.loeffler at gmail.com>
 wrote:
>
> >   - Changing Helvitical to HelviticaFoo and altering the ZapfDingbat
> > substitution to operate on it instead had no effect.
>
> No effect meaning that the "Bogus..." messages didn't change, right? So
> they are still coming form ZapfDingbats, not from the replaced Helvetica?


No effect meaning that the substitution of "Helvitica" for
"HelviticaFoo" produces no side effects such as "Bogus" messages from the
Goo allocator unlike the substitution of "ZapfDingbatsITC" for
"ZapfDingbats". Should have been more clear about that :). I also tried a
similar test with Courier and got no error messages.



> >   - 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.
>
> Hm, I wonder... The "Bogus..." messages always occur after all "Lookup
> font..." messages right? This might suggest that they occur not in the
> initialization phase but in the actual drawing phase (possibly in
> SplashOutputDev::drawChar).
>

Good guess about `SplashOutputDev::drawChar`.  Getting Poppler to build in a
GDB-friendly way took some hair pulling---the Autotools build uses libtool
and libtool "helpfully" nukes object files after it gets done linking
libraries.  Previously, I got into a fight with libtool when compiling
Poppler for the the Leopard builds as it was also "helpfully" stripping some
essential compiler flags.

I am now officially not a fan of libtool, it seriously needs a
`--dont-try-to-be-clever` flag.

Fortunately the Poppler CMake build doesn't try to pull such shenanigans. It
faithfully passes compiler flags and leaves object files alone.  I expanded
`poppler-mac-font-handling.patch` to add the Mac font handling option to the
Poppler CMake build as well as the Autotools build:

    https://github.com/Sharpie/TeXworks/commit/251eb23

As I recall, lack of CMake support may have been an issue that kept
Jonathan's patch out of the official Poppler tree:

    http://lists.freedesktop.org/archives/poppler/2009-July/004972.html


Anyway, after getting TeXworks and Poppler to run through GDB, a backtrace
from the error message indicates that the problem occurs in
`SplashFTFont::makeGlyph` at `SplashFTFont.cc:244` which is a couple steps
down the call chain from `SplashOutputDev::drawChar`.  I'll try to look over
this later to see if I can figure anything out, but here is the full
backtrace:

    Formatted:
    https://gist.github.com/1008336

    Raw:

https://gist.github.com/raw/1008336/1c01061723261e5d3b6d583ff059a82ac0f00482/texworks_gdb_log.mdown


Let me know if anything jumps out!

-Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110604/91742d59/attachment.html>