When the attached PDF file is rendered by Ghostscript head (r11700) the '1' is missing from the various numbers (i.e. "107.000" is rendered as " 07.000"). Earlier versions of Ghostscript fail in the same way. Adobe Acrobat 9.3.4 and Apple Preview 5.0.2 open the PDF file correctly. The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm -r400 ./5120-023_div_8_steel.pdf
Created attachment 6710 [details] unified diff of a change to disable type 3 font caching. The type 3 font 'EMBEDDED_2a+StylusBT' is incorrect. The glyph for the '1' glyph is as follows: 257 0 0 0 257 1000 d1 291.104 17.493 m 306.543 617.663 l 306.543 636.318 314.905 645.967 330.344 645.967 c 350.285 645.967 356.718 640.821 356.718 588.716 c 339.35 26.499 l 338.063 -4.377 331.63 -12.096 314.262 -12.096 c 298.824 -12.096 291.104 -1.161 291.104 17.493 c 291.104 17.493 l The 'd1' operator declares the glyph to have a width of 257, a lower left corner at 0,0 and an upper right corner at 257,1000. However, the actual marking operations of the glyph take place outside this bounding box. For example: 291.104 17.493 m 306.543 617.663 l draws a line from 291,17 to 306,617. This entire line is outside the declared bounding box. On page 423 of the PDF reference manual, under the d1 operator it says: "llx and lly are the coordinates of the lower-left corner, and urx and ury the upper-right corner, of the glyph bounding box. The glyph bounding box is the smallest rectangle, oriented with the axes of the glyph coordinate system, that completely encloses all marks placed on the page as a result of executing the glyph’s description. The declared bounding box must be correct—in other words, sufficiently large to enclose the entire glyph. If any marks fall outside this bounding box, the result is unpredictable. " The reason the result is unpredictable is because if the glyph is cached the bitmap created is only big enough for the declared size and marks outside the declared area will vanish. If the glyph is not cached, then the declared bounding box is not used for anything. Clearly Acrobat renders glyphs uncached, Ghostscript renders them cached for performance reasons. If it is considered desirable to render type 3 fonts uncached, then the attached patch will redefine the 'd1' operator so that it does not invoke the cache. This will result in the same output as Acrobat, at the cost of some performance when rendering type 3 fonts. Since the font clearly contravenes the specification, and disabling the cache potentially costs performance, I don't think this is something we want to add by default.
Changing customer bugs that have been resolved more than a year ago to closed.