[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pro/contra PS resource databses
Here is a summary to the questions regarding the use of the PS
resource database in ps2pk15:
> ptmr8r Times-Roman "TeXBase1Encoding ReEncodeFont" <8r.enc putr8r
> Utopia-Regular "TeXBase1Encoding ReEncodeFont" <8r.enc <putr8a.pfb
tir Times-Roman "TeXnANSIEncoding ReEncodeFont" <texnansi.enc <tir.pfb
uvc UniverseCondensed "TeXnANSIEncoding ReEncodeFont" <texnansi.enc <uvc.pfb
:=) Please make it flexibly enough to work *not* just for 8r...
No problem. Filenames are lookuped via their internal PostScript
name. In your case via TeXnANSIEncoding (instead of TeXBase1Encoding).
The PS resource database should contain the info to locate the files
To put it more generally, when you use PSRES for both xdvi and dvips,
is it possible to let xdvi (through mtpk) know about the pfa file but
still not force dvips to download it even when it is not needed?
The mechanism Adobe uses to find out if a PostScript font is resident
on a printer is not via the PS resource database but via the proper
PPD file. In case of our HP LaserJet 4Si we have
*Font AvantGarde-Book: Standard "(001.006)" Standard ROM
*Font AvantGarde-BookOblique: Standard "(001.006)" Standard ROM
*Font AvantGarde-Demi: Standard "(001.007)" Standard ROM
So if you have the ability to add fonts to a SCSI disk you should update
the PPD file to reflect this situation. Of course dvips needs to
read this PPD file to find out what font is resident instead of
of using its current `<filename' approach while xdvi (maybe using
mtpk and ps2pk) always needs to get that font resident or not.
in favour of:
ptmr8r Times-Roman "TeXBase1Encoding ReEncodeFont"
putr8r Utopia-Regular "TeXBase1Encoding ReEncodeFont"
Sorry, but it's not at all obvious to me that this is an improvement.
I know you have a different opinion, but ...
What *would* be cleaner, IMHO, is a syntax that specifies the files and
their purpose, for example:
putr8r Utopia-Regular (encoding "8r.enc") (type1 "putr8a.pfb")
The software would be perfectly capable of reading 8r.enc and deducing
The syntax of psfonts.map
"use of resource1" "use of resource2" <filename1 <filename2
"use of resource2" "use of resource1" <filename1 <filename2
is perfectly suited for dvips itself. But not for other applications
like mtpk for example. Your suggestion would be an improvement for the
last category. But given the fact that Adobe's PS resource databases
provides a standard documented and free available way to lookup the
filenames of resources why shouldn't we use them in dvips and other
The benefits are best understood if you imagine the work somebody has
to do in order to use his ATM fonts with dvips. Should he rename all
his fonts to the standard CTAN names? Or make a copy of his fonts
just for working with TeX? With PS resource database it would be
just a question of running mkpsres.
One thing that is not just syntactic sugar is some way to specify
do-not-partially-download-this-type1. I was going to invent something
like <<minion.pfa or <!minion.pfa or some such.
If there is a good reason to partially download one font but not
another one I would think of finding an extension to the PPD format
to cope with it. Then other applications could eventually use this