[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.
-graydon
- Re: [PATCH] new font model for awt / java2d,
graydon hoare <=