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
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
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.