This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] new font model for awt / java2d
- From: "Scott Gilbertson" <scottg at mantatest dot com>
- To: "graydon hoare" <graydon at redhat dot com>
- Cc: <java-patches at gcc dot gnu dot org>, <classpath at gnu dot org>
- Date: Fri, 9 Jan 2004 17:18:22 -0500
- Subject: Re: [PATCH] new font model for awt / java2d
- References: <8765irnxnu.fsf@dub.venge.net> <0e3301c3d6f0$d900cfb0$3c16a8c0@mantatest.com> <3FFF2323.4060105@redhat.com>
> Scott Gilbertson wrote:
> > 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?
to which Graydon Hoare replied:
> 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 ...".
>...
Thanks for the suggestions. I guess the one reproduced above is the
simplest way to go. I roughed something in today along those lines, but it
just crashes in a different place now (in the font metrics cache). I'll
have to revert to the previous gcj/libjava code for a while, until I can
schedule a day or so to make a working implementation (next week I hope).
In the meantime nobody's beating down my door for xlib peer updates, and my
embedded app was working fine on the older code.