Re: [PATCH] new font model for awt / java2d

[graydon hoare]

Scott Gilbertson wrote:
> 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