🚀 go-pugleaf

From a recent posting by   --Henry Churchyard     churchh@emx.cc.utexas.edu

> Recently there has been some discussion in comp.fonts about the ANSI
> character encoding used by Windows.  I have obtained what I think is
> the Windows encoding, and I have several questions:

>   1) Is the list in the first column in fact the Windows character encoding?

Not quite, see list of differences at the end.

> 2) How did Microsoft decide what characters to assign in the range
> 0x80-0x9F?  They don't appear to be following any standard here.  

The encoding used in MS Windows is `Windows ANSI', not ISO Latin 1.
Why would you expect it to match?  The Macintosh `standard roman
encoding vector' doesn't match ISO Latin 1 either.  And why do you
single out ISO Latin 1 as a basis of comparison? 

> (And why the repeated definition of /ydieresis ...

There is no repetition (see table at end).

> ...and the non standard definitions of charcters 0x27 and 0x60?).

The encoding used in MS Windows is `Windows ANSI', not ISO Latin 1.
There are literally DOZENS of so-called `standard' encoding vectors.
There are in fact many problems with ISO Latin 1, one of which is
that there are repeat encodings for many accents, which is both
wasteful of character code space, and can't work with ATM for
Windows, which cannot handle repeat encodings. 

> 3) For the slots where a "/.notdef" appears in the first column (in
> the range 0x80-0x9F), is it utterly impossible under any circumstances
> whatsoerver to make Windows use characters with such codes?

You can make Windows applications use any character code you like.  
To specify it numerically, hold down the `Alt' key, type 0 followed by
the decimal number of the character code you want.  Of course, if
/.notdef appears in the encoding vector at that position,then nothing
will be drawn...

What you probably meant to ask instead is: `Can one access
characters other than those in the Windows ANSI encoding vector?'

The answer is `yes', in Windows (as on the Macintosh) fonts can be used
in one of two ways (and only one of these two ways): (i) reencoded to
the systems `standard' encoding vector (Windows ANSI for MS Windows),
or (ii) using the font's `native' or `raw' encoding.  The `native'
encoding for most Type 1 text fonts is Adobe StandardEncoding, but
one can change the encoding vector in a PFB file.

Using the `raw' encoding requires making up a PFM (Windows font metric) 
file with the appropriate bits set and the metric information generated 
according to the chosen encoding vector (similarly, one needs to make up 
a FOND resource on the Mac).  There is NO way to do this dynamically.
Neither Windows nor the Mac GUI provide for on-the-fly reencoding to
arbitrary vectors (Sigh).

And setting up a text font for something other than Windows ANSI 
requires special tools, such as AFMtoPFM, AFMtoSCR and so on.

As to your table:
=================

There is actually no repeat of `ydieresis' in Windows ANSI
(which is just as well, since ATM for Windows cannot handle repeat encodings).

Code position 157 is NOT `ydieresis', `ydieresis' is in code position 255. 

You are missing `Ydieresis', which is in code position 159.

Also, 160 is `nbspace' (no break space), not `space',
and 173 is `minus', not `hyphen', and 176 is `ring', not `degree'.

(Also, in ISO Latin 1, 45 is `hyphen', not `minus').

And you missed the differences between Windows ANSI as interpreted 
by the Windows PostScript driver and ATM:

PSCRIPT.DRV uses 0 - 13 for accents (because many PS interpreters 
cannot handle accented characters unless both base and accent are 
in the encoding vector):  grave, acute, circumflex, tilde, macron, breve,
dotaccent, dieresis, ring, cedilla, hungarumlaut, ogonek, caron, dotlessi

ATM instead uses 1 as a hard-wired position for `caron' and 2 as a
hard-wired position for `dotlessi' (and 0 is the reject basket for
all unencoded characters - you get whatever was the last unencoded
character in the Type 1 CharString program).

Also, ATM has all accent positions hard-wired, some in positions not
used by PSCRIPT.DRV, including: 136 for circumflex, 152 for tilde.

The encoding for PSCRIPT.DRV has changed from Windows 3.0 to 3.1.  
And the encoding for ATM has changed from ATM 1.15 to ATM 2.0
This was mostly because MS added characters, some of which were
placed (totally by chance no doubt (:-)) right on top of positions
that had been hard-wired into ATM for accents.

Some of your confusion may result from mixing up these four different
`Windows ANSI' encoding vectors.


Berthold K.P. Horn
Cambridge, Massachusetts, USA