I'm going to forget about text handling entirely.
I've figured out what my problem with postscript output was. It seems that my bounding box was ranging from (0,0) to (+x,-y) which placed the image below the printed page. This is because Fresco places the origin in the top-left corner. A fix to the code is on-going.
But I won't be able to check it in until we have our CVS repository back. Stefan Seefeld, our fearless leader, is mangling the CVS tree as we migrate from one server to another, with a new build system and a new directory structure. Good luck, Stefan!
I'm hacking my local tree in preparation of my Grad Project presentation. The first two things I did were to remove the 33fps cap and force full redraws every frame. This actually ups the frame-rate for GL and lowers it for libArt, which is what I want. Of course, I'll have to produce a switch for it so that I can turn it off when I want to show the damage-cleaning system Berlin has.
Alpha-blended 3d objects are busted at the moment. If a cube is supposed to be rendered in alpha, we want to be able to see through the front and to the back. If we use either back-face culling or depth testing, we will lose parts of the cube that should've been visible. Hence, we must render back-to-front in this case, which means that I'm buzy writing a painter's algorithm sort. It's buggy and I don't know what's wrong.
GLX only allows one thread to hold the Context at a time. This is usually fine for any game because they aren't threaded, or if they are they do all their video operations from the same thread. Not so with Berlin. If we receive a request to the DrawingKit from across CORBA, the ORB will launch a new thread to deal with the request. Hence, the GLDrawingKit needs to have a worker-thread built in. This thread must be provided by the Console, since the Console will also want to make GL calls (to handle the mouse pointer, specifically).
Last rant, I talked a bit about how the full DrawingKit API is exposed to the client. I more recently noticed that there's a parallel problem with the Traversals. The server doesn't have a copy of the scene graph ever, instead it just holds a reference to the top level node and asks it for an iterator, then walks through all the children. Because a Graphic can be implemented by the client, so can an GraphicIterator and a malicious iterator can produce a cyclic scene graph, an infinite depth problem, an infinite breadth problem. There's a few more problems in the general case; a client can pass an exception over CORBA to the unsuspecting server thereby killing it. Or it can never return, knowing that the server is blocked waiting for a response. This is all very bad. I'd like to move the whole scene graph representation inside of the server so that it can enforce sanity within the scene graph. All children of a Graphic must be registered with the server, no more client-provided Iterators, thank you. This means, however, that if a client wants to traverse the scene graph, it must do so by asking the server for a reference to it, which probably isn't such a bad idea from a security perspective anyways.