[Xprint] Re: [STSF-devel] My STSF wishlist...

Alexander Gelfenbain adg at sun.com
Fri Jan 9 19:38:56 EST 2004

On Wed, Jan 07, 2004 at 05:36:26AM +0100, Roland Mainz wrote:
> > 
> > STSF is designed to be able to parse (extract names and metric data)
> > and to load fonts in all known (to STSF developers) formats.
> Really all formats ? What about SVG fonts or PS Type 3 ? =:-)

Well, STSF does understand these two formats *now*, but what I was
saying is that when (and if) support for these two formats is added, it
will go into the core STSF code, in addition to some drop-in scaler
that will be rendering them.

> Is there no API to figure out which font formats are supported _before_
> uploading a font via |XSTTypeEnvCreateFonts()| ? Other (future) STSF
> implementations (for example: STSF implemented in XDarwin using the
> native MacOSX font shaping/rendering APIs) may be far more restrictive
> in the font formats supported via |XSTTypeEnvCreateFonts()|.

Well, there is no API, but sttypes.h defines ST_FT_ constants (ST_FT_TRUETYPE,
ST_FT_TTC, ST_FT_TYPE1, etc.) STFontType is defined to be "unsigned int" which
is 32 bits on most platforms, but we limited the number of different font 
formats to 24 and reserved remaining 8 for the internal use of ST Font Server.

I don't think that the number of different font formats is going to grow.
Everybody seems to be converging on OpenType as a "container" font format.

STSF is supposed to load any font that has an ST_FT_ constant defined for it.
There is no guarantee that such a font can be rendered on any particular
STSF installation.

> > STSF
> > does not, however, scale any of the fonts itself. There are loadable
> > font scalers to do the task. So you can pass any font file to
> > STTypeEnvCreateFonts() and if STSF knows anything about the font,
> > it will load it.
> > 
> > In order to figure out if the font is renderable, you need to enumerate
> > all scalers with STTTypeEnvFindAllScalers() (or find a specific scaler
> > with STTypeEnvFindScaler() ) and request its bitmask of supported
>                                                ^^^^^^^
> Uhm, is this really implemented as bitmask ? What if there are more than
> 32 (|unsigned long|) or 64 (|unsigned long long|) supported font format
> variants (without searching my memory deeply I get at least 18 different
> font format variants... and I guess in a few years there will be
> more...) ?

I don't think people are so enthusiastic about inventing new font formats

> > font formats with STScalerGetInfo()
> Does that mean the application has to upload the font first to figure
> out whether the font can be rendered ?

Not really. As I said before, an application is supposed to enumerate 
all scalers and query their supported fonts bitmask. If the font can
be rendered by a scaler, that scaler will have the appropriate bit
turned on in the bitmask.

That is not to say that we probably need to provide a helper library
function that examines a font and returnes its STSF font type
(ST_FT_* constant.) 


> > > BTW: It may be a good idea to disallow usage of
> > > |XSTTypeEnvCreateFonts()| via the SECURITY extension (via an updated
> > > "SecurityPolicy" file). I assume someone can upload TTF/OTF fonts via
> > > that API which then get processed by server-side code, opening a whole
> > > bunch of possible problems with buffer-overflows etc.
> > > "Untrusted clients" (e.g. "untrusted" from the SECURITY extension point
> > > of view) should not be allowed to upload fonts by default...
> > 
> > We need to think about it. I believe that doing stringent font validation
> > in STSF Font Server will suffice - font scalers such as FreeType or
> > commercial scalers are known to be quite well tested to reject broken
> > or malformed fonts.
> Personally I wouldn't rely on that... too much code where too much
> things may go wrong... =:-)
> Remember that some Linux distros run the Xserver as user "root"... it
> would be catastrophic if someone loggs into a cracked machine using ssh
> and the rootkit on that box uses X11 forwarding and the STSF extension
> to spread itself...

Even if the X server is run as "root" ST Font Server (stfontserverd) is
not supposed to be run as "root". On Solaris we are running it as "daemon".


> > Good suggestion and relatively easy to implement. On Solaris with use
> > doors (libdoor(3LIB)) IPC mechanism. On Linux we are currently
> > using TCP sockets that we will be converting to UNIX domain sockets.
> > Both mechanism provide adequate credentials verifications. Running multiple
> > font servers, however, will have performance implications, since they
> > will no longer have access to the common glyph cache.
> Still... having multiple stfontservers (per Xserver and per machine)
> should be an option - for example to have two (or more) sets of users
> with different profiles/requirements for font rendering etc. ... and one
> other important reason for seperation may be simply: Security.



> > Our original design concept is different. Instead of providing glyph
> > coverage maps, we synthesize virtual fonts on the fly with the font
> > fallbacks mechanism. STSF is supposed to do its best to fill in the missing
> > glyphs from stylistically similar fonts, so there should be no need
> > for an application to know if a font X contain a glyph Y. Alas this
> > is not currently implemented.
> Ouch. Ouch. Ouch.... ;-((
> That may be a HUGE problem for applications which depend on that feature
> (for example: Mozilla's current XLFD font rendering implementation) or
> explicitly want control it (one example would be a MathML viewer where
> glyph substitution from other fonts may result in unwanted results).

I dont' think that it is a problem. STSF allows an application to control
the fallback list for a font.

> BTW: Is it possible to explicitly define the font substitution (e.g. if
> font 'a' misses a glyph (for example: The "EURO" symbol) search fonts
> 'b', 'c', 'd' (in that order) and if none of these fonts have that glyph
> use the string 'EUR' instead) using the STSF API ?

It is possible to define a search order (as a list of fonts) for missing glyphs
in any specific fonts, however we don't allow to do it on a per-glyph basis.
I dont't have any objections to adding a more sophisticated API that
allows applications to define fallbacks based on a character value or range.

Your charcter substition idea is better implemented by supplying an OpenType
font with an appropriate glyph substitution table. There are "smart fonts"
for a reason :)
> What about the reverse way, e.g. asking Qt/Trolltech+OpenMotif people
> for comments/help ? :)

We certainly are going to do that.

> ----
> Bye,
> Roland



Alexander Gelfenbain, Sun Microsystems, Inc.
+1 (408) 635-0612 

More information about the Xprint mailing list