GNOME Bugzilla – Bug 112506
gpdf doesn't render glyphs from Type 3 font
Last modified: 2006-01-29 17:55:49 UTC
Hi, when I try to open the attached PDF file in gpdf, it only shows a white screen. xpdf does render it, and gpdf does render other PDF files correctly.
Created attachment 16336 [details] pdf file which fails to render
The text in that file is set exclusively in Type 3 (custom/bitmap) fonts. gpdf doesn't support Type 3 fonts yet. Because the encoding of the font is custom, too, I can't even substitute a system font. Type 3 support is one of the harder tasks, so this might take a while
Created attachment 17773 [details] Another pdf with Type 3 fonts that misrenders
I guess the above pdf also misrenders because it uses Type 3 fonts? The document contains several tables, and they render correctly in xpdf.
André: yes, same problem, sorry.
*** Bug 129387 has been marked as a duplicate of this bug. ***
*** Bug 131697 has been marked as a duplicate of this bug. ***
*** Bug 131198 has been marked as a duplicate of this bug. ***
The bullet points generated by OpenOffice fail to render in gpdf but display properly in ggv, and are present in previews of the .ps document used to generate the .pdf (with ps2pdf14 under Fedora Core 1) link to the .pdf: http://www.webdragon.net/resume/srg_resume.new.pdf
*** Bug 132706 has been marked as a duplicate of this bug. ***
Bumping up some priorities and such, as this is a regression from the other basic/comparable Free tools. Martin, any idea how much work this would be to add? Is this something we could ask someone else to look at, or to take code from xpdf or something for?
*** Bug 134772 has been marked as a duplicate of this bug. ***
To implement this, GPOutputDev::beginType3Char, endType3Char, type3D0 and type3D1 have to be implemented. The Xpdf implementation is in XOutputDev.cc. It implements a glyph cache for Type 3 glyphs in a way that's very hard to reimplement in gpdf. A first gpdf type 3 implementation without such a cache might be not too hard (but would be slow).
Thanks for the feedback, Martin. Hopefully someone will find cycles for this soon :)
*** Bug 122021 has been marked as a duplicate of this bug. ***
*** Bug 135564 has been marked as a duplicate of this bug. ***
*** Bug 139674 has been marked as a duplicate of this bug. ***
*** Bug 142172 has been marked as a duplicate of this bug. ***
*** Bug 142371 has been marked as a duplicate of this bug. ***
*** Bug 141359 has been marked as a duplicate of this bug. ***
*** Bug 137365 has been marked as a duplicate of this bug. ***
Created attachment 30903 [details] another file that fails to render Not sure if this is the same bug or not. Everything renders correctly except the letters 'fi'
*** Bug 154249 has been marked as a duplicate of this bug. ***
*** Bug 158188 has been marked as a duplicate of this bug. ***
*** Bug 161718 has been marked as a duplicate of this bug. ***
It's intresting to implement this issue but after look in the sources I see some problems: 1. GPOutputDev hanles only strings not chars. Do I understand correctly that for handle Type3 it should be translated in char mode? Currently only endChar and 3d1 functions are called, only char mode allow beginchar function. What should be done in such implementation: a. Begin char somehow get char glyphs (How in can be done?) and fill gnome_print_glyphlist. As I've understood there is no way to create such list from bitmaps, it can be created only from text. b. end char renders glyph list (gnome_print_glyphlist) c. 3d0 does nothing d. 3d1 scales gnome_print_glyphlist 2. Will this work interfere with recent plans of dropping gnome-print output device and use xpdf one? Cairo here would be possible but xpdf patch for cairo still doesn't implement type 3 support. Also I think there would be many feathures like text search that would be hard to implement with cairo.
*** Bug 158931 has been marked as a duplicate of this bug. ***
*** Bug 154646 has been marked as a duplicate of this bug. ***
*** Bug 156740 has been marked as a duplicate of this bug. ***
*** Bug 166196 has been marked as a duplicate of this bug. ***
I wonder if this PDF isn't showing glyphs because of a similar issue. http://particle.phys.uvic.ca/~cmb/pdf/gnucpp.pdf It is displayed OK in xpdf.
Closing WONTFIX. GPdf is no longer maintained. Please use evince for your pdf viewing needs. http://www.gnome.org/projects/evince Evince has support for Type 3 fonts.
evince 0.5 (with cairo) does correctly render these documents ... but it takes several minutes of 100% CPU usage to do it, and they look crappy when it's done (all pixelated, no antialiasing). Compare gv, which renders them instantly and cleanly. (This is a 3GHz Pentium-M.) Recommend reopening, reassigning to evince, retitling "severe performance problems and bad rendering with Type 3 fonts." (May well be a poppler issue.) Potentially related are bug 170207, bug 314847, and bug 317532.