Re: some XFree86 5.0 questions... Xft2 and STSF

On Thu, 2003-03-20 at 18:57, Stuart Kreitman wrote:
> As a case example of how well the X community handles rapidly changing new
> technologies, this subject of typography deserves better than anecdotal coverage.
> 
> The compelling motivations to move up to STSF are:
> 
>         1. Universal API's in support of all independantly developed
> font scalers and layout engines.  This is a requirement for
> internationalized, bi-directional, lcd-optimized, and high-quality deployments.
> Pango/Xft2 are hardwired to specific engines which are insufficient for
> these requirements.  Perhaps it is the input of the engineers responsible
> for the I18N contributions to X.ORG and Xfree86 that makes these
> issues so visible to us.  The goal is proliferation of GNOME waay beyond  
> English-speaking peoples.

Pango, when used with Xft, currently covers, among "hard" scripts

 Arabic, Bengali, Devanagari, Gujarati, Gurmukhi, Hangul (combining
 jamos) Hebrew, Hindi,  Kannada, Malayalam, Oriya, Tamil, Telugu, Thai

Along with the "easy" stuff (Latin, Russian, Chinese, Japanese, etc,
etc.)

Most of the unhandled scripts (Lao, Khmer would be among the more
important missing ones) are just a matter of a bit of straightforward
coding to handle. I've a patch in my mail queue for Syriac. 

I think the current use of Xft in conjunction with Pango and other
layout engines to display such a range of languages speaks pretty
effectively to the question of whether Xft is suitable for i18n.


As to the question of other (that is, proprietary) font engines and
rasterizers:

 - It's not something the XFree86 project, or the open source community
   should be concerned with much.

 - FreeType actually doesn't appear significantly in the Xft
   and fontconfig APIs... I don't know if it is interesting
   to do so, but technically it would be easy to port them
   to some other font library.

 - FreeType is actually quite modular -- it would be straightforward
   to plug in properietary rasterizers.
 
 - The FreeType rasterizer is quite good already, and most
   of the needed improvements (better counter handling for CJK
   is at the top of the list) are nothing nearly has hard
   as creating an entire text layout system...

>         2. Server-side and Client-side-capable  render and layout processing,
> which allows hardware exploitation and performance/scalability gains on
> platforms other than single-user PC's, or does everyone expect that their
> laptop, desktop, and what-evertop will look the same in 2 years as it does
> today?

I don't think it's worth beating around the bush here; the 
particular architecture that Sun is interested in is
many frame buffer X servers running on a single central large
server and pushing the fbcontents as graphics to thin clients.

For this setup, the hope is to be able share as much font 
and rendered glyph data as possible between the different 
X servers and applications running on them.

This scheme isn't certainly representive of the vast majority
of current usage patterns, and personally I don't expect that
to change. But, is STSF is going to work better in this setup? This 
hope is based on 3 claims that are (to me at least) largely
unsubstantiated:

 - That the amount of font/glyph data that it is possible share
   is significant compared to the application size.

 - That it is possible to make STSF perform well in an architecture
   with extensive sharing. Last I knew the client-server parts 
   of STSF were still an untested design. (This may have changed)

 - That with with the small API-neutral modifications to the Xft
   architecture, it wouldn't possible be to get similar amounts
   of sharing.

>         3. Operating system-agnostic structure that is portable beyond
> Linux and Unix. It is portable to Windows too. The potential for one
> Typography API, everywhere.

Pango is already in fairly widespread use on Windows ...

> A fair evaluation would include knowledge of the STSF specification 
> http://stsf.sf.net and knowledge of its broader design goals.

I can't claim to have spent more than a couple of hours looking at the 
STSF details. To be honest, I can think of a lot more interesting
things to do for GTK+ 3 than replacing a working set of text APIs
and forcing application authors to rewrite everything once again.

Regards,
                                          Owen