Re: [Groff] Problems with unwanted unicode.

[Werner LEMBERG]

> > I'm going to fix this for groff 2.0 by implementing Unicode,
> > separating input and output encoding, but it won't be a quick
> > development process...
> 
> Then, could you think about tentatively integrate Japanese patch
> into official version of Groff?

I would really like to avoid it.  Main reason is that the Japanese
patch basically bypasses the way how groff processes input.  It
doesn't extend the structures by making it 32bit-aware but adds new
variables instead.

Another problem is how to handle fonts in groff.  It seems that we
have to extend the current font file syntax to allow ... what exactly?
Please make suggestions.  Some ideas:

  . Glyph classes.  We'll need that for defining CJK metrics and kerns
    in a compact way.

  . Subfonts.  [I don't mean the splitting of a large font into
    entities with, say, 256 glyphs each.]  Using a single Unicode font
    is nonsense.  Instead, groff should provide a means to group fonts
    into Unicode blocks.  If a new font is registered, it sets some
    flags to indicate which block is covered.  A mechanism to provide
    a fallback font is neeed also.  It could also be used for the
    other way round:  Registering a huge font as many subfonts makes
    the loading much faster.

  . Interaction between fonts to implement effects like kinsoku shori
    (i.e., less space between a CJK and non-CJK character than between
    two non-CJK characters).  It's not completely clear to me how to
    achieve that in a simple way.

What else?


    Werner