Bug 85259

Created attachment 6685 [details]
original_document

Created attachment 6686 [details]
print_preview

You have to make the fonts accessible (and found) by ghostscript, which is used by the print preview and by the CUPS server when printing. You have 2 solutions:
1) adapt ghostscript configuration to access your fonts (which should be the case in a normal Linux distribution)
2) embed fonts in your printed document: in the print dialog, use the "System Options" button, go to the "Fonts" section and enable font embedding

If this solves your problem, please close this bug report.

I was having the same problem, and Michael's Fix #2 solved the problem.  (I don't know how to do Fix #1; if it's already done automatically, as Michael suggests, then this bug is probably a duplicate of Bug 59367.)

UNCONFIRMED (batch reassigning messed this)

In the past, I have done option #1 (It was a big pain in the rear), but it did not help the situation, even though Ghostscript could match up the correct true type fonts at its processing console.
      
On several other occasions, I have tried option #2, but it seemed to have done nothing. I have even informed KDE and Qt of my font paths.
 
Look I am not wanting to flame here, but I have honestly experienced this bug on every BSD and Linux distribution that I have used since early 2002. Prior to that point, I never even attempted to print anything. How can this seriously happen for so long on so many different machines?

Moreover, if font embedding is to be the magical solution, why doesn't KDE automatically configure the font embedding and matching to the proper paths?

I tried both of those two tips too, and could not make it work either. I included the fonts, so that they worked in when running "gs prfont.ps". For instance, I tried the font Rudelsberg, like this:

/Rudelsberg DoFont

Despite spitting out a lot of missing font messages, the font did appear correctly, like it did within KWord. But when I tried to print that font in KWord, I got a pop-up Ghostview error message about "stackupderflo". Also, when trying to use the Times font, "gs prfonts.ps" reports that the font is being replaced by Times New Roman and displays just fine. When printing in KWord, however, the font is replaced by a san serif font.

It would be very nice indeed to get this working properly.

Oops, a few typoes there. That error message should be "stackunderflo", as in this:

------8<------
A print error occurred. Error message received from system:

gs -q -dSAFER -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=$out{/home/thomas/magicgassavingdevice.pdf} -sPAPERSIZE=a4 -c .setpdfwrite -f '/tmp/kde-thomaslTMInb/kdeprint_DAvBoiuu' : execution failed with message:
Error: /stackunderflo in --noaccess- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stop ed_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %opa ray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostri gval-- --nostringval-- --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1053/1417(ro)(G)-- --dict:0/20(G)-- --dict:182/200(L)-- Current allocation mode is local Current file position is 58859 ESP Ghostscript 7.07. : Unrecoverable error, exit code 1
----->8-------
 

Solving the font problem is not an easy task and is very system-dependent. To make the printed document use the same fonts as in the application, there are 2 ways:
1) make the fonts available to the rasterizer (ghostscript) by adapting its font path; however some problems may popup, because the rasterizing process is done in the server environment, and possibly on another machine where the fonts (especially the user-defined ones) are unavailable
2) embed the fonts in the printed document; some problems may also popup because of embedding failure, which is Qt-related, and where kdeprint cannot do anything; it also makes the print data larger and the print process time slower.

For WYSIWYG result, I always advise to embed fonts.

I made all the fonts available to ghostscript, and they work fine there too. Also, I embedded the fonts in the printed document. (It was on by default here.) The results are still wrong. To summarize:
1. Ghostscript shows Times New Roman instead of Times, which is perfectly acceptable. The KWord prints Nimbus san serif instead of Times. Something is wrong, obviously
2. I tried all settings for embedding, from none, to partial, to full. All with the same result.

Though point 1 fixes some fonts, KWord still fails when either:
1. The font is incomplete, even though the missing characters aren't being used.
2. The font is missing and will be replaced by a different font.

It would be interesting that you post a PS file generated by KWord (use the "print to file" printer). BTW, does the problem already appears in the generated PS (print to file and view the result with whatever you like).

Michael.

Created attachment 12455 [details]
Font test

This file has two sentences: one in Times and one in Times New Roman. It really
does look like the Times font has been replaced with Helvetica. Obviously,
since KWord can't print files with the other problematic fonts, I can't
demonstrate those.

Created attachment 12456 [details]
Font test, take 2.

It doesn't seem like KWord handeled that page very well, so I had to put in a
few blank lines in the beginning of the document.

Indeed, the file does not mention the "Times" font, so the print result as well as the preview are *logical*. KDEPrint cannot do much about it, the print content is the responsability of the application and Qt. There's most probably a font substitution, but this is out of the control of kdeprint.

Michael.

OK, did a little trial here. Using the font Times in KEdit worked just fine, so that part is definitively a KWord bug, and not a kdeprint bug. The Rudelsberg font, however, did not work in KEdit either, so that would be a kdeprint or Qt bug?

KDEPrint does not control the print content and, for example, how the fonts are substituted or embedded. What can happen is that Qt fails to embed the font, but this is usually stated in the generated PS file, just have a look.

Michael.

Regarding comment #16, where should this bug be redirected then? Should this be redirected toward Qt or some other KDE printing mechanism, for I have observed this problem globally in many rich font KDE applications, such as Konqueror, when printing?

Like Thomas, I have tried both means of getting fonts to work, and it was especially disheartening years ago after creating the new Ghostscript Fontmap files only to find that WYSIWYG printing does not work in KDE. In any case, the end user should never have to go through the painstaking efforts of developing new Fontmap files, because Ghostscript is a very tempermental application. Perhaps te software distribution could do this task, but the situation is just dismal at best.

As of today, 2005-09-07, per the suggestion of comment #16, I notified Trolltech of this bug and have asked them for assistance.

I received a response from Trolltech asking for more specific information, perhaps a code sample that can produce this. Could someone who is qualified with this be in charge of coming up with a code example, because I clearly lack the expertise required to do this.

The Trolltech bug #85392

<---Begin Trolltech Response--->
Hello,

This is an auto-reply to your email.

We have read your email but require more time to deal with it. We have
assigned it the issue number #85392. Please use this number if you email
us about the issue. We regret that we cannot guarantee a personal reply.

For a list of known issues and feature requests, use the online Task
Tracker:

http://www.trolltech.com/developer/tasktracker.html

When submitting bug reports please make sure that you tell us which
product (including the exact version) you are using, and how you have
configured your installation.

If you provide a small self-contained and compilable example that
demonstrates the problem we will probably be able to identify the cause
and propose a solution much faster than if you just give a general
description. Typically bug reporters modify one of the smaller Qt
examples to reproduce their problem.

If you are experiencing a build problem, make sure that your compiler is
correctly installed and that you have applied any necessary patches; see
these pages for further information:

    http://www.trolltech.com/developer/platforms/index.html
    http://www.trolltech.com/developer/compilers/index.html

You might also want to try the latest Qt snapshot to see if the problem
has already been addressed in our development tree. Snapshots are
available from

    http://www.trolltech.com/download/snapshots.html

Best regards,
The Trolltech Support Team
--
http://www.trolltech.com

======================================================================
You're invited to Trolltech Developer Days 2005!
Meet Trolltech developers, executives and partners, hear in-depth
seminars on Trolltech technology and network with hundreds of
your peers at the 2005 Trolltech Developer Days!
Register online today at http://www.trolltech.com/devdays2005
======================================================================

<---End Trolltech Response--->

It's not really about code, but more about font problem. So be sure to state which font fails to embed/work in Qt. The best would be to try out with a Qt-only application. In Qt examples (in the Qt source tree), there used to be a qtextedit example that would suit the curretn situation. Try to use it with the offending font.

Michael.

*** This bug has been confirmed by popular vote. ***

@ Thomas Kjosmoen (comment 10):

"shows Times New Roman instead of Times"
----------------------------------------
  Please run "qtconfig". Select the "Fonts" tab. Locate the "Font Substitution" 
  pane. Be aware, that this dialog isn't intuitive at all: the big white space
  does *not* list a complete table of all font substitution pairs. You'll need
  to scroll through the list of fonts in "Select or Enter a family:" and watch
  out for what appears in the "Current Substitutions:" pane. You'll notice that
  once you select "Times New Roman" that it gets substituted by "Times". Check
  if you have multiple substitutions enabled there, like "Nimbus sans serif".

"I tried all settings for embedding, from none, to partial, to full"
--------------------------------------------------------------------
  *Where* did you try this? (I'm not aware where you should be able to set such
  different modi.)


A font being incomplete may trigger some Qt code path (I do not understand C++ or Qt, mind you) that does prevent from embedding. 

For a "missing font" it is obviously one natural reaction to substitute it automatically (The alternative would be to throw and error and abort).


Cheers,
Kurt

Due to feedback timeout, I'll close this bug by Feb 1, 2007 (unless someone takes up Michael's request from comment 20).

Also, re-assigning bug to KOffice, because KDEPrint is not responsible for non-embedded fonts sent by a PS-printfile creating application.

closing bug due to missing feedback timeout