mpost problems
Larry Smith
Dear Olaf,
Thank you for your answer. What you suggest as the problem cause is
reasonable, and I wanted to answer at least the part of your email
that I know the answers to straight off, before delving into the
details of creating a couple of examples, and trying a couple of hacks.
At the end of this file I have appended my original e-mail and your
answer so that we can compare notes in a sensible fashion.
(1) There is indeed NO pncr.vf on the dos box. The virtual font pncrrm.vf
maps to a font called pncr.tfm, and a couple of other things, all of which
are "raw" fonts declared in psfonts.map to map to the PostScript font
NewCentur.... etc.
(2) according to "locate" there IS a pncr.vf on the unix box. The
path to it is:
/usr/share/texmf/fonts/vf/adobe/ncntrsbk/pncr.vf
I certainly did not think of this myself, I do not use the raw
rp**** fonts that are part of the dvips package at all, so I had
completely forgotten that a default installation would have such things.
(3) I guess you are telling me I somehow have to prevent mpost from using
the pncr.vf file, and instead use one of my own creation? But how do I do
this without creating a "loop" in the dvips psfonts.map mapping? THINK! I
suppose. Does mpost "read" any configuration file to determine where to
look for .vf files? or does it simply use the path determinted by
TeXconfig for all of the TeX and its friends programs to find tese things?
If so, does this mean I have to "turn off" searching of the system wide
virtual font directory tree for .vf files? namely
/usr/share/texmf/fonts/vf
I think I can do this without driving dvips into a fit, because the only
PostScript fonts I am using are ones that I have declared in psfonts.map,
and are either builtin to the PostScript interperter, my own .ps source
files, or some fonts I purchased. I will have to find some time to try
this afternoon to see if what you suggest works. My only worry off the top
of my head is if some how I then screw up ghostview, but we will see. I
will let you know what happens.
Larry
On 11 Apr 2000, Olaf Weber wrote:
> Larry Smith writes:
>
> > The problem is the isnsitance of the sequence of program calls
> > mpto -tex junk > trash
> > mytex \&mymem trash
> > dvitompx trash.dvi junk.mpx
> > The result is that for the fonts declared in the .mp source
> > and the TeX format to be
> > pncr
> > become in the .mpx file
> > pncr8r
>
> Probably this happens because the pncr.vf virtual font is mapped into
> characters from pncr8r. In other words, a difference between the
> texmf trees. (If so, it should be simple to create a small example
> that doesn't depend on you own format.)
>
> Is there a pncr.vf on the dos box? It is likely that there is not,
> and that the use of pncr on the dos box translates directly into the
> use of rpncr (for "raw" pncr) on the unix machines.
>
> Unfortunately you do need to use substantially similar texmf trees if
> you want to exchange documents between TeX installations. Especially
> the handling of type1 fonts has varied in time, and between
> installations. The provenance of both the "new" and the "old" texmf
> trees matters here.
>
> --
> Olaf Weber
>
> Part of being competent is knowing that you might be wrong ... even if
> you were correct yesterday with the same answer. -- Barry Kearns
>
Larry Smith
Gee, thanks for the quick turnaround. I did not get to trying anything
useful yesterday at all, I am bogged down trying to prove a theorem, so I
still do not know if any of the things you have suggested will work. BUT
On 11 Apr 2000, Olaf Weber wrote:
> Larry Smith writes:
>
> > (1) There is indeed NO pncr.vf on the dos box. The virtual font
> > pncrrm.vf maps to a font called pncr.tfm, and a couple of other
> > things, all of which are "raw" fonts declared in psfonts.map to map
> > to the PostScript font NewCentur.... etc.
>
> Note that on the unix system, it is likely that there is no pncrrm
> font at all.
Actually there is: I built a texmf tree in my home directory, and
this version of Linux TeXconfig claimed that this tree would be
searched before the system tree, so I thought .... Na, ja, I
guess I hoped would be better.
> AFAIK mpost doesn't use vf files at all. It is dvitomp which resolves
> virtual fonts to actual ones. The paths used to find the vf files are
> described in texmf.cnf.
>
right on: but dvitomp or dvito is not listed, so I assume it is
the the following path that is relevent for dvitomp also
VFFONTS = .;$TEXMF/fonts/
if so then in theory I could change the environmemt variable
corresponding to this to point ONLY at my own texmf
tree virtual font directory? Probably this will cause problems with
ghostview, but that remains to be seen. If so I could always run ghostview
from a shell script that reset the environment variable. Maybe the better
option is to run dvito from a shell script that resets the environment
variable. I will have to try some variations here.
> Using the files from the dos box on the unix machine is one option.
This is what I am trying to do: all these files have been installed in
the texmf tree in my home directory, but it would seem that dvitomp is
looking somewheres in the system tree, where VFFONTS points is what I
guess, to resolve an issue that does not need resolving.
> To do this you have to ensure that pncr.vf cannot be found at all,
I do not have root priviliges on the unix box so I do not see how to do
this off hand, that is, unless changeing the environment variable will
work.
> that pncr.tfm matches the tfm found on the dos box, and you have to
> change the line for pncr in psfonts.map to match what's in the file on
> the dos box. Doing this for all fonts basically means replacing the
> vf and tfm files on the unix box with those from the dos box.
>
I have done this: but (see above) not having root privilidges, and more to
the point, not being the only user on the system, I cannot "replace"
I can only create my own texmf tree.
As for the rest of your message, all the relevent .tfm and .vf files are
installed in the texmf tree in my home directory. Using the system
defaults on the unix box is not an option for me, because I do not use any
of the standard format packages of fonts, and do NOT want to have to
maintain two sets of source code for my preprints and book manuscripts. I
guess I must do a bit of experimentation, but probably will not be able to
until the weekend. In any case I will let you know if anything works and
what it is, because there may be other users out there with similar
problems.
Thanks again,
Larry