Version: (using KDE KDE 3.1.2) Installed from: Compiled From Sources Compiler: GCC 3.3 OS: Linux When a font is installed in Basic Mode with the Control Center Font Installer -- installed in the users home directory tree -- it works fine in the print preview but will not print unless it is embeded in the PS file.
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...