groff
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]