[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 8r encoding + xdvi :-(
- To: "K. Berry" <kb@cs.umb.edu>
- Subject: Re: 8r encoding + xdvi :-(
- From: Thomas Esser <te@informatik.uni-hannover.de>
- Date: Mon, 29 May 1995 17:55:30 -0400 (EDT)
- Cc: da@dcs.ed.ac.uk, joachim.schnitter@sap-ag.de, tex-fonts@math.utah.edu, vojta@math.berkeley.edu, s.rahtz@elsevier.co.uk
- In-Reply-To: <199505291404.AA07713@terminus.cs.umb.edu>
On Mon, 29 May 1995, K. Berry wrote:
> gsftopk can do the reencoding, but
> only for "real" type1 fonts and not for the .gsf fonts from ghostscript.
>
> So, let's fix gsftopk.
Yes. The fix from Paul Vojta (TargetFont exch instead of TargetFont in file
render.ps line 193, version 1.9 of gsftopk) did not work for me, although
I thought it did for some time ...
With the fix, I get:
te.users(gauss)534: gsftopk ptmr8r 600
gsftopk version 1.9
[1gs: Error: /typecheck in --makefont--
gs: Operand stack:
gs: --dict:11/11-- --nostringval-- --nostringval--
gs: Execution stack:
gs: %interp_exit --nostringval-- --nostringval--
--nostringval-- false --nostringval-- --nostringval--
--nostringval--
gs: Dictionary stack:
gs: --dict:595/631-- --dict:0/20-- --dict:59/200--
gs: Current allocation mode is local
gs: Current file position is 4859
I am using gs3.33. Does the fix work for gs-3.12?
If I use an unpatched version of render.ps, the pk-file ptmr8r.600pk is
generated, but it is not reencoded.
> The .gsf files from GhostScript do not seem to work with ps2pk.
>
> So, let's fix ps2pk.
Well, ps2pk needs .afm files which do not come along with .gsf fonts.
But, I tried a .afm file I found on CTAN and got:
te.users(gauss)541: ps2pk -v -X600 -R600 -e 8r.enc ptmr.gsf ptmr8r.600pk
Loading CharMetrics from ptmr.afm and encoding vector from 8r.enc ...
FontName Times-Roman; Encoding TeXBase
Checking ptmr.gsf font ... done
Creating character glyphs for ptmr.gsf ...Floating point exception
If I use Times-Roman.pfa (available on our SUNs), ps2pk goes well.
> .gsf fonts *are* Type 1 fonts, according to the Adobe book. It's true
> that most software requires eexec encoding, but there's no reason to do
> this. It just slows things down. So, in this case I think it's better
> to fix the software than to change the fonts.
Thank you, Karl, for the info.
--
Thomas Esser te@informatik.uni-hannover.de
Univ. of Hanover, Germany
Institute for Informatics (Database and Information Systems Group)