Hi Sven, I have a question regarding the Headless Toolkit. Will it be possible to decide which one to use both at compile time and runtime? I mean, will it be possible to compile Classpath to only compile and use the Headless Toolkit, for environments where GTK is not supported well (e.g. OS X without X11)? Of corse, if more than one Toolkit is available, the normal java.awt.headless switch should be used to activate Headless mode. Another question: Will the GTK backend continue to depend on X11 as well? I tried to compile the current version of AWT with the OS X / Quartz implementations of GTK and Cairo, and realized there are quite a few dependencies on X11 stuff in the AWT sources. Some examples: In gnu_java_awt_peer_gtk_CairoSurface.c #include <cairo-xlib.h> #include <gdk/gdkx.h> I replaced these with #include <cairo-quartz.h> #include <gdk/gdk.h> and it compiled correctly. But then there was gnu_java_awt_peer_gtk_ComponentGraphics.c, in which the fix will not be that easy: #include <X11/extensions/Xrender.h> The code then has various dependencies on X11 that will not run in such a Quartz environment. I'm not into GTK on Windows, but I doubt it will work there either. I was wondering if these dependencies can be remove / replaced by code that's only depending on GTK. J?rg Am 01.07.2006 um 01:09 schrieb Sven de Marothy: > Hello all. > I thought I'd just post my laundry-list of TODOs here, in case someone > else wanted to jump in and help out. > > awt.font > * Arabic shaping. > Arabic text is currently written in correct order (right-to-left) but > the characters need joining. This job is to be done by > FreetypeGlyphvector. For details on the algorithm, see Chapter 8.2 of > the Unicode standard. > (http://www.unicode.org/versions/Unicode4.0.0/ch08.pdf) > This isn't that hard to do, but certain character pairs will end up > represented as one glyph. The glyphvector impl needs some small > modifications to handle this. (TextLayout *should* be able to handle > this already, however this is not well tested). > > * Devanagari & friends. > Similarily, the south-Asian scripts require some more work to be > done in > order to convert to glyphs. This is detailed in chapter 9 of the > standard. (http://www.unicode.org/versions/Unicode4.0.0/ch09.pdf) > It's a bit more work than the Arabic case, but mostly it'd be > helpful if > someone who knows the language did this. > > * Finish TextLayout - not too much work left here, but you can see the > methods in the JAPI scores. More testing and bug-hunting is of course > welcome too. > > awt.image > * Make CairoSurface extend Raster and implement some interface for > BufferedImage to get Cairo implementations of Raster. > > So that creating an ARGB BufferedImage will create a surface Cairo can > draw directly and also draw to. Other BufferedImage types can keep a > copy of themselves as this kind of raster and copy that data back > to the > original raster when the user does a BufferedImage.getData(). > BufferedImageGraphics can then be dropped. > > * The awt.image code needs to be checked and tested closely. There's a > lot of bugs in there and some stuff which is plain wrong. (E.g. > calls to > ColorSpace methods with bad parameters). > > ImageIO > * Still needs a lot of work. But getting awt.image working is > probably a > prerequisite for this. A GIF plugin is now available, and a PNG one > for > writing and reading is nearing completion. JPEG is still missing. > > We can never have enough plugins! If anyone wants there's all kinds of > obscure formats left to support. TIFF, PICT, Targa, ICO, CUR, > Sunraster, > XBM, XPM, PCX, Amiga IFF. Whatever you feel like (some of these are > really simple). > > If you're a newbie and can't be bothered to learn the whole IIO > framework just to contribute a simple plugin, if you want, you can > always just contribute something along the lines of: > static BufferedImage loadImage( InputStream in ) > and someone more experienced around here can wrap that with the > necessary plugin code. > > Headless > > We need a headless toolkit which getDefaultToolkit() can return. > (which can do the job of throwing the HeadlessExceptions, not as > now in > the AWT code). At least right now I've got plans for a Cairo > +Freetype-based one, which'll allow us to reuse existing code. > This will require: > > * The actual toolkit, which should be fairly simple to implement. > (Most peers throw HeadlessException, except "lightweight" peers like > Canvas and Panel which get dummy implementations. createImage() > returns > a BufferedImage or uses ImageIO, and so on. > > * A Freetype-based Font peer. (Not too much work) This can pretty much > be used as-is with the existing GlyphVector implementation and by > extension all text rendering. (This peer can then be reused by the GTK > peers for Font.createFont). > > * A few modifications to the build to accomodate all that. > > awt.print > > * Page margins are off. > > * Gradients are written as Level-3 PostScript, which isn't really > useful > for most people in the real-world who don't have level-3 printers. (I > was hoping CUPS RIP-filter would take care of it, but it doesn't > seem so > on my machine/printer at least) > > * Some stuff remains to be implemented, e.g. compositing (which is > indeed a long-standing problem with anyone trying to generate sane > PostScript) > > So, anyone want to help out, let us know! > > /Sven > >
