Hello,
Alexander Gelfenbain a �crit :
>
> The Sun Microsystems ST team would like to invite open-source developers
> to participate in the public review of the STSF API. The API specification
> can be found on the project web page at http://stsf.sourceforge.net/
> Discussion and comments on the API should be sent to the
> [EMAIL PROTECTED] mailing list, which is open to the public
> and publically archived.
>
I've just spent a few hours reading the ST and XST APIs, as well as dug
within the source code that was made available a few days on SourceForge,
and I'd like to share my first impressions with you..
Those who know me a bit will understand that I've focused on the issues
of abstract-ness and reliability :-)
I. Regarding the API itself:
----------------------------
I like the API, there are several things that I consider good things:
- the API is simple
- the API doesn't explicits the font engine (called 'scaler'
in ST terminology) used, unlike libXft.. And I do think it's
a good thing.
- the API doesn't explicits the client/server model chosen by
the ST team, nor the way it manages/lists installed fonts.
This means that if the client/server model doesn't provide
reasonable benefits (or if it brings too many annoyances),
it's still possible to change the implementation to more
common things (like a user-side libraries).
That's of course very unlikely, but it's still nice to know
that the API doesn't limit your design/implementation too
much
- it uses style objects (like ATSUI), which should considerably
ease the development of programs that need to display or print
rich-text.
- it let applications use custom font files/streams
(see STTypeEnvCreateFont). Not implemented yet, but
I suppose that this will come..
Note that there is no provision in the API to perform
font sub-setting when it comes to generating embedded font
fragments for PDF or Postscript output. However, it seems
that some font conversion sources are included in the
source file 'opensource/STFontServer/sft.c'
it's possible to output individual text to outlines, which
means converting text to graphical Postscript or PDF though..
On the other hand, I don't see _any_ way to perform consistent
WYSIWYG text with this API, since its packs both glyph shaping
and (device-specific) text layout in a single pass.
I find this quite strange and I'd like to know if there's
something that I didn't understand in the API, or if this simply
is a "design feature" ?
I know that it's not important in 90% of cases, but I do care for
the subtle effects of hinting on line widths and justification :o)
II. Regarding the client/server design:
---------------------------------------
I don't think that many people on these lists understands how how
the ST framework is designed, so here are a few more explanations:
ST is designed around a client/server model that is, it's important,
completely independent of any X11 issues. A stand-alone Font Server
process runs and manages font listing/installation as well as
processes font files and perform text layout.
Another important point is that application are able to choose
the font engines (called Scalers in ST terminology) they want to
use, even if they'll never access them directly. Instead, this
is done in the font server exclusively..
Basically, when a simple application wants to render text with ST
on, say, a PNG pixmap, with the FreeType 1.x font engine,
the following will happen:
+-----------------------+ +---------------------------+
| +-------------------+ | | +-----------------------+ |
| | | | | | | |
| | ST Client | <---------> | ST Font Server | |
| | library | | | | code | |
| | | | | | | |
| +-------------------+ | | +-----------------------+ |
| | | +-----------------------+ |
| | | | | |
| | | | FreeType 1.x | |
| +-------------------+ | | | (dynamically loaded) | |
| | | | | | | |
| | Application | | | +-----------------------+ |
| | code | | +---------------------------+
| | | |
| +-------------------+ | Font Server process
+-----------------------+
Application process
The SF Font Server is in charge of the following different
features:
A - manage font installation/listing (i.e. scanning font
path directories, enumerating valid font files in them,
etc..)
B - load/unload font engines
C - process font files either through the engines (for
rendering) or directly (for glyph shaping/text layout
purposes)
While I agree that task A should be implemented in an
independent process, putting B and C within the FontServer
process suspectingly looks like an open invitation to
mediocre reliability.. (read crash, crash, crash !!)
From my experience dealing with hundreds if not thousands
of font files, I can tell you that writing a 100%
bullet-proof font engine is extremely difficult.
Many files available are simply broken, do not adhere to
their relative spec, and present incoherent data that is
often difficult to sort out.
You'd better be certain that the font engines loaded in
the ST FontServer process will never crash if they're
given invalid font files. Otherwise, trying to open
it will simply crash the font server, and halt all
clients connected to it..
(As a side note, I simply cannot guarantee that FT 1.x
and FT 2.x are bug-free. I'd be surprised if the other
scalers supported by ST could say otherwise too..)
You'd better be certain that your glyph shaping/text layout
code is bug-free and capable of handling fonts with invalid
OpenType Layout or TrueType GX tables, for example,
or you'll suffer the exact same problem..
You'd better be certain that you handle exceptional conditions
well too. Think about memory shortage, a font that becomes
un-readable because a drive has been unmounted, etc..
If you can meet all of these goals, you can put all of this
in the server. Otherwise, you'll need to provide frequent
patches/updates to your users each time a new problem is
detected..
That's, after all, workable.
II. Regarding the X Server extension:
-------------------------------------
XST is the name of the X Server extension designed by the ST
team. If an application uses it, the following will happen:
+-----------------------+ +---------------------------+
+-----------------------+
| +-------------------+ | | +-----------------------+ | |
|
| | | | | | | | |
|
| | XST Client | <------> | XST Extension | | |
|
| | library | | | | code | | |
|
| | | | | | ^ | | |
|
| +-------------------+ | | +----------|------------+ | |
|
| | | +----------|------------+ | |
|
| | | | v | | | ST Font
Server |
| | | | ST Client library | <-------->
|
| +-------------------+ | | | code | | |
|
| | | | | | | |
+-----------------------+
| | Application | | | +-----------------------+ |
| | code | | | +-----------------------+ | ST Font Server
process
| | | | | | | |
| +-------------------+ | | | X Server | |
+-----------------------+ | | code | |
| | | |
Application process | +-----------------------+ |
+---------------------------+
X Server process
Of course, I have not drawn the connection to the X Font Server process
when available :o)
The good thing in this setup is that the inherent complexity (i.e. the
biggest source for potential bugs) is not within the X Server itself.
However what would happen if the ST Font Server crashes for one reason
or another ?? Is there a way for the extension to re-connect to the
server and have its state restored in a coherent state ?
It wouldn't be a good thing if trying to load a broken font would
both crash the font server and halt the X server, wouldn't it ?
How is this exceptional condition handled in the current XST Extension
code ??
Another question frequently asked before is how often do we need to
update the X Server when bugs are fixed in ST ? Well it depends on
the way the extension itself is managed.
First of all, any fix that _only_ touches the font server (or even
the font engines themselves) doesn't concern the X Server directly.
However, a fix in XST of ST Client library will need an update of
the code providing the XST extension. Any API addition or protocol
change as well..
With XFree86, extensions are provided by dynamically-loaded modules
that can, theorically, be upgraded individually. In practice, users
seem to always prefer to get a new package from the XFree86 team.
I suspect that this will mean more updates to the X Server in the
end for practical reasons then.. but I may be wrong..
III. Regarding the implementation:
----------------------------------
I shouldn't be commenting the current implementation, because it is clear
that the code available from SourceForge today is far from completed and
that the API is sufficiently abstract to allow great internal re-factoring
without touching client applications..
However, being the pedantic coder that I am, I cannot fail to notice that
the code isn't especially robust when it comes to memory exhaustion
conditions.
Very strangely, many 'malloc' calls are simply not checked, like in
the following example:
static lnode *newNode(void *el)
{
lnode *ptr = malloc(sizeof(lnode));
assert(ptr != 0);
ptr->value = el;
return ptr;
}
More surprisingly, it is not rare to see that a function checks
malloc and returns a NULL pointer or -1 in case of failure.
Unfortunately, the result is sometimes never checked correctly
in the caller.
There are even hybrid code like the following:
static InstanceSlotRecordPtr InstanceSlotNew(OpaqueGlyphCache *p, uint32 instanceID)
{
InstanceSlotRecordPtr ptr = malloc(sizeof(InstanceSlotRecord));
if (ptr != 0) {
ptr->InstanceID = instanceID;
ptr->GlyphSlotCount = 0;
ptr->GlyphSlotMax = GLYPH_SLOTS_INIT;
ptr->GlyphSlotArray = calloc(ptr->GlyphSlotMax, sizeof(GlyphSlotRecordPtr));
}
return ptr;
}
Where the 'calloc' call is never checked, creating a potential dangling NULL pointer
in case of memory exhaustion (and the rest of the code never checks this)..
I know that you're going to find me picky :o) However, this kind of code is
present in both the client and server sources of ST, which means that:
- the FontServer is susceptible of simple crashes in the case of
memory exhaustion. Unlikely but still possible, and with dire
consequences..
- the Client library is also susceptible to such crashes. In the
event where you'd like to use it within an X Server extension, this
could mean that the X Server would crash under the same conditions
As far as my knowledge of the XFree86 sources go, I know that its developers
have a high standard regarding function return status checks. I hope that
this remark will help improve the reliability of the ST sources in order to
avoid making the X Server and client applications more fragile than they
need to..
Voila. It has been a long essay and I hope it will help the discussion a bit ;-)
Regards,
- David Turner
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
