Bug 3344

Created attachment 2711 [details]
this is the pdf that crashes it

kpdf doesn't use poppler yet, as far as I know...  I did however reproduce the
crash, so I'll take a look.

The problem is that our type 1 font parser is not robust enough to handle  
erroneus Encoding tables like   
  
/Encoding 256 array  
0 1 255 {1 index exch /.notdef put} for  
dup 33 /arrowright put  
dup 50 /element put  
dup 54 /negationslash put  
dup 63 /perpendicular put  
dup 70 /F put  
dup 72 /H put  
dup 76 /L put  
dup 88 /X put  
dup 91 /union put  
dup 92 /intersection put  
dup 94 /logicaland put  
dup 102 /braceleft put  
dup 103 /braceright put  
dup 106 /bar put  
dup 161 /minus put  
dup 183 /lessequal put  
dup 184 /greaterequal put  
dup dup 161 10 getinterval 0 exch putinterval dup dup 173 23 getinterval 10  
exch putinterval dup dup 127 exch 196 get put readonly def  
  
I'm still trying to find if the last line (that is what our parser does not 
understand) is supposed to mean anything or we can just skip it. For example 
http://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF seems to imply 
it is completely incorrect 

Created attachment 3154 [details] [review]
the patch

Here's a patch that fixes the problem.	The issue is that the type1 parser only
looks for the termination of the Encoding array in lines that don't begin with
'dup' and then only if the line is 'def' 'readonly ...' or '... def'.

The patch terminates the encoding array simply if a line begins with 'def' or
contain ' def'.  This is to avoid a char name like /somedef terminating the
encoding array prematurely.

Committed to CVS.