Subject: Re: rendering - how bad is AW font displaying desing?
From: Leonard Rosenthol (leonardr@lazerware.com)
Date: Sun Jan 07 2001 - 19:21:22 CST
At 6:53 PM +0000 1/7/01, Tomas Frydrych wrote:
>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.
True. And there is also the case where a single character
(code point) actually renders multiple glyphs (composites or
alternates).
>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.
OK, I'll buy that. (also taking into account not just
context, but also font & style choices, line direction, etc.)
>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;
True, but in no language that I am familiar with does the
context extend beyond a single "word" or line position (eg. glyphs
that are extended when at the end of a line in full justification
mode).
>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.
Actually, if everything is Unicode-based, then you can pretty
much use the standard Unicode tables (see the Unicode "books") for
all this kind of information - which is what Pango does, as well as
having "language modules" for handling more complex "glyph shaping
needs".
>Things get further complicated, if your rendering engine is stand-
>alone; you may need two way traffic implemented between it and
>your code.
Depends...
>In AW the drawing is done by runs.
As it is in most/all styled text environments.
>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.
More likely you will simply supply all of the information up
front, as with Pango where also give it contextual and "run"
information. The only place that I've seen a need for callbacks
with Pango, for example, is if we use their higher level layout API's
(PangoLayout). Havoc informs me, and of course he is right, that if
we use the low level API's then many of my concerns go away! (of
course, it also means we have to do a bit more work ;).
>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.
You shouldn't, since the changing of a run in the middle of a
"word" is quite unusual and I think could well be taken as a mistake
in most cases. But yes, if you wanted to, you could take all the
runs on a "line" and pass them along. It's not a big deal.
>And
>there are other issues involved under rendering, not just drawing
>text on screen, such as line breaking.
Sure, though I would classify that as "text measurement" issues.
>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;
NO QUESTION about it!! It's definitely a long term project
and I don't believe anyone was suggesting otherwise.
Leonard
--
----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65
This archive was generated by hypermail 2b25 : Sun Jan 07 2001 - 19:23:27 CST