dag@per2.UUCP (Daniel A. Glasser) (06/13/89)
I recently started trying to use dvihp from the dvist 3.3 posting
to comp.binaries.atari.st, and have been having no end of trouble
with it. One of the problems I've encountered is that it seems
to lose track of what font it's supposed to be getting characters
out of. I tried running a font table (as produced by testfont.tex)
for cmr10 out to the laser printer with dvihp. It used the correct
font for some of the time, the wrong font elsewhere. Some characters
were lost completely.
I guessed that this might be caused by the fact that most of the
fonts I had in my \fonts directories were for use with dvist.ttp
and dvieps.ttp, so I used MetaFont to create a set of pk files in
another directory. I have 300pk and 201pk files for each of the
standard TeX fonts in that directory tree (on a different partition
from the dvieps.ttp set), and have set up my "dvist.rc" file to
contain the line
f:\fonts
yet when I run dvihp, I get the error message (from memory here)
cannot open |f:\fonts\cmr10\201pk'
I assume the vertical bar character is a typo in the error message
in the program, as nothing I do can get rid of it, but the file
f:\fonts\cmr10\201pk does exists.
Does anybody know if this is definitly a problem with dvihp? Has anyone
used it extensively on the ST? What is your directory configuration.
Also, what magnifications should I generate (ie, what ???pk files should
I have) for each font for use with dvihp.ttp?
Thanks in advance for any advice that I might receive.
Daniel A. Glasser
--
_____________________________________________________________________________
Daniel A. Glasser One of those things that goes
uwvax!per2!dag "BUMP!!!(ouch)" in the night.
---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------gjh@otter.hpl.hp.com (Graham Higgins) (06/14/89)
I have found that my version (3.3) of dvist tells pork pies (lies) when
reporting an unsuccessful font search - it reports "unable to open
cmbx10/96pk" when it *really* means that it can't find cmbx10/105pk
^^ ^^^
It seems to be 9 short each time (87 vs 96, 96 vs 105, 106 vs 115).
I sussed this when it complained about not being able to open cmbx10/87pk,
but *not* before it had me running around in circles trying to find *one*
version of cmbx10/96pk which it would swallow!!
Hope this helps.
Cheers,
Graham
======
------------------------------------------------------------------
Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060
Information Systems Centre | gray@hpl.hp.co.uk
Bristol | gray%hplb.uucp@ukc.ac.uk
U.K. | gray@hplb.hpl.hp.com
tyler@stpl.UUCP (Tyler IVANCO) (06/16/89)
In article <570016@otter.hpl.hp.com> gjh@otter.hpl.hp.com (Graham Higgins) writes: >I have found that my version (3.3) of dvist tells pork pies (lies) when >reporting an unsuccessful font search - it reports "unable to open >cmbx10/96pk" when it *really* means that it can't find cmbx10/105pk > ^^ ^^^ No, its not telling any lies, it really cannot find that file. The dvi font loader attempts to find a font +/- 9 from the calculated magnification to overcome missing fonts and more importantly round-off errors that we had encountered. > One of the problems I've encountered is that it seems > to lose track of what font it's supposed to be getting characters > out of. I tried running a font table (as produced by testfont.tex) > for cmr10 out to the laser printer with dvihp. It used the correct > font for some of the time, the wrong font elsewhere. Some characters > were lost completely. This is a new one that we will attempt to look into. Did the program work properly with the given dvi file. We have used this program extensively on UNIX, OS/9 and to a far more limited extent, TOS and haven't encounted this problem. We will try out dvihp with the testfont file in the near future. > cannot open |f:\fonts\cmr10\201pk' Don't worry about the vertical bar. Those who have programmed AES will understand it's purpose (i.e. generate a new line in an alert box) and this has infiltrated itself into all of our program as we use a common driver for all devices. In general, we use any 300dpi pk font for virtually any laser printer out there. However, the font quality varies for one engine to another. Some devices prefer darker fonts, others lighter ones to acheive the same density.
gjh@otter.hpl.hp.com (Graham Higgins) (06/20/89)
++ / otter:comp.sys.atari.st / tyler@stpl.UUCP (Tyler IVANCO) / 10:33 pm Jun 15, 1989 /
++ In article <570016@otter.hpl.hp.com> gjh@otter.hpl.hp.com (Graham Higgins) writes:
++ >I have found that my version (3.3) of dvist tells pork pies (lies) when
++ >reporting an unsuccessful font search - it reports "unable to open
++ >cmbx10/96pk" when it *really* means that it can't find cmbx10/105pk
++ > ^^ ^^^
++ No, its not telling any lies, it really cannot find that
++ file. The dvi font loader attempts to find a font +/- 9 from the
++ calculated magnification to overcome missing fonts and more importantly
++ round-off errors that we had encountered.
Sorry, I might have got it wrong. I *thought* that the message from dvist said
"unable to open cmbx10/96pk" when, in fact, cmbx10/96pk was actually *there*. I
understand that it might have ideally wanted cmbx10/105pk and looked for
cmbx10/96pk as a valid -9 mag font file substitute, but I have it in my mind
that it was reporting "unable to open <X>" errors for fonts which actually
existed as <X>. Still, memory can play tricks.
I regretfully report that dvist doesn't work under bigscrn (and I was probably
very naive to even try). It would have been *most* useful --- is there any
chance that it will, one day?
Apart from having that unjustified hope dashed, I am chuffed to death, I have
both LaTeX and the dvi previewer now working happily(ish) --- most impressed,
thanks for your efforts in providing the facility.
Cheers,
Graham
======
------------------------------------------------------------------
Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060
Information Systems Centre | gray@hpl.hp.co.uk
Bristol | gray%hplb.uucp@ukc.ac.uk
U.K. | gray@hplb.hpl.hp.com