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: Werner LEMBERG
Subject: [Groff] Re: unicode support, part 14: unicode fonts
Date: Sun, 26 Feb 2006 23:25:47 +0100 (CET)

> Here comes the patch that makes it possible to process manual pages
> with Unicode characters without declaring them first in advance.

Thanks a lot!  I've applied your changes, 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 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.

> With this patch, an average Japanese manual page can be processed,
> but shows the following problems:
>
>   1) Although the man page starts with
>
> '\" t -*- coding: utf-8 -*-
>
>      the groff driver is not intelligent enough to run preconv. I
>      have to activate the -k option explicitly.

This is a feature.  I think it is best to not change this -- at least
not now.

>   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?

>   3) The output lines on devutf8 device are still too long, because
>      groff doesn't know about the distinction between normal-width
>      and double-width characters.

This has to be handled with glyph classes (as discussed earlier).

>   4) When outputting to the devhtml device, some warnings appear:
>        warning: can't find special character `u6D41'
>      They appear to come from the first japanese character of each
>      consecutive run of consecutive characters. They are harmless;
>      the HTML output is fine.

This should be fixed.


    Werner




reply via email to

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