[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: graydon hoare
Subject: Re: [PATCH] new font model for awt / java2d
Date: Fri, 09 Jan 2004 16:54:43 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]