Hello,
Joseph Koshy a �crit :
>
> This is something I've not understood very well, can the list please
> help?
>
> Font technologies like OpenType allow for the font renderer to do
> sophisticated transformations on the glyphs being rendered, including
> glyph substitution, glyph repositioning (e.g:- kerning) and the like.
>
> If this rendering were to be done by an X server, how would a client
> map a screen coordinate back to an underlying location in the text
> that it is handling?
>
There are several reasons why putting text layout within the X server
is a particularly bad idea, here are a few:
- complexity:
code for parsing OpenType Layout tables is really complex, and
it'd be stupid to say that the current engines we have to do so
are 100% correct (the spec is very complex, and there are very
few fonts to test for now, even if this is getting better..)
this means that, as new fonts reach the market, the OTL engine
will probably need to be updated on a regular basis to fix its
own bugs, or to support buggy fonts (and these are very common
unfortunately).
- device independence:
OT text layout is complex, and you need it to both properly
display and _print_ international text with it. Placing the
engine within the X server would mean that the printing
sub-system (provided by Gtk/Qt/etc..) will likely need to:
- access the X server to print data even if it isn't
displayed (sounds like bad design)
- provide its own copy of the engine (which could not
match the version within the server, creating some
important WYSIWIG problems..)
> The straightforward algorithm used by the typical client, of using a
> font's glyph metrics to translate a screen coordinate back to a
> location inside the rendered text string will not work if the X server
> is doing any repositioning/glyph substitution "behind the scenes".
>
You're right, the straightforward algorithm is useless for any non-trivial
international text. A different approach is needed, and it looks like what
Java2D already does:
- take on input:
* a list of 32-bit Unicode character codes
* some formatting/styling information applied to ranges
of the above character array
- perform text layout (OpenType, wathever, ...)
- in order to create an abstract "glyph array" whose role is to:
* provide an array of font/glyph indices
* provide for each glyph its position in _device-independent_
coordinates
* provide a way to map glyph <->characters with the "glyph array"
- process the "glyph array" to generate a "display glyph list" for
a specific display size (i.e. performing glyph scaling/hinting,
anti-aliasing if needed, LCD filtering, adjusting layout to the
pixel grid, etc..)
the module in charge of this would also be able to translate pixel
positions into device independent positions within the abstract
"glyph array"
- or process the "glyph array" to generate a "printing glyph list"
for printing (i.e. conversion of glyphs to Postscript outlines,
embedding/conversion of the font, etc..)
this module shouldn't need to provide a pixel<->device space
conversion
As you see, this is complex (even though that isn't related strictly
to OpenType), and you don't want this kind of code within the X server
itself..
> It seems to me that, by the current definition of the X protocol, the
> client has to do complex text rendering, meaning that full support for
> OpenType HAS to reside on the client side, and not on the server side.
>
The standard X11 font and rendering models are severely _broken_ in many,
many, aspects and I'm not going to discuss this here..
The "Render" extension and its associates libraries is simply a way to
completely get rid of these (to replace them with much simpler and powerful
alternatives) while preserving backwards compatibility whenever possible..
As an example, the latest version of "libXft" does work with any X server,
but only provides anti-aliased text if the "Render" extension is provided.
This should help migrate legacy applications to the new model rather
easily (and transparently to users..)
Hope this helps,
- David Turner
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
