groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Groff] Re: UTF-8/Unicode for groff


From: Bruno Haible
Subject: [Groff] Re: UTF-8/Unicode for groff
Date: Wed, 1 Mar 2000 20:13:47 +0100 (MET)

Eric Fischer writes:

>   (2) For Unicode characters that do not appear in the current font,
>       I have set it up to automatically substitute bitmap versions
>       of the characters.  These are created spontaneously from Roman
>       Czyborra's "unifont" font whenever troff finds it cannot
>       locate a U+xxxx character, and are accomplished through the
>       equivalent of .char with a series of \h, \v, and \D to draw
>       the bitmapped image.  I'm not terribly happy with this, but it
>       seems better than not being able to do anything at all with
>       the characters.

Bitmap as a fallback is a nice solution. But before going into details,
here are more ideas for work.

* Higher Unicode support

  Unicode plain text may have combining characters, right-to-left writing
  (hebrew, arabic), and text which needs special rendering rules: When
  rendering Arabic, one needs to classify the letters at medial/initial/final/
  isolated, and choose the appropriate shapes. When rendering some Indic
  scripts, one needs to rearrange the letters in the words (vowels come
  first, etc.).

  You can ignore these problems, or you can decide to deal with them in
  libgroff.

* Unicode support in devps

  Why would you use Roman Czyborra's low-resolution font, when there are
  a lot of high-quality high-resolution TeX fonts available (some on dante.de,
  some elsewhere)? Render these fonts at 600 dpi, and include them into the
  .ps output. This is also what dvips does.

* Unicode support in devutf8

  Here you don't need any bitmap fonts, because the UTF-8 output device is
  supposed to have them. Currently the treatment of combining characters is
  not correct: instead of "LETTER C then COMBINING HACEK" it outputs "LETTER C,
  backspace, HACEK".

* Breaking the limits

  Some pieces of libgroff assume that the fonts are small enough that its
  feasible to load all fonts into memory, and use one C object per character.
  When a font has 40000 characters, this just becomes too slow.

Don't count on me for doing that soon; I'm currently on other projects.

Bruno


reply via email to

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