[Xprint] Re: [STSF-devel] My STSF wishlist...
roland.mainz at informatik.med.uni-giessen.de
Wed Jan 7 01:54:54 EST 2004
jay hobson wrote:
> > Here comes a small wishlist of items/ideas which may be usefull for the
> > STSF:
> > * Support for per-application fontservers, e.g. the STSF font server
> > should be a available as shared library interface which applications can
> > use on demand. The idea is that applications which have to deal fonts
> > provided by user data can "upload" the font information to the Xserver.
> Clients can upload fonts using the XSTTypeEnvCreateFonts call. These
> fonts are tied to the TypeEnv, and are only available to that client.
> This provides security necessary for the font, and allows the font
> to be "server" side for speed. Use XSTTypeEnvDestroyFont to remove it.
> Since the stfontserver is multi-threaded, and resident on the local
> machine, there is not much advantage of having an ST server per
> client. Actually, that defeats the advantage of a unified cache.
How do you handle the problem of various font types in
For example - how does an application know which font types are
supported by the STSF engine in the Xserver ? And how should
applications handle "unusual" font formats (like SVG fonts) - is it
required to convert those fonts to a "well-known-to-be-supported" format
(for example - would it be required to convert "SVG fonts" to TTF first
or is there a different solution planned ?) ?
I may be nice to have a more advanced API to create an "empty" font
(|XSTTypeEnvCreateEmptyFont()|) and then upload/download glyph outlines
metrics and context data (like shaping information) per glyph
to have dynamic control (e.g. set/get/edit) over each single glyph from
within the application on-the-fly. That way it would be possible for
applications like "pfaedit" to render fonts using STSF without uploading
the whole font each time (after edits).
If such a glyph manipulation API is to compliciated (for the STSF X11
extension) an other option would be to allow applications to create
their own STSF font server and let them handle the issues on the client
side (the idea behind that is the rant of some people who still think
that rendering glyphs via the RENDER extension is "better" since
applications have 100% control over glyph
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...
> > Some thoughts for a possible implementation:
> > - There should be a way to define one STSF font server only for a given
> > |Display *| connection to avoid that two instances of "xpdf" or
> > "Mozilla" interfer with each other
> Each application will ask for a TypeEnv object, so each one is unique
> as far as the stfontserver is concerned. Stfontserver also creates a
> unique thread for each client that connects to it. If running through
> the Xserver to connect to stfontserver, then only one connection
> exists for all applications using that method. (The Xserver only allows
> one application command to be running at any given instance, so this is
I guess this means the Xserver only has one connection to the
stfontserver, right ? Will the whole Xserver "block" while the
stfontserver is being accessed or only the requesting client ?
> > - There should be a way to define one STSF font server for a specific
> > "application group", for example that all instances of "xpdf" or "Adobe
> > Acrobat" can share one font server instance
> All applications on the local machine use the same stfontserver.
Do you mean the "current Xserver" with "local machine" ?
> > * STSF font servers should support "stacking", e.g. one STSF font server
> > should be able to use another STSF font server as source (for example .
> > one "internal" font server includes an external instance etc.)
> We are intending to allow font servers to communicate to one another
> in a future release. (This communication would be machine to machine
> since only one stfontserver is running on any particular machine).
I hope users/admins can run more than one stfontserver per machine (for
example - running under different UIDs etc.) ... :)
> > * There should be a way to filter/ban fonts/scalers/shapers from both
> > client and server side (via (extended) regex or something similar ;
> > quite usefull in the case that there are buggy fonts (at least in the
> > case of Mozilla the support for "font banning" was VERY usefull... ;-/))
> Good idea! We will look into adding this functionality to the API.
It may be a good idea to provide command line options for the Xserver
and env vars for the client side as well that it is possible to control
that behaviour from outside the application code if neccesary.
> > * There should be a STSF<-->XLFD "transition" API (as seperate shared
> > library) to allow an easy transition of applications which use the "old"
> > X font API (this may be usefull for toolkits such as Athena or Motif...
> > "native" STSF support for both toolkits may be better but also requires
> > much engineering time). The API should work in similar (but not the
> > exactly the same) ways as the old API; the major difference should be
> > that there is no more direct access to the glyph metrics via the glyph
> > index (e.g. to avoid that all metrics data of a 16bit font have to be
> > downloaded over the wire... an incremental, on-demand download would be
> > better :), instead a function should be called to obtain the metrics of
> > one glyph or a list of glyphs. Additionally there should be a function
> > to get the CMAP (=a map showing which positions of a font are populated
> > and which not) of a given font (or set of fonts) and functions to render
> > glyphs using 32bit positions (e.g. STTAXDrawText32(), STTAXTextItem32(),
> > etc.)
> Development for a bridge is underway. The goal is legacy support, so
> there would be no API changes to current X commands. Applications wanting
> to take full advantage of the power of STSF should use the STSF API.
> We do intend to allow access to CMAP and other tables.
With "cmap" I wasn't thinking about the TTF "cmap" table... I was more
thinking about an API to obtain the CMap (e.g. which glyph positions are
populated) for any font (I am thinking here about the problems with the
iso10646-1 font encoding used a lot by Xfree86 - some applications (like
Mozilla) have HUGE problems with this encoding (short: mozilla's
braindead implementation simply loads all iso10646-1 encoded fonts until
it finds the glyph it is looking for. In the worst cases a few thousand
fonts get "queried" using |XLoadQueryFont()| (!!!) until a match gets
found (due lack of a cmap there is no other way to find out which fonts
contain which glyphs))).
> > * Support for Athena toolkit (see comment above about the "transition
> > API", however "native" STSF support may be better)]
> Best plan would be to "use the bridge", or if we could get some help,
> transition the entire font handling over to STSF.
"Use the bridge" isn't a good idea since this wouldn't result in sample
applications which use the native STSF API. Did anyone from the Motif
folks at Sun and OpenMotif take a look at the issue yet ? And what about
the Qt/Trolltech people - did anyone ask them yet for feedback ?
> > * Support for Xprint (that's
> > http://xprint.mozdev.org/bugs/show_bug.cgi?id=3819 - "Add Standard Type
> > Services Framework (STSF) to Xprint"), which can be split into four
> > pieces (the Raster DDX is already covered by the normal STSF DDX support
> > for the "mfb" code):
> > - Support for the PostScript DDX
> > - Support for the PDF DDX
> > - Support for the PCL DDX
> > - Support for the Xprint-specific "internal printer fonts". These fonts
> > are only available after the printer has been selected by an application
> > (after |XpSetContext()| has been called, assuming that the Xprint
> > attribute "xp-listfonts-mode" contains the value
> > "xp-list-internal-printer-fonts"). The quiz is whether the current STSF
> > font API (and client implementation) is able to detect that the list of
> > fonts may change due calls to |XpSetAttributes()| (for example the
> > application may set "xp-listfonts-mode" to a value which should disable
> > printer-internal fonts via omitting "xp-list-internal-printer-fonts")
> > and |XpSetContext()| (the context may be unset). If the client side
> > caches the font lists or font queries all h*ll may break loose... ;-/
> We would like to put support for STSF in Xprint. Currently, we have not
> been looking at the particular problems (such as internal printer fonts)
> that Xprint brings to the table. We've been a bit busy on other areas.
Main support for the printer-internal fonts sits in the single Xprint
DDX implementations. The only problem which may affect the STSF client
side are font queries where the results may change after a print context
has been set via |XpSetContext()| ...
... the biggest problem I am currently worrying about is how I can
implement support for rendering fonts with an alpha channel in the
PostScript DDX... any ideas ?
__ . . __
(o.\ \/ /.o) Roland.Mainz at informatik.med.uni-giessen.de
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 2426 901568 FAX +49 2426 901569
(;O/ \/ \O;)
More information about the Xprint