David, This is a very nice overview.
I've been to busy at the moment to take an indepth look at ST. I'd like to comment on several items but before I do I want to make sure I have all my facts in order. Do the ST folks want to make comments on this review? Before we begin drawing conclusing its always good to have agreement on the basic facts. :) David Turner wrote: > > 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 -- Brian Stell _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
