Bugzilla Bug 104512

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 an attachment (id=68840) [edit]
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 an attachment (id=68990) [edit]
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 an attachment (id=72032) [edit]
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 [edit] 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.