I cannot help but be blunt here: the state of WYSIWYG printing in Linux and BSD is dismal. Only a handful of applications actually produce WYSIWYG output with respect to fonts. This task is not made any easier in fact by many applications' dependence upon Ghostscript for printing. Ghostscript has one of the most difficult and tedious font installation procedures for adding True Type fonts to its Fontmap.GS and Fontmap.* files. In my opinion it is too much work to configure these fonts by hand, so portage's mechanism for installing True Type as well as others should automatically process and add and make these fonts available to Ghostscript. Here is some useful reading about the required procedures for Ghostscript: http://linux.about.com/library/howto/font/blfont5.htm http://astro.uni-tuebingen.de/software/ghostscript/Fonts.htm http://www.pgaccess.org/index.php?page=KickAssFonts Here is some useful documentation about how to test whether Ghostscript can actually load and preview the files: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/fonts/type1-fonts-ghostscript.html Here are some interesting bugs that illustrate the abysmal printing output: http://bugs.kde.org/show_bug.cgi?id=85259 http://bugs.kde.org/show_bug.cgi?id=59367 As for KDE, it would be helpful if the ebuilds would automatically add the new fonts and make Qt and KDE aware of the fonts and the paths for printing. If you need proof of the abysmal state and whether it has been addressed, create a document in the Mozilla, KOffice, Abiword, GNUMERIC, and Evolution and follow the following steps: 1.) create a document that uses all fonts on the system, including webdings and the kanji and foreign ones; 2.) print the output to a PDF; and 3.) verify that the fonts actually appear as the do in the document and not substituted or missing. Reproducible: Always Steps to Reproduce: 1. Install a font from media-fonts/* Actual Results: Ghostscript, KDE, and Qt are not made aware of the fonts for print embedding or inclusion. Expected Results: Ghostscript should be made aware of the fonts to their fully-qualified paths, including the permutations for bold, italic, etc. KDE and Qt need to be automatically informed at a global level of the font paths for embedding into print documents.
FWIW, there is work in progress for allowing fontconfig support in GS 8.x by one of our (Scribus Team) guys.
(In reply to comment #1) Is there a place that this work is being discussed or documented online? If this is absolutely useless, I apologize; but after doing some searching, I came across Debian's DEFOMA tool (http://packages.debian.org/unstable/admin/defoma) that, from what I can guess, accomplishes some of these font tasks. Perhaps some of the code from this utility could be salvaged and pieced together into the font eclass.
Created attachment 68840 [details] A revised font.eclass and associated management utilities that associate TTF and PFB fonts with Ghostscript Gentoo Postscript Font Manager Version 0.1 Thomas Kjosmoen <gentoo@kjosmoen.com> Matt T. Proud <khanreaper@nerp.net> HISTORICAL CONTEXT Debian offers automatic management of fonts with Postscript by the means of a utility called Debian Font Manager (DEFOMA). This is a very convenient development for Debian, because it allows for True Type and other types of fonts to be automatically installed and registered with Ghostscript, the main Postscript parsing engine available in Linux. Unfortunately, Gentoo never offered such a font manager, even though its font.eclass automatically handled font registration with fontconfig and other mechanisms. RATIONAL FOR MANAGER The main goal with this utility is to increase the simplicity of font management in Gentoo. Simply stated, prior to now, it the process of adding fonts to Ghostscript has been a painful procedure, one that frequently does not go well. Not only is the majority of online documentation antiquated, but it is often unhelpful; and none of this even begins to address just how temperamental Ghostscript can be when an error occurs, let alone a minor syntax error. THE OPERATION OF MANAGER To abate these problems, this management package provides small additions to the font.eclass and offers two new utilities: makegsfontmap and gsfonts-update. When a font package that uses font.eclass is used (This is explicitly stated due to the fact that freefonts currently does not use it.), a Ghostscript Fontmap file is created from the fonts using the makegsfontmap utility, which places the Fontmap file in the root directory into which the fonts were installed. After the merging of the packages completes, the new eclass calls gsfonts-update, which recursively scans /usr/share/fonts for Fontmap files, and automatically adds them to /usr/share/ghostscript/*/lib/Fontmap for inclusion into the Ghostscript font search path. These processes are automatic and should require little user attention. If the user removes an existing font package, its respective Fontmap file is dereferenced from /usr/share/ghostscript/*/lib/Fontmap. Systems administrators should also be able to install items into /usr/share/fonts, use the makegsfontmap utility, and reference their own fonts easily using gsfonts-update. INSTALLATION PROCEDURE Backup /usr/portage/eclass/font.eclass; the new font.eclass should replace /usr/portage/eclass/font.eclass. gsfonts-update and makegsfontmap belong in /usr/sbin. USAGE NOTES One is encouraged to re-emerge any installed fonts so that they can be automatically mapped and made available to Ghostscript. Furthermore, one must be aware that not all font packages make use of font.eclass, so this package's features may not apply to all equally. THE DEVELOPERS This project has been a joint development between Thomas Kjosmoen and Matt Proud. QUESTIONS, CONCERNS, AND FEEDBACK We welcome any feedback at our aforementioned e-mail addresses. It is suggested that both of us are jointly contacted so that a complete communication context can exist. FILE REVISION 0.1 Matt T. Proud <khanreaper@nerp.net>
There are some bugs in the submitted utilities. I'll try to upload fixed and improved files later today.
Created attachment 68990 [details] A revised font.eclass and associated management utilities that associate TTF, PFA, and PFB fonts with Ghostscript These new files obsoletes the previous version. There are a few fixes, and I added support for PFA files. For a summary of the changes, read the included README.txt.
Refer to http://bugs.scribus.net/view.php?id=2075. The work that awaits is the autohell work AFAIK.
Once this is in gs, the eclass wont be needed, only fontconfig.
I have a fontconfig support patch for gs 8.x done and working. All it needs at this point is integration into the gs build system, something I just haven't found time for due to the demands of work, uni, and my role with Scribus. I've attached what I think is the lastest version of the patch (I haven't looked at this for some time). You'll need to hack the Makefile to add -lfontconfig to LDFLAGS and add '#define HAVE_FONTCONFIG' to the top of gp_unix.c because the build integration is absent. You might also have to ensure that the fontconfig libs and headers are on LD_LIBRARY_PATH and CPATH, respectively. Again, this is only necessary because we're not using pkg-config to find fontconfig, since the build integration is missing. It's against 8.51cvs, IIRC. Please test, and if someone here has the time to hook it up into the gs build system I'll be very thankful. -- Craig Ringer craig@postnewspapers.com.au
Created attachment 72032 [details, diff] Adds fontconfig support to gs 8.5x
so what's the current status here, has the patch been proposed to the gs herd (printing ?) yet.
I am all open for the patches, does this way work here? Could it help us to get cjk-fonts working again with gs-esp-8 and gs-gnu, gs-afpl?
IIRC CJK fonts in gs are special, and must be loaded via another interface. I wasn't able to obtain suitable fonts and documents to test with when working on the fontconfig patch, but Russel (`ghostgum') also thought it wouldn't affect CJK loading. If someone has some CJK fonts and a PostScript document that uses them, I'd be happy to test this out.
Okay, I've added a patch based on attachment #72032 [details, diff] to ghostscript-gnu. Many thanks Craig. Fonts looks quite better once printed from Konqueror, and CJK glyphs are correctly printed, too.
I added the fontconfig patch to ghostscript-esp, so now 2 of 3 ghostscripts are patched. remaining ghostscript-afpl still needs to be fixed.
ghostscript-esp 8.15.2 has been released few days ago (http://www.cups.org/articles.php?L378) do these patches apply to the new release as well?
yes, they do. I have already bugged them upstream: http://www.cups.org/espgs/str.php?L1631+P0+S-2+C0+I0+E0+Q In fact I added them to 8.15.2 but named the ebuild differently because I missed the release ;)
I just tested this with the latest ghostscript-esp that seems to include this patch. It uses system fonts properly now and displays them correctly. That's a huge improvement. Thank you for that. CJK glyphs (and all other multibyte characters) don't work for me, though. The old version (ghostscript-esp-7.07) had two CJK fonts for Japanese that I could use without a hitch. Unfortunately these fonts don't seem to be included anymore. I'm very interested in using TTF CJK fonts with ghostscript, or Unicode glyphs in general; so far it does not seem to be possible to do so natively in Ghostscript.
ghostscript-gpl upstream is not working on this in their bug: http://bugs.ghostscript.com/687595
http://bugs.ghostscript.com/show_bug.cgi?id=687595 silly, ghostscript bugz does not allow short names
Finally resolved upstream by the merger with ghostscript-esp, first fixed ghostscript-gpl version is 8.60. Thanks to everyone involved.