[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Groff] Re: unicode support, part 14: unicode fonts
From: |
Bruno Haible |
Subject: |
[Groff] Re: unicode support, part 14: unicode fonts |
Date: |
Mon, 27 Feb 2006 14:18:16 +0100 |
User-agent: |
KMail/1.5 |
Werner,
> I've applied your changes
Thanks, that was the biggest so far.
> but I'm stumbling across the following problems.
>
> . 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]".
I think this is acceptable because
- \[char172] denotes character 172 in the _input_ encoding (not
necessarily ISO-8859-1), and only preconv knows about this encoding,
- if such a character appears at font level, it most likely means that
preconv was not run,
- the error message tells the user about the problem (ok, maybe we
should extend the error message to talk about 'preconv'?)
> . 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?
I intend to work on this after the composed / combined characters stuff.
> > 2) A few "cannot adjust line" and "can't break line" warnings.
>
> Hmm. This happens with non-Japanese man pages also; similar to TeX
> I've added warnings some time ago to report such problems.
>
> Or do you mean that this is related to your Unicode patch?
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.
Bruno