A Rendering Idea

[Gaspar Sinai <gsinai@xxxxxxxxx>]

Hi,
I have a new redering schema in mind, that I am going to
implement in a future version of Yudit.

Of course it would take less than the estimated 10 years
of development time if someone, or some group would be
excited about it and implement it in a library. This is
the reason why I am writing down this here.

More and more people are using Open Type fonts to render
Unicode text, I use it myself. Still, I think that Open Type
is not the answer to complex Unicode rendering.

The major problems with it are:
① Very difficult to test the rendering software. Features,
  need to be applied in a certain order. Even one mix-up will
  result in bad rendering, and a very complex test should be
  manually performed to catch the bug.
② OpenType tables can not be shared between two fonts of the
  same time, although similar positioning/substituting  needs
  to be performed. This makes the font file unnecessarily big.
③ OpenType is not an Open Standard.
④ Rendering is a non-reversible process

The idea is:
Ⅰ. Assign codes and hot spots for all possible Glyph componenents,
  per script, per language system.
Ⅱ. Create a generic state machine thet can step through the input
  unicode characters, and spit out Glyph components and their relative
 hot spot positions.
Ⅲ. Create states and a dynamically loadable state table per script
 per language system.
Ⅳ. Create bitmap and vector fonts. The glyph codepoints are
 defined in (Ⅰ.) so this will be an easy process. Much easier
 than creating OpenType tables.
Ⅴ. Create a generic inverse state machine. The input is
 components and their relative hot spot positions and the
 output is unicode stream.
Ⅵ. Create dynamically loadable inverse state tables per script
 per language system.
Ⅶ. Use (Ⅱ) and pass it to (Ⅴ) to see if we get back out stream.
 We can test the rendering engine on-the fly this way.
Ⅷ. Use (Ⅴ.) for OCR (character recognition) software to scan
  text images into Unicode stream.

This is all - I am running out of Roman numerals ☺

The merits of such a rendering/font schema would be:
- Fonts do not need to carry extra extra tables
- Rendering is linear and needs very littel processing power.
- It is testable
- It is bitmap-font-friendly
- Once the specs are done, font making is an easy process.

The drawback is:
- Need to fix the states for the script and laguage system.
  This needs to be done very carefully.

One thing is for sure: one man is not enough to implement all
this…

Unfortunaltely I do not really have much time to discuss all
these steps and reasons now, so forgive me if I am not replying
my mails.

G̳á̳s̳p̳á̳r̳

ガーシュパール・Гашпар・가스팔・Γασπαρ・גאשפאר
עברי 10-2*5


--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/