[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ps2pk vs. gsftopk
> A separate consideration. I have been out of the loop for a week or so,
> and don't know how the discussion of psfonts.map vs PSRESources is
> going. I have taken the opportunity to look through the Display
> Postscript book in the interim, and i don't see that PSRES is an
> adequate substitute for psfonts.map, which allows more than just fontname
> mapping and encoding. It also allows
> ".167 SlantFont"
> "1.2 ExtendFont"
> "/PaintType 2 store"
> and if these can be managed in PSRES, it is certainly not made clear how.,
> I haven't tried it, but it wouldn't surprise me if other simple def's
> could be stored too.
> I use all these features. Not all the time, but it is the special
> occasions that count.
The psres library provides a mechanism to lookup filenames (which are
system dependant) for PostScript resources which don't need to be
system dependant. For example Times-Roman will always be the name of
the font in PS although the external filename may be tr______.pfb on
one system and Times-Roman.pfa on another. The psfont.map provides a
method for dvips to map PostScript fonts to TeX fonts. Each line
references a number of PS resources. Consider the next example:
ptmr8r Times-Roman "TeXBase1Encoding ReEncodeFont" <8r.enc
putr8r Utopia-Regular "TeXBase1Encoding ReEncodeFont" <8r.enc <putr8a.pfb
Each line references the name of the PostScript font (Times-Roman,
Utopia-Regular) and the name of the encodingsvector (TeXBase1Encoding).
Instead of using the '<8r.enc' notation used by dvips to find the
filenames of the resources needed in order to use some resource ps2pk
uses the psres method. Suppose dvips, ps2pk and ghostscript (and all
other PS applications) use the psres method for looking up resources
then we have a lot of advantages:
1) PS resources fonts can be installed in one single place per system
2) There is no need to use MSDOS filenames like putr8a.pfb in
psfont.map on UNIX systems
3) maintenance of psfonts.map will become a lot easier (no references
to system dependant filenames).
For fonts the dvips notation `<putr8a.pfb' also means that it should be
downloaded. I think we need a more general approach in terms of
PostScript Printer Definition (PPD) files. The transcript 4.0 software
does contain a utility (psutil.c) for reading PPD files. It will not be
difficult to make a PD version for it.
To conlude: psfonts.map files will not be replaced but thanks to the
psres library we can make its contents more system independant. I
expect that implementing the psres library in dvips and reading PPD
files will not be difficult even under the constraint that compatibilty
with the past is required (< notation).
Hope this sounds like music for all all of you.