Bugs item #4352, was opened at 2012-08-06 15:29 Status: Open Priority: 3 Submitted By: Emmanuel Beffara (xunam) Assigned to: Nobody (None) Summary: "Badly formed number" errors Category: Fonts Group: None Resolution: None Initial Comment: For some time (can't remember precisely when it started) I have been getting errors for PDFs using my "French Cursive" font family. There are many things involved when this bug happens, so it is hard to pinpoint exactly where it comes from, but I have the impression it might happen in pdfTeX. It happens with PDF documents generated by pdfTeX using some particular fonts. The symptom is error messages of the form Error (2319): Badly formatted number when viewing the PDFs using any software that uses the Poppler library. The number in the messages is variable. Despite these messages, documents are properly displayed and printed. Any document using the current CTAN version of frcursive exhibits this problem. I attach a minimal example of a font that also produces the error. The procedure of the included Makefile is: 1. make the PFB font and the TFM file from the MF source, using mftrace 2. compile a minimalistic document with pdftex 3. convert it to PS using pdftops (which uses poppler) Step 3 produces the error message. I should add that I experimented a bit on this minimal example: - if I make the PDF using tex and dvipdfm, the error disappears (which is why I though pdftex was part of the bug) - if I change the character width from -0.111 pt# to e.g. 0.111 pt# or -0.11 pt#, the error disappears ---------------------------------------------------------------------- Comment By: Emmanuel Beffara (xunam) Date: 2012-08-07 07:35 Message: Indeed, this glyph width is wrong. The intended value is actually negative (reading it as 2^15 - 11 gives a more reasonable value of -11, assuming negative widths are allowed, which seems to be the case reading the T1 spec). So the problem here is probably on the side of mftrace. Nevertheless, this is not what causes the problem I originally described. With the example I uploaded, if I change the width in the metafont source from -0.111pt# to -0.11pt#, then the "Badly formatted number" error disappears but the PFB file is exactly the same (not considering creation dates) and t1disasm shows the same (invalid) width. The only difference is in the TFM file. Hence I do think pdftex does something wrong. With character width -0.111pt#, tftopl on the TFM file yields (CHARACTER C a (CHARWD R -0.011099) ) (with width -0.11pt# we get -0.011 here) and 'pdfshow t.pdf 5' (using pdfshow from the mupdf tools) yields 5 0 obj << /Type /ObjStm /N 7 /First 40 /Length 342 /Filter /FlateDecode >> stream [...] << /Font << /F51 4 0 R >> /ProcSet [ /PDF /Text ] >> [-11.-1] [...] which indeed looks wrong. With width -0.11pt# this "-11.-1" is replaced by "0". If I make the PDF using tex and dvipdfm, disassembling the corresponding object in the final PDF shows that the value written by dvipdfm is "-11.1". ---------------------------------------------------------------------- Comment By: Reinhard Kotucha (reinhard) Date: 2012-08-06 20:18 Message: The file foo.pfb contains much too large values for hsbw: 2 index /CharStrings 2 dict dup begin /.notdef { 0 32757 hsbw endchar } ND /a { 0 32757 hsbw endchar } ND The first argument of hsbw is the side bearing, usually < 100, the second argument denotes the glyph width, usually < 1000. Since 32757 > 2^16, it might be an implementation limit of some programs. Furthermore, when I extract and disassemble the font included in the resulting PDF file, the result is exactly the same. Hence pdftex includes it "as is". I suppose that the problem either originates from mftrace or the metafont sources. You can use the program t1disasm in order to disassemble fonts. See also: http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4352&group_id=106