[texworks] Mac OS TeXworks + fontconfig

Stefan Löffler st.loeffler at gmail.com
Sun Jun 5 09:30:59 CEST 2011

On 2011-06-05 00:38, Jonathan Kew wrote:
> So at the lowest level, it's complaining about trying to allocate some kind of object of size zero; the goo allocator considers that invalid.
> Looks like this is happening on the space character, probably (c=32 in your call stack).
> I wonder if there's something about the space glyph in this version of ZapfDingbats that breaks an assumption in poppler. Space would be unusual in that it has no contours; but that would be true in most fonts, of course, so I don't know why this particular one causes trouble when other fonts apparently work ok.

I don't think it's about contours. Instead, from looking at the code, it
happens when poppler is trying to copy the bitmap (rasterized) glyph,
which in our special case turns out to have height 0. Apparently, most
other fonts have spaces with a non-zero height ;).

> (Of course, TeX doesn't usually generate space glyphs at all, but I'd expect them to be present in PDFs from other sources that poppler handles without problems.)

All of this font handling is actually not so relevant for standard TeX
docs, as there fonts are embedded AFAIK. The testcase that failed
actually tests compliance with the PDF standard for non-embedded base-14
fonts (which is the only case system fonts are needed).
Still, I think it's important to investigate and resolve these issues
before they get out of hand and cause real problems in the future.


More information about the texworks mailing list