Re: 2-bytes character display ready ?

[Richard Frith-Macdonald]

On Monday, February 18, 2002, at 11:15 PM, Yen-Ju Chen wrote:

>   I try some modification and start getting some good results. :)
>   This is what I did:
>
>   1. In NSStringDrawing, use encode_unitochar_strict instead
> encode_unitochar.

I don't understand why that should help ... using the strict encoding
should just mean that conversions would fail if you try to convert
from unicode to a character set which did not support all the
characters you used.  With the non-strict version the characters
which could not be converted would be changed to
asterisks.

>   2. Change char to unsigned char in DPSshow.

I think that DPSshow() is meant as a convenience function for sending
simple ascii data.
I now think that we need another such function for non-ascii data,
and it should therefrone not be necessary to change DPSshow()

>   3. In XGFont.m, use XFontSet to set the Font.
>
>   Then I can show 2-bytes character in NSTextField and NSButton !!
>   That is a ugly modification because I'm not familiar with Xlib and
> unicode.
>
>   Is the PostScript interface means char vs unsigned char ?

It means byte data - certainly for sending characters this is
all unsigned data.  The problem is that the DPSshow() function
is not designed to handle the full range of data that PostScript
handles.

>   I found DPSxxx() always accept const char.
>  Since ASCII character is a subset of 2bytes character,
>   I hope GNUstep can include the ability to handle 2bytes character.
>   I have no idea how hard it will be,
>   or how it will break the PostScript interface.
>   But here is my idea after my first successful try, which may totally
> wrong.
>   1. Add XFontSet into GSFontInfo interface.
>       XFontSet can handle the font for 2bytes character.

I'm not sure how this would be used, but I'm certain it shouldn't be in
GSFontInfo.  GSFontInfo is a front-end library class, and should 
therefore
not contain *any* X specific information.
X font information would only be used directly in the backend.

>   2. Initiate XFontSet as XFontStruct in XGFont.m.
>       That's the most difficult part for me.
>       Too many parameters.
>   3. If it won't break any interface,
>       use unsigned char instead char.

I think we need another convenience function for sending true postscript
strings to the backend.  The DPSshow() function is obviously intended
only for ascii data, so it shouldn't matter whether it's signed or not.
Sending 8-bit data using this api might not work with some dps systems.

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.

The system has a 256 byte encoding vector.

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.

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.

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!


Next, composite fonts -

If you are using a language with *lots* of common characters,
continually changing fonts and encoding vectors would be annoying.
So you use a composite font - which is really a hierarchical collection
of fonts along with encoding vectors and one of eight mapping types
(FMapType) which specify how the data sent to 'show' is to be used.

I can't list the details of all the mapping types here, but I think the
one that maps closely to X is -

8/8 mapping (FMapType=2) in which each character is passed
to the  'show' operator as two bytes - the first being an index number
for the required simple font within the composite font, and the second
being the character code within that simple font.


As I understand it, a wide character font in X has up to 256 rows of
256 characters - which is equivalent to a postscript composite font
consisting of 256 simple fonts.  However, I *think* that X expects
to get unicode characters rather than row/column indexes into this
table.


To use X wide fonts, we therefore have two options ...

1 (bad) treat the X font as an 8/8 postscript composite font and map
the unicode character to some font-index/char-encoding pair. Send this
data to the backend, and have the backend reconstruct the unicode
character.
2. (better) define a new FMapType for these fonts, and simply send the
unicode data ... which the X calls in the backend will map onto the
row/column positions for us.



Summary ...

I now agree with Fred that we need a new function to send binary data.

I think it should conform to the PostScript API ... it should send a byte
array to the 'show' operator, so it will work on true PostScript systems.

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.