After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 112506 - gpdf doesn't render glyphs from Type 3 font
gpdf doesn't render glyphs from Type 3 font
Status: RESOLVED WONTFIX
Product: gpdf
Classification: Deprecated
Component: general
unspecified
Other Linux
: High major
: ---
Assigned To: Martin Kretzschmar
Martin Kretzschmar
: 122021 129387 131198 131697 132706 134772 135564 137365 139674 141359 142172 142371 154249 154646 156740 158188 158931 161718 166196 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-07 17:08 UTC by Colin Walters
Modified: 2006-01-29 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pdf file which fails to render (60.58 KB, application/pdf)
2003-05-07 17:09 UTC, Colin Walters
Details
Another pdf with Type 3 fonts that misrenders (20.51 KB, application/pdf)
2003-06-25 21:25 UTC, André Dahlqvist
Details
another file that fails to render (214.29 KB, application/pdf)
2004-08-24 20:02 UTC, Lee Revell
Details

Description Colin Walters 2003-05-07 17:08:15 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.
Comment 1 Colin Walters 2003-05-07 17:09:30 UTC
Created attachment 16336 [details]
pdf file which fails to render
Comment 2 Martin Kretzschmar 2003-05-07 18:42:32 UTC
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
Comment 3 André Dahlqvist 2003-06-25 21:25:59 UTC
Created attachment 17773 [details]
Another pdf with Type 3 fonts that misrenders
Comment 4 André Dahlqvist 2003-06-25 21:27:28 UTC
I guess the above pdf also misrenders because it uses Type 3 fonts?
The document contains several tables, and they render correctly in xpdf.
Comment 5 Martin Kretzschmar 2003-12-19 13:12:40 UTC
André: yes, same problem, sorry.
Comment 6 Martin Kretzschmar 2003-12-19 13:14:03 UTC
*** Bug 129387 has been marked as a duplicate of this bug. ***
Comment 7 Martin Kretzschmar 2004-01-24 18:41:20 UTC
*** Bug 131697 has been marked as a duplicate of this bug. ***
Comment 8 Martin Kretzschmar 2004-01-24 18:59:43 UTC
*** Bug 131198 has been marked as a duplicate of this bug. ***
Comment 9 Scott R. Godin 2004-02-08 20:28:31 UTC
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
Comment 10 Luis Villa 2004-02-17 03:40:46 UTC
*** Bug 132706 has been marked as a duplicate of this bug. ***
Comment 11 Luis Villa 2004-02-17 05:15:28 UTC
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?
Comment 12 Martin Kretzschmar 2004-02-19 11:32:03 UTC
*** Bug 134772 has been marked as a duplicate of this bug. ***
Comment 13 Martin Kretzschmar 2004-02-20 11:53:53 UTC
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).
Comment 14 Luis Villa 2004-02-21 18:21:29 UTC
Thanks for the feedback, Martin. Hopefully someone will find cycles
for this soon :)
Comment 15 Martin Kretzschmar 2004-02-27 23:27:06 UTC
*** Bug 122021 has been marked as a duplicate of this bug. ***
Comment 16 Rodd Clarkson 2004-03-05 00:20:45 UTC
*** Bug 135564 has been marked as a duplicate of this bug. ***
Comment 17 Martin Kretzschmar 2004-04-17 18:36:20 UTC
*** Bug 139674 has been marked as a duplicate of this bug. ***
Comment 18 Vincent Noel 2004-08-13 17:21:45 UTC
*** Bug 142172 has been marked as a duplicate of this bug. ***
Comment 19 Vincent Noel 2004-08-13 17:28:26 UTC
*** Bug 142371 has been marked as a duplicate of this bug. ***
Comment 20 Vincent Noel 2004-08-13 17:30:26 UTC
*** Bug 141359 has been marked as a duplicate of this bug. ***
Comment 21 Vincent Noel 2004-08-17 18:11:23 UTC
*** Bug 137365 has been marked as a duplicate of this bug. ***
Comment 22 Lee Revell 2004-08-24 20:02:18 UTC
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'
Comment 23 Vincent Noel 2004-10-01 17:08:12 UTC
*** Bug 154249 has been marked as a duplicate of this bug. ***
Comment 24 Vincent Noel 2004-12-10 18:47:08 UTC
*** Bug 158188 has been marked as a duplicate of this bug. ***
Comment 25 Martin Kretzschmar 2004-12-20 18:05:02 UTC
*** Bug 161718 has been marked as a duplicate of this bug. ***
Comment 26 Nickolay V. Shmyrev 2004-12-21 17:13:00 UTC
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.

Comment 27 Vincent Noel 2005-01-05 18:01:54 UTC
*** Bug 158931 has been marked as a duplicate of this bug. ***
Comment 28 Sebastien Bacher 2005-01-14 00:00:26 UTC
*** Bug 154646 has been marked as a duplicate of this bug. ***
Comment 29 Sebastien Bacher 2005-01-14 00:15:44 UTC
*** Bug 156740 has been marked as a duplicate of this bug. ***
Comment 30 Vincent Noel 2005-02-03 22:19:56 UTC
*** Bug 166196 has been marked as a duplicate of this bug. ***
Comment 31 Ilguiz Latypov 2005-05-27 22:49:16 UTC
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.
Comment 32 Martin Kretzschmar 2005-11-13 13:19:22 UTC
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.
Comment 33 Zack Weinberg 2006-01-29 17:55:49 UTC
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.