Bug 62054

I have established that this problem is in Qt.

So, I am closing the bug.

--
JRT

Created attachment 2253 [details]
EXPERIMENTAL to fix the problem

This patch fixes the problem on my system.

YMMV
--
JRT

Changed Summary to reflect actual problem. 
 
All PostScript data files have the font names IF (and only if) you don't embed 
the fonts.  They are correct IF you DO embed the fonts. 
 
The only real problem is the PostScript font names since without the correct 
font names, GhostScript or a PostScript printer can NOT find the correct 
fonts. 
 
The source of this problem is in the Qt module: "qpsprinter". 
 
I have attached a patch for Qt which resolved the bug on my system. 
 
Therefore, I am marking the bug as closed. 
 
-- 
JRT 

Duh!

--
JRT

Subject: Re:  KWord uses the wrong font names in PostScript files

On Sunday 17 August 2003 04:39, you wrote:
> Created an attachment (id=2253)
>  --> (http://bugs.kde.org/attachment.cgi?id=2253&action=view)
> EXPERIMENTAL to fix the problem
> 
> This patch fixes the problem on my system.

Great.
Can you send it to qt-bugs@trolltech.com, with an explanation of the problem and
solution?
I'd also suggest to rename the two static bools so that 1) they start with qt_
2) it's clearer what's the difference between the two is :)

I can't really comment on the patch itself, not knowing the code (nor Postscript).
Thanks a lot for your help.

Created attachment 2281 [details]
Alpha/Beta patch for Qt-3.1.2

I worked on this a little more, cleaned up the code some.

I would rate this as a Beta if you have an up to date system.

New versions of XFree86, Xft, FreeType2, & FontConfig.

Otherwise this is Alpha and use at your own risk. :-)

--
JRT

Created attachment 2282 [details]
Alpha/Beta patch for Qt-3.1.2

OOOOOOPPPPPPSSS, major error.  I posted the Bzip2 version.

This is plain text.

--
JRT

Comment on attachment 2282 [details]
Alpha/Beta patch for Qt-3.1.2

This is plain text, the other one is bzip2.

--
JRT

Subject: Re:  PostScript files generated by Qt have wrong font names if not embeded

download_0 could be named downloadInternal

embedFonts vs qt_embedFonts is still very confusing (what's the purpose of each bool?)
Looks like one is the QSetting value, and the other is whether to really embed fonts?

Hmm, I see that this is all for 3.1.2, I wonder if 3.2.0 improves the situation already.

Subject: Re:  PostScript files generated by Qt have wrong font
 names if not embeded

David Faure wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
> You are a voter for the bug, or are watching someone who is.
>      
> http://bugs.kde.org/show_bug.cgi?id=62054     
> 
> 
> 
> 
> ------- Additional Comments From faure@kde.org  2003-08-20 10:46 -------
> Subject: Re:  PostScript files generated by Qt have wrong font names if not embedded
> 
> download_0 could be named downloadInternal

Perhaps I'm just not very creative at names, or perhaps there really isn't 
a good name here since: "download_0" is just exactly the same as: 
"downlosd" except that it has a conditional in front of it for: PFA, PFB, & 
TTF fonts ONLY.  It is just a way of making the code smaller.

That is, the classes: "QPSPrinterFontPFA", "QPSPrinterFontPFB" & 
"QPSPrinterFontTTF" inherit: "QPSPrinterFontPrivate" and redefine: 
"download_0".  The other classes which inherit: "QPSPrinterFontPrivate" 
redefine: "download" (if they use it) and by so doing eliminate the 
conditional expression.

> embedFonts vs qt_embedFonts is still very confusing (what's the purpose of each bool?)
> Looks like one is the QSetting value, and the other is whether to really embed fonts?

The flag: "qt_embedFonts" is the variables set according to the QtConfig 
setting and is the one actually being used.  The flag: "embedFonts" was 
left only because it appears to be tangled up in the conditional compile 
directives.  It has no other function.  It could be eliminated by someone 
with more complete knowledge of the code by changing the conditional 
compilation directives.

> Hmm, I see that this is all for 3.1.2, I wonder if 3.2.0 improves the situation already.

I tried the: "textedit" example and it isn't any different with 3.2.0.  I 
have not tried to patch 3.2.0 yet.

--
JRT