Comment 12 for bug 276615

(In reply to comment #11)
> I found that evince needed tens of minutes to print wrong.pdf to a ps
> file on my 1GHz PIIIM. The resulting ps has 847 fallback images of
> the form:
>
> % Fallback Image: x=149, y=129, w=3, h=2 res=300dpi size=351
> [ 0.24 0 0 0.24 149 660.839983 ] concat
> /DeviceRGB setcolorspace
> 8 dict dup begin
> /ImageType 1 def
> /Width 13 def
> /Height 9 def
> /BitsPerComponent 8 def
> /Decode [ 0 1 0 1 0 1 ] def
> /DataSource currentfile /ASCII85Decode filter /LZWDecode filter def
> /ImageMatrix [ 1 0 0 -1 0 9 ] def
> end
> image
> J3Vsg3$]7K#D>EP:q1$o*=mro@So+\<\5,H7Uo7+~>Q
> q 0 0 612 792 rectclip
>
> If you use something like pdftk(1) to uncompress the PDF evince
> generates you find similar output there, too.
>
> I'm not sure where the fault lies in terms of evince, poppler or
> cairo. Evince probably should use cairo's userfont API. It
> probably should also use poppler's pdftops code for generating
> PS from PDF, and pass PDF thru as is when generating PDF from PDF.

It is a limitation of the cairo backend of poppler that it can't print Type 3 fonts nicely. When cairo 1.8 is released with the new user-font API it will be possible to fix this in poppler. Cairo user-fonts are embedded in PS/PDF as a Type 3 font.