Re: [Groff] unicode support - questions

[Bruno Haible]

Hello Werner,

Thanks for your answers. There are some answers that I will need time to
understand...

> until we have real 32bit input slots

I'm not sure what you expect here. The way it's currently done is that
characters with name "uNNNN" are used. What is the need to use a
32-bit 'int' value for this instead (except for optimization - and
optimizations come afterwards, after profiling)? And for glyphs, i.e.
for the elements of a font, I cannot use 32-bit values anyway because we
agreed that combined characters such as "x with diaeresis and comma below"
must be handled as a unit, i.e. as a single glyph.

> The old code in troff which allows
> something else is there just for backwards compatibility.

I don't intend to remove any functionality; I cannot decide which
backwards compatibility stuff can be removed and which cannot.

> >   3) My current patch creates two subclasses 'enumerated_font' and
> >      'unicode_font' of 'class font'.
> >
> >      An enumerated font has all its characters enumerated in the
> >      font file.  A unicode font covers all combined Unicode
> >      characters (consisting of a base character and zero or more
> >      combining characters).
>
> It's not clear to me what you want to do.  Please give an example and
> elaborate.

This first step is to make the treatment of the Unicode glyphs
algorithmic rather than table-based. _If_ tables are needed that the
user needs to customize - the Asian double-width property comes to mind:
it depends on the terminal emulator being used - it should IMO be done
through a specialized representation that is economic both in space in
the font file format and in memory, rather than a representation that
enumerates character after character. For the moment I'm ignoring the
Asian width issue, and all Unicode character properties are specified in
C code.

> The most important thing IMHO is to define glyph classes which share
> the same properties (metrics, linebreak data, etc).  We need this
> especially for Asian scripts.

Hmm. Should these glyph classes be useful outside the font:: API? Or
is their only purpose to provide the data for font::get_depth() etc.?

Also, do you think these glyph classes depend on the font, or only
on the device to which the font belongs?

> As a transitional step it would be
> good to add lots of typedefs to classify the input, output, and glyph
> data types.  Later on it should be straightforward to invent other
> data structures if necessary.

Thanks for your agreement. Then this will be the next step, after the
patches that I've already submitted. Because it's easier to understand
the code when the types are clear. Up to now I didn't even know that
these were three different data types; I was only looking at the font
class. I assume, an element of a font - often called "index" - is a glyph.
What is an "output character" then?

Bruno