© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
4d1350f
(Get the code!)
Message-ID: <email address hidden>
Date: Mon, 30 Aug 2004 16:23:02 -0400
From: Matt Swift <email address hidden>
To: <email address hidden>
Subject: more information and maybe solution
I just spent most of today working on this problem. This report
should probably be reassigned to gsfonts and merged with #268225, but
please read further.
I am not going to reassign/merge it myself; I want to leave it in this
case to the Debian developers involved, after considering the
information below. In debugging this problem, I have discovered
possible other problems with the gs-* and tetex-* packages. I want
those developers to read and consider this information rather than
forget about these problems because their immediate cause is in
another package.
The immediate culprit is the 11 Aug 2004 release of gsfonts (version
8.14+urwcyr1.
OK again.
From the gsfonts changelog:
gsfonts (8.14+urwcyr1.
* The "Brief Return From The Hell" release.
* This release is a compound made from the standard gs-fonts *8.11*
and the latest "Type1 URW fonts with Cyrillics"
(http://
the long-standing Serbian glyph problem - closes: #250949
Not even Serbs will be happy that the addition of their glyphs has
somehow broken gs's processing of Courier for everyone around the
world. gsfonts-8.14-3 is disappearing from the archives. I was lucky
enough to find it on the Internet. I didn't try 6.0-2, which is in
stable; I don't know what the consequences are of downgrading that
far.
The problem of mis-sized Courier occurs when gs processes any file
that calls for the Courier font, which does not already contain an
embedded version of Courier. It occurs, for example, when printing a
PDF, and when printing a PS file generated by TeX via dvips (under the
default conditions in which dvips will not embed the "standard 35").
When you force dvips to embed the Courier font, the result looks OK,
regardless of whether dvips embeds uses the Adobe or Nimbus version of
Courier. Why? Because the Nimbus "Courier" font files dvips knows
about (/usr/share/
same as the ones gs knows about
(/usr/share/
Note also that if you view a .ps file with gv when the corrupt gsfonts
are installed, you get corrupt fonts on your screen. If you view the
same file with Acroread instead, it looks fine. The reason is that
Acroread is supplying the non-embedded "Courier" from yet a THIRD
location, e.g., /usr/local/
the submitter of bug #268225 has his system configured in such a way
that when he runs gv, gs is called in an environment that leads it to
use a non-corrupt copy of Courier [i.e., some copy not in the gsfonts
package], but when he prints, gs is called in an environment that
uses.)
In /etc/texmf/
"LW35 URWkb" determines which of two Courier fonts will be used by
dvips (and any other program that may use those map files) and the
setting of "dvipsDownloadB
whether dvips embeds the font or leaves it out, on the assumption that
whatever program renders the .ps file will be able to supply its own
copy of the font. Equivalently, the "-Pdownload35" and "-Pbuiltin35"
options to dvips control embedding.
The file /etc/texmf/
gs to use the same font same font that TeX and dvips know about,
without having to embed the font in the ps file. The best way to do
this with gs-afpl and gs-gpl seems to be to change
/etc/gs-
Fontmap.GS, and to change another Fontmap occurring in the search path
later than the desired fonts, to load Fontmap.GS. (The alternative to
delaying the load of Fontmap.GS is to fashion and distribute a revised
Fontmap.GS to be loaded initially but omitting the standard 35 fonts
removed from it.
Note that unlike gs-afpl and gs-gpl, gs-esp-7.07.1-8 -- whatever
settings a sysadmin chooses in /etc/texmf/
whatever the value of GS_FONTPATH, and whatever Fontmap files the
sysadmin may have created (using defoma-hint or any other means) -- is
always going to use the Nimbus font when it processes a file calling
for a non-embedded Courier font. Why? Because the Nimbus font is
assigned to the name "Courier" in /usr/share/
and this directory occurs in the gs-esp search path after "." and
"$HOME/.fonts". Whatever assignments to Courier may come later in the
search path are irrelevant. The ways to get gs-esp to load an Adobe
font are (1) change $GS_LIB, (2) fiddle with $HOME/.
idea, since I think KDE expects to maintain it), (3) change
/usr/share/
overwritten). (OK, also other ways, too, like writing a wrapper for
gs.)
So there ought to be a bug submitted against gs-esp requesting the
file /usr/share/
/etc/gs-
gs-gpl.
I think a BETTER solution in general would be to set the first directory
in the macro GS_LIB_DEFAULT to /etc/gs-
The fact that various packages include various fonts that pass for
Courier -- even different revisions of the Adobe one -- is a general
problem of itself, as well. None of these problems would exist if
there were just one Courier afm and pfb file on a Debian system.
Note FYI that to get gs to show what font file it is actually going to
load when a font name is called for, do the following (from the gs
documentation, example is for gs-afpl). I wish I knew how to get more
detailed debugging from gs, such as the values of GS_FONTPATH and a
summary of each iteration in the font-search process.
% gs-afpl
AFPL Ghostscript 8.14 (2004-02-20)
Copyright (C) 2004 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>
Loading NimbusRomNo9L-Regu font from /var/lib/
Using NimbusRomanNo9L
GS>/Courier DoFont
Loading NimbusMonL-Regu font from /var/lib/
>>showpage, press <return> to continue<<
This technique lets you test behavior with different envariables and
modifications to /etc/gs-