<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
finally, the pieces of the puzzle are starting to fit together :).<br>
<br>
On 2011-06-04 22:47, Charlie Sharpsteen wrote:<br>
<blockquote
cite="mid:BANLkTim=o_pQUB_t_Qsk5x5o7SuRGPvYbA@mail.gmail.com"
type="cite">
<div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>> - Changing Helvitical to HelviticaFoo and altering
the ZapfDingbat<br>
> substitution to operate on it instead had no effect.<br>
<br>
</div>
No effect meaning that the "Bogus..." messages didn't change,
right? So<br>
they are still coming form ZapfDingbats, not from the replaced
Helvetica?</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
OK, so it really is just a ZapfDingbats issue, and not an issue with
the substitution code.<br>
<br>
<blockquote
cite="mid:BANLkTim=o_pQUB_t_Qsk5x5o7SuRGPvYbA@mail.gmail.com"
type="cite">
<div>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>> - I followed the function calls out of
GlobalParamsMac.cc and into<br>
> SplashOutputDev.cc. They don't occur in<br>
> `SplashOutputDev::doUpdateFont` which is the function
that calls<br>
> `getDisplayFont` from GlobalParamsMac.cc.<br>
><br>
> Not sure what else to do at this point.<br>
<br>
</div>
Hm, I wonder... The "Bogus..." messages always occur after all
"Lookup<br>
font..." messages right? This might suggest that they occur
not in the<br>
initialization phase but in the actual drawing phase (possibly
in<br>
SplashOutputDev::drawChar).<br>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
</div>
</div>
<div>I am now officially not a fan of libtool, it seriously needs
a `--dont-try-to-be-clever` flag.</div>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div> <a moz-do-not-send="true"
href="https://github.com/Sharpie/TeXworks/commit/251eb23">https://github.com/Sharpie/TeXworks/commit/251eb23</a></div>
<div><br>
</div>
<div>As I recall, lack of CMake support may have been an issue
that kept Jonathan's patch out of the official Poppler tree:</div>
<div><br>
</div>
<div> <a moz-do-not-send="true"
href="http://lists.freedesktop.org/archives/poppler/2009-July/004972.html">http://lists.freedesktop.org/archives/poppler/2009-July/004972.html</a></div>
<div><br>
</div>
<br>
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:
<meta charset="utf-8">
<meta charset="utf-8">
<meta charset="utf-8">
<div>
<br>
</div>
<div> Formatted:</div>
<div> <a moz-do-not-send="true"
href="https://gist.github.com/1008336">https://gist.github.com/1008336</a></div>
<div><br>
</div>
<div> Raw:</div>
<div> <a moz-do-not-send="true"
href="https://gist.github.com/raw/1008336/1c01061723261e5d3b6d583ff059a82ac0f00482/texworks_gdb_log.mdown">https://gist.github.com/raw/1008336/1c01061723261e5d3b6d583ff059a82ac0f00482/texworks_gdb_log.mdown</a>
</div>
<div><br>
</div>
<meta charset="utf-8">
<div>Let me know if anything jumps out!</div>
</blockquote>
<br>
Awesome work! In fact, I think the solution jumped out. From looking
at the source code, it seems that bitmap->h (which is the number
of rows to allocate) is 0, hence the warnings. My guess is it is
caused by a zero-dimension "glyph" for the space character. Anyway,
it should be fixed easily (see attached patch). So, hopefully this
settles that once and for all.<br>
<br>
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?<br>
<br>
Thanks again for the immense amount of work you've put into this!<br>
<br>
Cheers,<br>
Stefan<br>
</body>
</html>