[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 #11 from James Cloos <cloos at jhcloos.com>  2008-09-18 14:09:57 PST ---
I am out of X right now, but I am pretty sure that pdftops/poppler from
poppler git master of a few days ago gave reasonable output.  I can say
that, for each of levels 1, 2 and 3, it generates Type3 PostScript fonts
for each of the Typd3 PDF fonts and outputs the text using show-type ops.

The biggest difference between the level1 and level2 output is that l1
uses hex and level2 uses ascii85 encoding for the images which make up
the type3 fonts.  Level3 only adds better support fir CID-keyed fonts
over the level2 output.

[Time passes...]

I ran those ps files thru gs -sDEVICE=pbm -r75 (which creates ascii PBM
files), opened them in emacs and removed the newlines after each 64-
character long line, thereby having one line of 0s and 1s for each pixel
row of the image.  That shows that gs 8.63, at least, can handle the PS
output by pdftops/poppler (of git master) just fine.

I suspect, then, that this part of your problem is due to the outdated
version of poppler in the version of Ubuntu you have installed.
(poppler 0.6.4 is OLD.)

Git master poppler and cairo do not fully fix the problem when using
evince to print.

Evince generates new PDF or PS using cairo when printing.  The resulting
files are ugly.  

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.

IE, evince probably ought to have document-backend-specific routines
for generating PS and PDF for printing.

I *think*, then, that -- at least when using current tip versions --
the bug is in evince, not in poppler.


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