Re: 2-bytes character display ready ?

[Richard Frith-Macdonald]

On Tuesday, February 19, 2002, at 11:15 AM, Nicola Pero wrote:

> > 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.

Thanks for the correction ... but the point was that there is a limit
of 256 glyphs available for any one font (excluding composite fonts)
and you need to change fonts to get at other glyphs.

Changing font can consist of either swapping to another base font
entirely, or can be making a copy of the original font, with a new
encoding vector.  As far as I know, you don't actually modify the
original font object.

With composite fonts, you can effectively switch on the fly, since
each character is defined by 16 bits rather than 8 bits.

The PostScript reference manual uses the term 'font' in two ways ...
to refer to the abstract concept, and also to refer to the actual
object in the postscript interpreter.  I think that in the first sense
a font can have more than 256 glyphs, but in the second it can't
(except for a composite font).

> 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.

Yes - the sort of messy thing I'd think that most users would appreciate
having hidden inside NSStringDrawing.

> 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.

Extremely.

> 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'm pretty sure it isn't ... because NSFont actually provides a method
-glyphPacking which seems to be telling you how to convert from glyphs
to the data to go to the display.

I think that the glyph is perhaps meant to be related to the index of 
the glyph
within the font.  Though a couple of special glyphs are defined - and 
one of
them (NSNullGlyph) is defined to be zero ... so it can't just be the 
glyph
index (might be glyph index plus one).
I'm not sure if the glyph numbers are unique across all fonts or just 
unique
within one font.

> 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.

I was assuming that we would send the unicode character for the fi 
ligature
to the show operator.  I believe that there are unicode characters for 
all
the ligatures (I could be wrong about that though).