Bug 59367

To replicate the bug:

Get a new font that you don't have installed on your system and is (well) weird
enough so that you can identify it easily.

Install it [as user] with the Control Center Font Installer in: "Basic Mode"

Configure KDE and Qt not to embed fonts:

For Qt run: qtconfig, under the "Printer" tab, uncheck the: "Enable Font
embedding" box.

For KDE, in Control Center: Peripherals => Printers: Print Manager => Configure
Manager, select Fonts and uncheck the "Embed fonts in PostScript data when
printing" box.

Now open KWRITE and make a short file using the weird font and first do a print
preview and then print it.

Do the fonts match? 

Created attachment 1818 [details]
Wrapper script for GhostScript.

This wrapper script for the GhostScript executable: "gsc" should be installed
in your: "$KDEDIR/bin" directory.  Then make a link:

/usr/bin/gs -> $KDEDIR/bin/gsk

Edit the last line of this file if needed with the path to: "gsc" on your
system.

Created attachment 1819 [details]
'profile.d' script

This 'profile.d' script should be installed in your: "/etc/profile.d"

Edit the script to include all directories where you have fonts installed.

Directories with a: "Fontmap" should be added to: "gs_lib" and directories
without a: Fontmap" should be added to: "gs_fontpath".

I have developed a work around for this problem. 
 
If you install the above two files according to the instructions, the problem 
should be fixed. 
 
NOTE: 
 
1.	If you have other: 'profile.d' scripts which add to the GS_LIB | 
GS_FONTPATH env strings, you should add these to the: 'for' structure in: "gsk" 
so that GhostScript can find them when it is run from the print filter. 
 
2.	This should work even if your system doesn't support: 'profile.d' with 
a little work.  Your: 'profile' script will need to source: 
"/etc/profile.d/gs.sh" 
 
3.	I have not tested this with CUPS, but I think that it should work. 

What has the "mode" go to do with this? You'd still have the problem in
"Advanced" mode. Also, the installer is "kcmfontinst" not "kcmfonts".

But this is *not* a KDE bug - wouldn't it be better to report this to
Ghostscript, CUPS, etc?

"Component" corrected.

I am marking this as fixed and will submit a patch in a week or so after a
comment period.

--
JRT

Subject: Re:  Fonts installed in Basic Mode won't print unless
 embedded

Craig Drummond wrote:

> What has the "mode" go to do with this? You'd still have the problem in
> "Advanced" mode. 

No, you currently don't have the problem in the advanced mode because your 
program makes an entry in the master GhostScript Fontmap.GS which contains 
the full path to the font -- so GhostScript finds it.

> Also, the installer is "kcmfontinst" not "kcmfonts".

Apparently I had a small problem with the BugZila Wizard.  Sorry about that.
> 
> But this is *not* a KDE bug - wouldn't it be better to report this to
> Ghostscript, CUPS, etc?

It is clearly a system bug -- however, it *is* a KDE issue.  I have 
determined that it is not a GhostScript problem and have found the code in 
Bash where the problem occurs.  But it does not appear to be a Bash bug 
because Bash simply calls: "getpwuid()" and gets the wrong answer -- 
perhaps because it gives the GLibc call the wrong argument.  I will 
continue to work on this and a bug report for Bash and GLibc will we entered.

HOWEVER, if we are going to use GhostScript for rendering fonts in KDE, we 
MUST have a work around for this.

And, this is needed for Advanced Mode if: "Fontmap" files are going to be 
placed in individual directories chosen by the font installer.

By doing this, we set a de facto standard for others to follow.  This 
standard which works with the current system configuration is better than 
the Gnome Print approach of installing its own font system

--
JRT

Created attachment 1907 [details]
Fix for the problem -- works with GNUlpr

I have only tested this with GNUlpr.

Please advise me of your success | failure with CUPS.

NOTE: this patch also fixes the general problem of GhostScript not finding
fonts when printing a PS file without embedded fonts.  BUT, you must also have
the fonts configured in GhostScript for it to work.  RTF GhostScript Manual!
:-)

--
JRT

The specific problem with GhostScript not finding fonts installed in the $HOME
directory tree appears to caused by a problem in Bash.  When the print
spooler/filter calles GhostScript -- even if as the user that submitted the
print job -- a login script in bash does not get the correct value of HOME.  The
$HOME directory has a value of: "/" rather than being the correct value for the
user as returned by: "id -un" (as listed in: "/etc/passwd".  This is clearly a
system bug.

--
JRT

NOTE: Patch is for KDE_3_1_BRANCH.

--
JRT

Created attachment 2030 [details]
improved: "gsk" script.

The attached script is more general than the one in the patch.

This is just for LPR.  Set it up the same as the patch.

It will source _all_ 'profile.d' scripts that add to GS_LIB or GS_FONTPATH and
will read the HOME directory from: "/etc/passwd" file if it is readable.  Since
I only have Linux, I don't know how many other *NIXs this will work on.

Created attachment 2058 [details]
Replacement for the CUPS pstoraster script

This hacked script works on my system.	I don't know which other *NIX systems
it will work on.

To use this, simply replace the existing script which is normally in:

	/usr/lib/cups/filter

If your copy of ESPGhostScript was not named: "gs-cups" or was not installed
with a prefix: "/usr/local", you will need to make minor editing to the script.


--
JRT

Changed title and product.

Will post an improved patch for: "kdebase" for LPR and a patch for
ESPGhostScript for CUPS.

--
JRT

Created attachment 2068 [details]
Patch for users of LPR

This patch should solve the problem for non-networked systems using LPR.

Created attachment 2069 [details]
Experimantal patch for ESPGhostScript

This solves the problem when I tested it on my system.	But, it has not been
thourghly tested since I do not normally use CUPS.

This is for the current version of ESPGhostScript: espgs-7.05.6

I am closing this as "later" since the problem needs a proper fix.

That is, the two scripts are just work arounds.

--
JRT

Created attachment 2190 [details]
Patch for LPR updated

I have updated the script to fix problems I had running: "printtool"

Closed by mistake.

--
JRT

I have tested the LPR patch since I posted it.

I have used it for all of my printing and it appears to work.

I have updated the patch to fix a small problem with: 

    gs -h

when using my changes for the: "startkde" script.

and:

    gs -help

just in case. :-)

So, I think that is no ready to use although I am still calling it: 'experimental'.

My thought is that we may eventually have a KDE front end for the GhostScript SO
which would replace the script: "gsk".

The patch is for the 3.1 branch, but since it only adds things it should work on
HEAD just as well.

--
JRT

Created attachment 2628 [details]
Patch for LPR release candidate 1

Created attachment 2664 [details]
Patch for LPR release candidate 2

Minor error in patch corrected.

Created attachment 2697 [details]
Release version of patch for LPR systems

The gsk directory was moved to kdeprint in the kdebase source tree.

Created attachment 2924 [details]
Patch foomatic-rip to look into $HOME/.fonts

Printer PPD's generated from linuxprinting.org use the foomatic-rip interface
to ghostscript. The attatched file patches this to allow CUPS to search in
$HOME/.fonts for per-user fonts. This will only work when printing to a printer
attatched to a machine with access to $HOME/.fonts - i.e. a local usb/paralel
printer.

foomatic-rip can be / is used by other printing systems - and can probably be
modifed by calling the "set_gs_env_vars($user)" function, assuming the printing
system passes the user name to foomatic-rip. Not having acces to these, I
haven't modified foomatic-rip for these systems.

I am currently not working on this.

--
JRT

Created attachment 3374 [details]
Bug fix for previous (1.0) version

There is always a version 1.0.1 isn' there.

--
JRT

James, what's the status of all this?

Timeout to request by Cristian [2005-09-22 06:41], no activity on this topic by James since 3+ years.

Re: comment #26.

I reported the problem mentioned above to the Bash developers regarding release 3.0.  After some discussion, they agreed that there was an issue and it needed to be fixed.

I abandoned work on 'gsk' after figuring out how to configure my system so that it works without having to make any other changes.  However, this is not a solution for CUPS.  

CD believes that his global "Fontmap" file will cure the problem if fonts are installed with the KDE Font Installer.  I think that this is a kludge which does not fully solve the problem.  I ask that other users that use CUPS please test to see if fonts installed in the user's ($HOME) directory tree with the KDE Font Installer can be used for printing _with_embedding_turned_off_ in "qtconfig:printer".

So, I really think that with CUPS that it is a CUPS issue since it can not be solved by system configuration.  IWFM, but I don't know if this is true if you use CUPS

Oh, you are here :-)

Thanks for the response, James.

Who is "CD"? What does "IWFM" mean?

> ------- Additional Comments From pfeifle kde org  2007-01-12 01:40 -------
> Oh, you are here :-)


Yes, I have been ill.

> Thanks for the response, James.
> 
> Who is "CD"? 


See comment #5

What does "IWFM" mean?
> 

It Works For Me. :-)

--
JRT

The global Fontmap would only solve the problem for fonts installed system-wide. For fonts installed into $HOME, the foomatic-rip patch mentioned in comment #23 is required. Anyway, the KDE4 font installer no longer creates Fontmap files, and the KDE3.5 one has a config option that is turned off by default...