I got new code from CVS and my xlib application no longer works, because XToolkit isn't a subclass of ClasspathToolkit (i.e. it doesn't implement the ClasspathFontPeer stuff).
ah. well.. I don't know particularly what to say. I'm guessing your discomfort is partly because the Font that you were relying on using was an old pre-1.4 "strings and simple logical fonts" model, and we've migrated Font to the new precision model with glyph vectors, glyph metrics, complex layout, etc.
there's not an awful lot we can do here; classpath can only have one java.awt.Font, and either it claims (in its API) to implement the 1.4-style or it doesn't. it's a requirement for modern javas, so I'm of the mind that it should be supported. the ClasspathFontPeer compromise was designed to let sascha's work on a pure-java version of it coexist with my native pango/cairo/freetype version. there wasn't much of a plan for a version which didn't support the new font model at all.
Do you suppose we should have a pure java subclass of ClasspathToolkit (from which to subclass XToolkit), or do I need to go ahead and get XToolkit to work as a subclass of ClasspathToolkit?
hmm. tricky. the obvious ways forward that I can see for you are:
- make a ClasspathFontPeer with a special subclass name, which your
toolkit generates and your Graphics object recognizes, which only
supports the pre-1.4 semantics (which is broadly compatible with
the view of fonts available to xlib), and explodes when the user
tries to call any fancy new stuff. this would mostly be an
API-mapping task, with a bunch of cases that map to "throw ...". - try to integrate sascha's pure-java font code into yours, eg. by
rendering into offscreen buffers and copying tiles into xlib. this
would require you to have, I think, a cubic bezier scanline
converter at minimum (which you'll need for your Graphics2D
anyways), but would also eventually require adding hinting
support. I don't know where sascha is at on this stuff. - if you're comfortable with xlib, maybe make a version which uses
xft+xlib, but not cairo/pango/freetype as my version did.Is this stuff fairly stable (i.e. if I get xlib working with today's code, is it likely to stay functional for a while)?
I have no intention to change ClasspathFontPeer / ClasspathToolkit any further than strictly necessary; this code was put in place to permit multiple toolkit authors to fumble along our own ways, trying different strategies for font<->graphics<->toolkit communication without stepping on each others' feet too much. if it's not right for you, feel free to suggest changes.
-graydon
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
