24 Mar 2002 nicholasl   » (Journeyer)

Wow, I'd almost completely forgotten about this page; I found it when cleaning up my bookmarks list.

Berlin has progressed a lot since my last entry. But it's regressed rather badly too. The good news is the SDL+GL are in, thanks to the tremendous efforts of Tobias Hunger. I wrote up a new DrawingKit that renders to PostScript and got commit privileges to the tree. Ben Bucksch started up a new project called fresco-contrib and I've put a few clients in there including a client-side Graphic. At school, I've got a linux box with Berlin installed, but the 3d hardware requires XFree 4.2.0 and so I'll either have to wait for Brendan Robinson to package it, or install it myself. I plan to hold out for as long as I can.

The bad news is that some optimizations that got checked in early January have busted a lot. Bounding boxes are messed, clicked buttons fail to trigger, layout fails to bring sizes back down, and probably more. Things got very ugly, very quickly.

I've got a few things on my mind. One of them is the problem with positional event handling delivering coordinates in screen-pixels. Clearly this is useless to a widget, so we should deliver them in widget-space. Except that when we do so, things like dragging a scrollbar thumb will get confused because the widget receiving the coordinates is the thumb, not the scrollbar, so the coordinates never change as the thumb moves. D'oh. The solution is to make the scrollbar receive the event, not the thumb. But the only way for the scrollbar to check whether or not the thumb got hit is to use a Traversal—which would make the thumb receive the event. UNLESS, the scrollbar (dragpane) creates its own custom traversal class. Yuck!

Secondly, it occured to me when writing the client-side Graphic demo that the client is allowed to call any function on the DrawingKit. Now, things like draw_path and foreground I can understand, but things like transformation, clipping and save/restore? The server is supposed to be able to handle anything that a client might do. Well, a client that calls restore a few times might just crash the server. Similarly, being able to change the clipping and trafo to draw all over the screen might be a security problem too. At first I thought that maybe I could get away with giving the DrawTraversal access to the full DrawingKit and casting it into a reduced one before passing it off the the Graphic. Unfortunately, the Graphic could then narrow it to the larger interface and two, a client can implement its own Traversal anyhow. That's right a client can just ask for any DrawingKit at any time, out of the blue.

While I'm thinking about restructuring the interface between the Traversal and the DrawingKit, I'd like the DrawingKit to know more about what's going on in the Traversal. Currently, the DrawingKit can't create display lists because it gets created for one traversal and destroyed at the end. I'd like to have a PersistantDrawingKit class that sticks around and gets informed by the traversal before it goes to render each node of the scene graph. I haven't thought it all through yet either, but if the Traversal knows what's damaged and can ask the DrawingKit to do a fast-track rendering instead of traversing the nodes, we could avoid a lot of overhead, and most importantly network traffic.

Lastly, Berlin needs a TextKit. There's two parts to this issue: the TextKit and the DrawingKit. The TextKit needs to ask the DrawingKit for metrics on fonts that it is capable of drawing. This poses the WYSIWYG times multiple DKs problem. When you write something up in GL, then go to print it, the metrics on the font may change and so the line breaks may move and what you end up with won't be WYSIWYG at all. I want to impose one proviso: all DKs that report a font of the same name must have the same Metric. In other words, if there's a TTF file cmr.ttf, call it "Freetype AMS Computer Modern Roman" and the TeX metafont "Metafont AMS Computer Modern Roman." That should suffice, though in sufficiently bizarre environments it could still break. Mind you, when that happens I'd rather fix the underlying issue of conflicting fonts than change our architecture. The TextKit is responsible for performing the text layout. Given the font and a paragraph (string), it creates a graph where the glyphs (accented characters) and subgraphs are the verticies while the edges contain kerning/advance and soft-hypenation data. Ligatures and bidi are handled as separate graphs, where the entire subgraph can be treated as a glyph in the master graph.

    Notes on ligature processing: ligatures must be able to separate between the characters for the purpose of picking one character and not the other. Further, it should be capable of handling words like "shelfful" correctly, that is, without producing any ligatures.

    Notes on kerning: beware the sliding dot problem. In a string such as "T.W.Lewis," the dots should slide directly next to the characters. The mistake is in forgetting to keep the space after the dot and before the next letter. Similarly, don't slide the dot at the end of a sentence either. The graph should be exposed to a client that wants to provide professional editing capabilities.

(Given that a paragraph contains attributes such as alignment.) All the TextKit needs now, is the space into which it may perform its layout. This space is defined by having a baseline (or many baselines) that intersect two borders. Imagine a piece of three-hole, blue lined paper with a vertical pink line at the left margin and a yellow line along the right.

Oh no, I'm not thinking very well. I was going to talk about complex sheets of paper (multiple pink and yellow lines masking off where the next may and may not go) and then suggest that overflow be broken into pages. The plan was to make a simple multiline view be one baseline and allow the overflow to layout the remainder on similar pages then render each page stacked vertically. Unfortunately, I completely forgot about handling in-line graphics that are supposed to float around the text, such as an image that is associated with a word, but is to be right-aligned. And how should it be aligned, center of image to baseline of text? Or the bottom? (W3C's CSS suggests the bottom, come to think of it.) The other thing I want to address is fitting text along paths that aren't straight, like making a circle. Do you simply rotate the glyphs and place them in the right spot, or should the glyph itself be distorted entirely? I should ask a typographer.

More to come if I figure anything out, I suppose.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!