> > . 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
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
