Hi David,
Thank you very much for your excellent review of ithe STSF API and architecture. > > - it let applications use custom font files/streams > (see STTypeEnvCreateFont). Not implemented yet, but > I suppose that this will come.. In addition to that we were considering adding a rich security model with font certificates (public/private key pairs) and permissions, but decided to do it in the second version, as soon as we implement font sharing between ST Server running on different machines and make ST Font Server speak SLP. > > 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' I wrote sft.c for OpenOffice with ST in mind. We will be adding font conversion and subsetting (at least TT to T42) to ST and we will have to figure out the most elegant API for that... > > it's possible to output individual text to outlines, which > means converting text to graphical Postscript or PDF though.. Both hinted and unhinted, if the scalers support that. Haven't implemented it yet, but working on that. > > 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. Actually we know of this problem and we are going to be changing the API so that STLineMeasureTextImage() does not have an STGraphics attributes and works entirely in user space or adding a user-space version of this function to the existing one. We will be discussing this with the team this week, if you have any specific suggestions please let us know. > 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) Yes we understand that. We believe that it can be solved by having two functions that measure text in user space (abstract floating point coordinates) and in device space (pixel or perhaps fractional pixel coordinates.) We currently lack one of these functions in the API. > > 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: I can testify your explanations are absolutely precise! > 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.. It is a very valid concern. We will have to change the server-scaler API so that if the scaler crashes it does not crash the server. Also as soon as we implement ST Font Server as a standalone daemon process we will be including a watchdog process that restarts it when it dies. If we keep track of the font file it was processing before the crash we will be able to exclude it after the restart or do something about it. We are very concerned about stability of ST Font Server since we are plannig to use it in Solaris to drive SunRay servers eventually and it needs to be rock-solid. > > 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.. Yes, that will be very important... During my Java2D days I figured out that the market requires us to be bugs-compatible with MS font systems, i.e. if there are broken fonts supported by MS Windows we also needed to support them. That means that our font loading code could not be too discriminating. > > > 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.. Definitely. > > II. Regarding the X Server extension: > ------------------------------------- I believe somebody else from our team has already commented on XST. > > 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: My face is turning red. Of course I will have to fix it, thanks for pointing out. Before we integrate ST with the X Server we will have to get rid of all asserts and handle all run-time errors we can imagine. > There are even hybrid code like the following: Will be fixed very soon... > > 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.. It definitely will. > > Voila. It has been a long essay and I hope it will help the discussion a bit ;-) So do we :) > > Regards, > > - David Turner AG -- Alexander Gelfenbain, Sun Microsystems, Inc. +1 (408) 635-0612 _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
