The attached PDF is rendered with missing characters with gshead (r8602). Adobe Acrobat 8.1 and Apple Preview 4.1 display the file correctly. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif ./reading.pdf
Created attachment 3880 [details] reading.pdf
*** Bug 689649 has been marked as a duplicate of this bug. ***
The font is actually incorrect. A number of the glyphs end up calling function 1 which is defined like this: 00060: FDEF 00061: MD[org] 00062: DUP 00063: PUSHB[1] 7 00065: SWAP 00066: JROT 00067: POP 00068: POP 00069: PUSHB[2] 0 21 00072: JMPR 00073: ABS 00074: DUP 00075: ROLL 00076: RCVT 00077: DUP 00078: ROLL 00079: SUB 00080: ABS 00081: PUSHB[1] 50 00083: LT 00084: IF 00085: SWAP 00086: EIF 00087: POP 00088: ROUND[Black] 00089: PUSHB[1] 64 00091: MAX 00092: ENDF The problem is the relative jump: 00069: PUSHB[2] 0 21 00072: JMPR This jumps forward 21 bytes, which is intended to end up at the ENDF instruction (the pointer is still pointing at the JMPR for the purposes of counting the bytes). However the programmer miscounted and there are only 20 bytes to the ENDF instruction. This is actually quite a common error in TrueType fonts, I suspect that some interpreters spot the fact that they have run off the end of the function definition and abort the function silently (silently ignoring errors seems to be normal TT practice). We don't seem to keep a count of the length of the individual functions, so I propose to fix this the same way I fixed the last TrueType interpreter I worked on, and check the next opcode and preceding opcode after executing a JMPR instruction. If the opcode we are moving to is not an ENDF, but the opcode immediately preceding it is, then apply one less byte to the instruction pointer. The proposed fix works for this file, but I want to run a regression test before checking in the change.
Fixed in revision 9474, patch at: http://ghostscript.com/pipermail/gs-cvs/2009-February/009051.html