Re: A Rendering Idea

[Pedro Ferreira <pedro_nf@xxxxxxxxx>]

It looks like a good idea...
I've some time available for now (the company I was
working for just went bankrupt and closed...).
I'm participating in a project for language
processing, currently working with chinese, we know
the problem of character rendering...
My main skills are OO programming in C++, also some
Java. I have some experience in unix/linux programming
gcc, gnu autotools...
If there are more people interested on this, please
step forward...!

--- Gaspar Sinai <gsinai@xxxxxxxxx> wrote:
> 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/
> 


=====
Pedro Ferreira
Grenoble - France

"Everything should be made as simple as possible, but not simpler." - Einstein

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/