A question about how dvipsk works
Tom Kacvinsky
it necessary to serach for them first before falling back to whatever.
And it really is the fontmap that determines whether the font will be
a PK file or not. If a Type 1 font is found in the current fontmap,
that is used instead of a PK file.
Better for you is to set up the ls-R database properly, so you don't
thrash over the NFS mount.
Tom
On Mon, 10 Apr 2000, Daniel Arden Ost wrote:
>
> Is there some way to make dvipsk look for pk fonts before
> it looks for vf fonts?
>
> The reason I'm asking is because we have no .vf fonts installed
> in our texmf tree and lots of .pk fonts. Since the texmf tree
> lives on a NFS mounted drive, dvipsk is taking a hideously
> long time searching through the entire texmf tree only to
> discover that no .vf files exist before it looks for the pk
> files (which it usually finds in about 5 tries according
> to truss).
>
> When dvips is run on the machine that hosts the texmf tree,
> behavior is better, but still painfully slow.
>
> What I'd like to do is reverse the search order so that
> dvipsk looks for pk files before looking for vf files, but
> after looking through the source, I've realized that it will
> be no trivial exercise to figure out what's happening well
> enough to be able to make the necessary changes.
>
> If you have a moment to spare on such a puzzle, could you
> please tell me where to start my search in the source to
> make the necessary changes?
>
> Thanks for your time.
>
> Dan Ost
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Do noT ADjuSt yoUr minD
> iT IS rEAliTy tHaT Is maLfUNctIoNIng
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> http://www.vuse.vanderbilt.edu/~ostda/homepage.htm
>
Robin Fairbairns
> On Mon, 10 Apr 2000, Daniel Arden Ost wrote:
>
> > Is there some way to make dvipsk look for pk fonts before
> > it looks for vf fonts?
> >
> > The reason I'm asking is because we have no .vf fonts installed
> > in our texmf tree and lots of .pk fonts. Since the texmf tree
> > lives on a NFS mounted drive, dvipsk is taking a hideously
> > long time searching through the entire texmf tree only to
> > discover that no .vf files exist before it looks for the pk
> > files (which it usually finds in about 5 tries according
> > to truss).
> >
> > When dvips is run on the machine that hosts the texmf tree,
> > behavior is better, but still painfully slow.
> >
> > What I'd like to do is reverse the search order so that
> > dvipsk looks for pk files before looking for vf files, but
> > after looking through the source, I've realized that it will
> > be no trivial exercise to figure out what's happening well
> > enough to be able to make the necessary changes.
>
> That would be a *bad* idea. The whole idea behind virtual fonts makes
> it necessary to serach for them first before falling back to whatever.
> And it really is the fontmap that determines whether the font will be
> a PK file or not. If a Type 1 font is found in the current fontmap,
> that is used instead of a PK file.
quite so. it's quite possible to have a setup where dvips doesn't
know which pk file(s) to use until it's looked at a vf.
> Better for you is to set up the ls-R database properly, so you don't
> thrash over the NFS mount.
weellll...
what's actually wanted is most of the texmf tree to be force-looked-up
by use of !! operators -- that is, bypass all those stat calls over
nfs in favour of (once) reading the ls-R databases.
iirc, we had an argument here a while back about the !! operator (some
people arguing that it imposed an awful rigidity in the system). for
my money, that rigidity is amply repaid by the performance improvement
if you're using nfs. particularly if your servers are less than
totally whizz-bang. nfs just doesn't cut it for the sort of
operations kpathsea does in the absence of the !! operator.
robin