[gs-bugs] [Bug 689760] Missing characters: Failed to interpret TT instructions

[bugs.ghostscript.com-bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=689760

ken.sharp at artifex.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED



------- Additional Comments From ken.sharp at artifex.com  2009-02-12 07:28 -------
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.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.