On Thu, Jun 2, 2011 at 2:29 PM, Stefan Löffler <span dir="ltr"><<a href="mailto:st.loeffler@gmail.com" target="_blank">st.loeffler@gmail.com</a>></span> wrote:<div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
On 2011-06-02 18:19, Charlie Sharpsteen wrote:<br>
> - Changing ZapfDingbats to ZapfDingbatsITC in base-14-font.pdf does<br>
> not solve the Bogus memory allocation errors, however it does cause<br>
> all the dingbat glyphs to be replaced with .notdef boxes.<br>
<br>
</div>Hm, this is unexpected (for me, anyway). Am I right in assuming that in<br>
this case, none of the substitution, .dfont handling and stuff kicks in<br>
but it simply returns the .ttf file? If that is the case, I don't<br>
understand why all glyphs come out as .notdef. Unless there is some<br>
other ZapfDingbats-specific code somewhere... Does anyone with more<br>
experience with/knowledge about fonts have any ideas?</blockquote><div><br></div><div>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.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
> - The errors are coming from the memory allocator for the Goo<br>
> objects that Poppler uses.<br>
<br>
</div>Yes, I found the error message there as well. Could you find out which<br>
one of the *malloc it is (e.g., by simply altering the different error<br>
messages so they are unique)?</blockquote><div><br></div><div>The errors all come from the `gmallocn` allocator.</div></div><br></div><div><br></div><div>On Fri, Jun 3, 2011 at 3:31 AM, Stefan Löffler <span dir="ltr"><<a href="mailto:st.loeffler@gmail.com" target="_blank">st.loeffler@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;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><br></div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;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.</div>
</div><div><br></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 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 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 href="https://gist.github.com/1008336">https://gist.github.com/1008336</a></div><div><br></div><div> Raw:</div><div> <a 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><div><br></div><div>-Charlie</div><div><br></div>