[Groff] Re: unicode support, part 14: unicode fonts

[Werner LEMBERG]

> > . What shall we do with `charXXX' glyph names, with 128 <= `XXX'
> >   <= 255, if we are in `unicode' mode?
>
> The intent is that they are handled like undefined \[foobar]
> characters, i.e. that font::contains() returns false for them, and
> consequently some upper layers in troff will give a warning
> "undefined glyph \[char172]".

OK.  It just has to be documented somewhere, together with the
`unicode' keyword.  I'll probably cook something up for the various
man files and groff.texinfo.

> >   . The function font::get_width (in font.cpp) returns `24' for
> >     `unicode' fonts.  This hard-coded value must not appear there.  It
> >     should be eventually moved back to the font description file as
> >     soon as we have glyph classes.
> >
> >     The same applies to the other dimension functions.
>

> We agree that get_width needs to be parametrized through a concise
> syntax in the fonts file or DESC file.  I'm not so sure about the
> others whose value has always been 0 so far (get_height, get_depth,
> get_italic_correction, get_left_italic_correction,
> get_subscript_correction, get_character_type).  Does they have much
> sense for the tty and html devices?

Well, I want a generic solution for all devices, and to support, say,
a Type 1 Japanese font, we need access to all this information.

> I intend to work on this after the composed / combined characters
> stuff.

Great!

> > >   2) A few "cannot adjust line" and "can't break line"  warnings.
>
> I think it is related to the fact that in Chinese and Japanese,
> there are often more than 30 consecutive characters without a space
> in between.

Ah, yes, of course.  Something which has to be handled with font
ranges also: The property after (and before) which characters a line
break is allowed or disallowed.


    Werner