Re: 2-bytes character display ready ?

[Nicola Pero]

I've beend reading about postscript fonts yesterday night (coincidence).  
I was meaning to write to the mailing list about this, and saw that
richard is doing the same :-)

> OK.  Time for a some points on how postscript fonts work.  I got this
> from the 'PostScript reference manual'
> 
> First, simple fonts -
> 
> Each simple font has up to 256 glyphs in it.

No - a postscript font has an arbitrary number of glyphs in it.

 
> The system has a 256 byte encoding vector.

Each *font* has a 256 byte encoding vector, which can be easily changed on
the fly (technically you generate a new font which shares everything with
the previous one but has a different encoding vector, thus allowing you to
access a different 256 subset of all glyphs contained in the font).


> The data passed to the 'show' operator is treated as an array of one byte
> characters codes, each of which is converted to a glyph in the
> font by reference to the encoding vector.

Yes - and by switching from one encoding to the other one, you can access
all the glyphs in the font.

 
> So the default ISOLatin1 encoding vector maps the character codes
> from 0 to 255 onto the appropriate ISOLatin1 glyphs.
> 
> If you need to display characters where the glyph is not present
> in the font you are using, you change the font and the encoding
> vector you are using, in order to display the unusual character.

It's not that the glyph is not in the font, is just that the encoding
vector you are using doesn't contain any mapping to that glyph.  If you
change the encoding vector, you can access those glyphs.

 
> So far, so good.  Obviously, there is absolutely no point passing
> characters in 16-bit encodings across this interface, since there
> are only 256 glyphs in the font anyway!

No - the font contains more glyphs.  For example, to display the 'fi'
ligature, which is available in the base postscript fonts, but not through
the default or isolatin1 encodings, you need to switch to a different
encoding (I think the 'special' one - anyway it's in appendix E), then
pass to the show postscript operator the number corresponding to that
glyph in that encoding.  I always use this example of the 'fi' ligature
since it's an example in a language I know that really requires a
distinction between glyphs and characters.

I've also read all the details about all the other types of fonts, and I'm
quite sort of agreeing with richard etc that it's very complicated in
postscript.  What I particularly dislike is that you have a lot of
different types of fonts, and each type works in a different way.

In other words, the 'show' operator can access all the glyphs in fonts, it
can print any sort of human or non-human language (more human languages
than unicode supports), but the bytes which are passed to the show
operator are interpreted in completely different ways according to which
type of font it's in use.

to Fred - 'show' is *not* accepting ASCII characters.  'show' is accepting
an arbitrary stream of binary data, in the form of an array of 8-bit
bytes.  Depending on the font, this binary data is interpreted in a
different way.  In the base fonts, each 8-bit chunk is looked up in the
encoding vector, and mapped to a glyph.  In other types of fonts, more
than 8-bits are used at a time to determine the glyph; in some types of
fonts you can even change the way the font uses the binary data, and
choose at runtime which algorithm to use from a quite long list, for
example having shift bits sequences to shift between different encoding
vectors, or 8/8 or 7/9 or any sort of other strange algorithms for reading
the bytes.  You can have very complicated hierarchical structures with
lots of fonts in it, and have complex algorithms to extract the font and
glyph to use from the binary data passed to 'show'.

I was trying to figure out what the 'NSGlyph' type in the Apple system
would map to in this postscript world, because it's very confusing.

What does the glyph array in the layout manager is supposed to represent ?
binary data ready to be passed to the show operator ?  somewhat I have the
feeling that it's not like that.

I then read about X, and it was quite the opposite of postscript.  
Postscript has got too much power in it, X has got too less.  They have a
function to draw a string, and a function to draw a multi-byte string, and
then you can use those font sel stuff.  But ... how do you produce a 'fi'
ligature in X ?  Is that done automatically by X ?  If it's done
automatically by X, how do you produce 'f' and then 'i' as separate
characters ?  There didn't seem to be any way to control that.  I don't
think that I've ever seen a correct 'fi' ligature done by an X font.

I guess I need to read more to be able to give an answer.


> If a font is an X wide font, the backend XGFont class should tell us that
> the glyphs used are the same as the composed unicode characters, so that
> we just send the unicode data to the 'show' operator, and the X backend
> sorts it out.

The gui is supposed to be able to produce the 'fi' ligature, or the 'f'
and 'i' characters separated.  How would that work in your example ?  You
seem to be just plainly passing the unichar character array to X for
drawing.