Subject: rendering - how bad is AW font displaying desing?
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sun Jan 07 2001 - 12:53:29 CST
> Ouch, I didn't know the AW font displaying design was *that* bad. But I'd
> like some more confirmation before I myself make a judgement. If I were only
> to believe your points, our font rendering is relly broken and has to be
> fixed. Is it this broken?
Now, I am not trying to say that AW font handling is broken or
badly designed, and I would like to stress that I like AW, I really
do, and I am not trying to throw mud on anyone's work. So if it
came across like that, I appologize.
Unfortunately, rendering is not simply a question of font displaying.
Rendering has to do with the fact that in certain languages a single
character has got multiple glyphs depending on the character's
context. For instance in scripts, such as Arabic or Assyrian, a
character can have a different form when it stands alone, when it is
in the middle of a word, when it is at the end of a word, or even
when it is at the start of a word (rendring is not though limited to
scripts). The notion behind rendering is that only a single code is
used to represent/store/input the character, but the rendering
engine takes care of displaying the correct glyph based on the
immediate context.
Rendering itself is not as simple as it sounds at first; I have worked
on rendering stuff before and have seen situations when the choice
of a glyph is dictated by a character that is three or four places
remote, or a combination of characters not in the immediate
vicinity. In order to determine the shape of the glyph you have to
scan all the surrounding characters until you know you have
sufficient context; this *assumes* that you know which characters
in the particular case represent such a contex and which ones do
not. This is simple if you are expecting to render one specific
language and just hard-code it in, more complicated when you
want a mechanism that can deal with anything you may need to
through at it in the future.
Things get further complicated, if your rendering engine is stand-
alone; you may need two way traffic implemented between it and
your code. In AW the drawing is done by runs. When you need the
drawing to be rendered, the text of your run offten will not be
enough for the engine to work out how to draw it. In that case it will
have to ask for additional information and you will need to pass it
back to it. This is further complicated by the fact that a run may
not contain more than a single character; you may need an
arbitrary number of runs to be passed to the engine, in one way or
another, just to accomplish drawing of a single character. And
there are other issues involved under rendering, not just drawing
text on screen, such as line breaking.
The AW back end is not badly designed, only it was not designed
with the possibility of using a rendering engine in mind (IMHO). So
you do not need to fix it, but may need to rework it if/when you
decide you want to use a rendering engine with it; I was hoping to
look into what exactly it would take once I am done with the BiDi
patch.
Maybe I am seeing things too black, but my current experience
with implementing the BiDi handling (which is much simpler,
because it only operates with whole runs) suggests to me that
plugging a rendering engine into AW, irrespective of how brilliant
the engine, is going to be much more than an afternoon work; if I
am wrong about this, all the better, I would love to see fulblown
rendering capabilities in AW, and I am prepared to work toward this.
Tomas Frydrych
This archive was generated by hypermail 2b25 : Sun Jan 07 2001 - 12:58:27 CST