bug in 8r.enc? (was Re: newbie question)

[Rebecca and Rowland]

>[ Rolf Marvin B|e Lindgren writes:
>
>| ptmr8r   Times-Roman       "TeXBase1Encoding ReEncodeFont"  <8r.enc
>|
>| to psfonts.map, inputting x gives z where cmr gives x.
>|
>| am I doing something wrong?
>
>[ Sebastian Rahtz
>
>| its hard to believe that such a coarse error in 8r.enc would have
>| survived so long. I'd review the other files
>
>it's not actually x that gives z, if that's what you've read.  it's
>oslash that gives uacute.  many of the other position > 127 glyphs are
>misplaced as well.  I _do_ believe such errors can survive long, it's
>happened before.

It sounds like you're using the wrong input encoding - which input encoding
are you using?

Rowland.







From olaf@infovore.xs4all.nl 13 Jan 1999 14:25:20 +0100
From: Olaf Weber <olaf@infovore.xs4all.nl>
Date: 13 Jan 1999 14:25:20 +0100
To: Vladimir Volovich <vvv@vvv.vsu.ru>
Cc: "Berthold K.P. Horn" <enge@nada.kth.se
Subject: Re: bug in ae virtual fonts, or in fontinst, or in   vptovf/vftovp?
Message-ID: <12351.918486269.13@NO-ID-FOUND.mhonarc.com>
MIME-Version: 1.0
Content-Type: text/plain


Vladimir Volovich writes:
> "BKPH" == Berthold K P Horn writes:
>>> % vftovp aer10.vf aer10.tfm aer10.vpl Bad VF file: Oversize
>>> dimension has been reset to zero.

>  BKPH> I don't know whether this is the same issue, but many VF files
>  BKPH> insert absurd rules with semi-infinite negative dimensions.  I
>  BKPH> reported on this before, wondering whether this was some
>  BKPH> special marker used for some obscure purpose.  Of course, it
>  BKPH> doesn't print because the dimension is negative, but what is it
>  BKPH> for, and where does it come from?

> Note, that the original VPL file contained a zero-width rule (i.e. not
> with "semi-infinite negative dimensions"):

> (CHARACTER D 23 (COMMENT compwordmark)
>    (CHARWD R 0.0)
>    (CHARHT R 4.29993)
>    (CHARDP R 0.0)
>    (MAP
>       (SETRULE R 4.29993 R 0.0)
>       )
>    )

> So perhaps this shows a bug in vptovf? Or is vftovp incorrectly
> "interpreting" a zero width? Anyway, it looks like a bug in
> vptovf/vftovp, and not a bug in fontinst/ae fonts.

It looks like this was due to a bug in vftovp that was corrected in
the August 1998 release of vptovf (version 1.5) which had been found
by Wayne Sullivan.  This bug resulted in the semi-infinite negative
dimensions seen by Berthold.

The bug should be fixed in recent teTeX-0.9 snapshots, and will be
fixed in the upcoming web2c 7.3.


The following change summarizes the fix:

@x [128] Correct a bug found by Wayne G. Sullivan
if x>0 then negative:=false
@y
if x>=0 then negative:=false
@z

-- 
Olaf Weber





From olaf@infovore.xs4all.nl 13 Jan 1999 14:28:10 +0100
From: Olaf Weber <olaf@infovore.xs4all.nl>
Date: 13 Jan 1999 14:28:10 +0100
To: Vladimir Volovich <vvv@vvv.vsu.ru>
Cc: enge@nada.kth.se
Subject: Re: bug in ae virtual fonts, or in fontinst, or in vptovf/vftovp?
Message-ID: <12351.918486269.14@NO-ID-FOUND.mhonarc.com>
MIME-Version: 1.0
Content-Type: text/plain


Vladimir Volovich writes:

> Hi,
> when i'm trying to produce vpl file for the ae fonts from vf and tfm
> files, i get a "bad vf file" error from vftovp, e.g.:

> % vftovp aer10.vf aer10.tfm aer10.vpl
> Bad VF file: Oversize dimension has been reset to zero.

See my other mail for this issue.  Bug in vptovf, fixed in web2c 7.3.

...

> and this is definitely a bug in vftovp, since error message goes to
> stdout instead of stderr; and the last line in vpl file

> (COMMENT THE TFM AND/OR VF FILE WAS BAD, SO THE DATA HAS BEEN CHANGED!)

> comes without a newline character, which is also a bug.

Fixes will be in web2c 7.3 as well.

-- 
Olaf Weber