[Xprint] Re: [STSF-devel] My STSF wishlist, part 2...

Roland Mainz roland.mainz at informatik.med.uni-giessen.de
Wed Jan 7 05:35:04 EST 2004


Alexander Gelfenbain wrote:
> > Another bunch of ideas/wishlist items for STSF (I made that list long
> > ago, it even predates the first "My STSF wishlist" posting so don't be
> > confused... some of the items are already (partially)
> > resolved/implemented and/or had been discussed :):
> > * Query fonts via LDAP-like queries (the queries should allow extended
> > regular expressions and operators like '(', ')', 'NOT', 'AND', 'OR',
> > 'XOR', '==', '!=', 'substr', etc.) ...
> >     - ... by "name" (e.g. sort of "common name")
> >     - ... by "family"
> >     - ... by "foundry"
> >     - ... by "langgroup"
> >     - ... by "encoding name"
> >     - ... by "PostScript font name"
> >     - ... by "XLFD" (if the font is registered via XLFD, too)
> >     - ... by supported unicode page, range, glyph
> >     - ... by supported ENCODING page, range, glyph, column, row
> > (ENCODING is defined with the query)
> >     - ... by Cmap
> 
> We deliberately left it for the application and provided only a
> simple query API. If there is a real need, I don't think why it could not
> go into the next version of STSF later.

A more advanched query API like outlined above may have many
advantages... some examples:
- Using a string-based query API is more flexible - the functionality
can easily be extended via defining new query tags - the API and the
wire protocol can be left untouched (I am looking here at the future...
five... ten or more years when new font formats and or rendering/layout
techniques may be available... IMHO one of the BIGGEST mistakes in X11
was the very inflexible way how fonts are queried using XLFDs... there
are patterns to match font types but there was never a way to define a
different pattern format (actually I got that idea from the Xprint
extension design... most of the stuff is simply implemented via editing
Xrm resource strings - adding/extending the API is very very easy: Just
add another resouce :) ... it may be a good idea to avoid a similar
mistake in STSF.)
- The way how Mozilla (or Qt) finds matching fonts (looking at the way
how the Windows/GDI font lookup and rendering code is implemented) could
be moved from the client (mozilla) to the Xserver

[snip]
> > * Implement STSF as part of OpenGL
> > * Implement STSF as part of Fresco/Berlin
> 
> I don't think integarting STSF with any of these imaging systems is difficult.
> Somebody just needs to write an implementation of the render callback...

At least the Fresco/Berlin people have (or had... see
http://lists.fresco.org/pipermail/fresco-devel/2002-August/018668.html)
interest in STSF... and I've seem HP folks using the Freetype2 library
to render text (which s*cks in many cases) where a OpenGL-based STSF
extension would make much more sense.

----

Bye,
Roland

-- 
  __ .  . __
 (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 mailing list