[pdftex] pdftex core dump when including certain pdf files

sender.pdftex at wobsta.de sender.pdftex at wobsta.de
Sat Jul 16 22:04:04 CEST 2016


Hi Norbert,
(Hi Ross -> see cc),

On Sat, Jul 16, 2016 at 10:59:41AM +0900, Norbert Preining wrote:
> Was the plot.pdf also generated by PyX?

We're getting a bit off-topic, but I'm happy to answer your question. The file
plot.pdf was indeed created by PyX.

> > I've just fixed it in PyX (https://sourceforge.net/p/pyx/code/3683/).
> 
> I checked the file and see
>         if self.dfWeight >= 600:
>             stemv = 120
>         else:
>             stemv = 70
>         file.write("/StemV %d\n" % stemv)
> so PyX should create only integer valued StemV. How did the original
> plot.pdf been created, then?

PyX does something similar to other programs (pdftex included). It tries to
extract informations from the fonts by some tricks, when no afm file is
provided. (However, before the bug report we would had also copied a float from
the afm, if it happend to be a float in the afm, but this rarely happens if at
all. We also cast this to be an int in the PDF output now.) The case you've
shown is when an afm file exists but no StemV is inside. It than makes an very
crude approximation based on the font weight. (I'm pretty sure we have seen
this elsewhere and decided to do the very same in PyX.)

Now, for the case of plot.pdf it seems that no afm file was available at all.
(PyX also warns you about the rather crude way out in this case where we
extract data directly from using appropriate font glyphs.) For StemV we take a
period:

    file.write("/StemV %d\n" % (glyphinfo_period[4]-glyphinfo_period[2]))

In response to our bug report we changed the code to output an integer (as
checked in and shown here), whereas we allowed it to be a float before and than
the core dump in pdftex occured. Note: By our change the value is now always
truncated towards zero, but given this to be a crude approximation anyway, this
is probably not important.

Best,


André

PS @Ross: I noticed that in AFM there are ItalicAngles (for the two directions
a font could support). A plain and simple copy & paste error, while only
writing the first direction value, is very likely the source of our bug with
ItalicAngle*s* having occured in the PDF output (and which is fixed now).

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   lists at wobsta.de, http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/


More information about the pdftex mailing list