Bug 140251

Summary: custom truetype font not sent to printer
Product: [Unmaintained] kword Reporter: Andrew J. Kroll <a>
Component: generalAssignee: Thomas Zander <zander>
Status: RESOLVED FIXED    
Severity: normal CC: zander
Priority: NOR    
Version First Reported In: 1.6.1   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Andrew J. Kroll 2007-01-18 15:06:11 UTC 
Version:           1.6.1 (using KDE 3.5.5, compiled sources)
Compiler:          gcc version 3.4.6
OS:                Linux (i686) release 2.6.18.1

I have a truetype/opentype font that I have created myself. It displays correctly, but when I print, the font is subsituted with a totally different font on both print-preview and on the laser printer. Openoffice won't even display it right on the screen. The font has no problems rendering on the screen, for anything else, and firefox prints it fine. The font also works just fine under the usual M$ products. I have placed a copy of the font at http://dr.ea.ms/~oldfart/coder/ so that the development team may reproduce the bug. I released the font w/the GPL liscence, so it is fine for anyone to use it... that is, if they like the retro looking font... :-)
It is the opentype one that is installed in the system via the usual KDE font installer, and it placed it at /usr/local/share/fonts
It *could* be the font, but I kind of doubt that it is, unless there is a printer output flag that I missed (I will check) but that should not matter since firefox was able to print it just fine and dandy... perhaps KDE follows the font flags rules a bit to close?
Comment 1 Kurt Pfeifle 2007-02-01 12:33:00 UTC 
This is a specific incarnation of the more general and deeper problem which we suffer with KDE and Qt, namely that it does not send *any* TrueType font to the printer (not just your custom one):

  * Qt can not produce PostScript Level 2 or PostScript 3; it is limited to 
    PostScript Level 1. This in itself already is bad enough. 

  * Our KDE applications rely on Qt library functions to create PostScript. 

  * One of Qt's biggest flaws (on top of "PS Level 1 only") is this: when it
    has to process TrueType fonts, it converts them into "Type 3" (*) fonts and
    embeds the font into the generated PS file (**).

  * One drawback with this specific Type 3 conversion is that the "visual" 
    quality of the result is sub-par (this need not be so -- I've seen better
    results of TT --> Type3 font conversion than what we get with Qt).

  * The biggest problem however is this: if you convert a Qt-generated 
    PostScript file into PDF (f.e. by using the "ps2pdf" utility), the embedded
    Type 3 font has no name (look at "File --> Properties --> Fonts"). Hence,
    the PDF is not "searchable", you can't extract text from it, or you can't
    feed it to a screenreader or KTTS (accessibility).

I don't have any trust that this will *ever* be fixed during the KDE 3 timeline. Let's hope for KDE4.

Firefox prints it just fine because Firefox relies on its own means to generate its PostScript when it comes to printing, and it obviously is better in handling TrueType fonts.
    
As to why OpenOffice.org doesn't handle your font correctly, I don't know. OOo also does "its own thing" when it comes to font handling (it even ships its own font metric files for the 35 base fonts defined for PS Level 2)....

-------------------
 (*)  "Type 3" describe glyphs by means of ordinary PostScript procedures.
(**)  Ghostscript (at least more recent versions) can handle TrueType fonts by
      itself just fine.

.
Comment 2 Thomas Zander 2007-04-20 15:32:24 UTC 
Fixed in KWord2.0