Re: 2-bytes character display ready ?

[Nicola Pero]

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

Hmmm ... yes and no ... we are probably saying the same thing in different
words.

I agree with you that if you use show, you can access only a 256 subset of
glyphs from one postscript font with a single show call.  To change this
subset, you need to execute some postscript code before the show call.

With other fonts, you can access a wider subset of the glyphs in the font
in the same show call, without any need for special postscript code.

I agree on that.

<But if you get to the nicky picky discussion of internals, I probably
don't agree with what you say - but perhaps you didn't really mean to
enter those details - a postscript base font does contain more than 256
glyphs, and you can access/draw all the glyphs (for example with - I think
- BuildGlyph) - but not with show.  show accesses only the ones which are
mapped in the Encoding dictionary.  To change the glyphs you can access
with show, you change the Encoding dictionary (this operation doesn't add
or remove any glyph! it only touches the mappings from bytes to glyph
names) and to do that - technically - you build a derived font with a
different Encoding dictionary, even if it's not really a different font,
it even has the same unique font identifier in the postscript glyph cache.  
To say it again, the derived font object doesn't include any glyph less or
more than the original font, it actually shares all the glyphs with the
original font, it just accesses different glyphs in the font for the same
bytes in the show operation.  I don't expect any user-interface to display
the derived font as a different font ... it's just an internal postscript
technicality - you are using 'Helvetica 12 point', that contains glyphs to
draw both 'f' and 'i' and 'fi', and the fact that internally to draw 'fi'
you have to switch encoding back and forth (and the fact that because of
the grammar of the postscript language to do that efficiently you create a
new temporary font with a different encoding) should be completely hidden
to the user, who is just using 'Helvetica 12 point'.>


I clearly remember that the definition of a 'line fragment' in the apple
doc is 'a set of glyphs which can be displayed with a single show operator
call'.  For that to match my idea of a line fragment, they can't be using
the base fonts, they must be using fonts where they can access all the
glyphs in the font with a single show operation, without need to use
multiple show calls switching encoding between different show calls.


I think I need to get more informed - in particular about X - to go on
with the discussion.