[Poppler-bugs] [Bug 17497] Poppler cannot handle certain font encodings or font types correctly

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=17497





--- Comment #12 from Adrian Johnson <ajohnson at redneon.com>  2008-09-21 04:39:06 PST ---
(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 at 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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.