POW -- Tabs

Paul Rohr (paul@abisource.com)
Fri, 12 Nov 1999 17:30:39 -0800


We try to mix up the POWs from week to week. Some weeks we pick a
non-coding task, other weeks it's a new dialog or a critical bug. Then
there are the weeks we offer up a chunk of raw meat to the truly rabid
coders among us. :-)

Well, since someone's finally logged a bug on the fact that we only support
left-aligned tabs, it's high time that someone went in and finished the
feature.

scope
-----
The ruler work and file format work is already done to support all four
kinds of explicit tabs:

left
center
right
decimal

plus default tabs (which are also left-aligned). Clicking on the tab
"button" in the upper-left corner of the top ruler changes the style of the
next tab to be added, and all the usual dragging semantics for adding,
adjusting, and removing tabs also work.

(For completeness' sake, we've also spec-ed BAR tabs but aren't seriously
expecting to implement them in the formatter anytime soon, which is why they
got left out of the click cycle in the AP_TopRuler::mousePress() logic.)

However, the formatter just treats them all like left-aligned tabs. Boo,
hiss. This will be especially obnoxious as soon as folks start playing
around more with headers and footers.

Since all that interactive UI work and parsing has been done already, for
this POW you can zero right in on the core formatter work of positioning
runs on lines. It's all XP work, so it doesn't matter what platform you're
on. You're likely to be focusing in on the following four files:

abi/src/text/fmt/xp/fb_Alignment.cpp
abi/src/text/fmt/xp/fb_LineBreaker.cpp
abi/src/text/fmt/xp/fl_BlockLayout.cpp
abi/src/text/fmt/xp/fp_Line.cpp

If you find yourself adding new classes, then creating new files for them
would also be entirely in order.

hints
-----
If you're looking for ideas on formatting algorithms for tabs, here are a
few hints and starting places:

1. Don't take the current algorithm for left-aligned tabs too seriously.
The default tabstops case is especially bad, because there's a cumulative
roundoff error that creeps in. (For one example of this, see bug 346.)

2. Take a look at what Bruce Pearson did for full justification. With tabs
you'll also be adjusting the white space between runs, but not evenly.

3. Don't forget that decimal alignment is a *lot* like center alignment.
You're just centering around a specific character, instead of the midpoint
of the span.

4. Play around with other word processors to understand how tabs and
alignment interact. Your design is only as good as the "screw cases" it
handles in a predictable fashion.

5. Maxwell is a fine GPLed word processor which already has a fairly
complete implementation of all the various kinds of tabs and leaders.
There's no sense reinventing the wheel from scratch when you can study and
crib from what they've done. That's what the GPL is *for*. :-)

extra credit
------------
This POW will be complete when enough formatter work has been done so that
all four of the tab types currently supported on the ruler Just Work. By
itself, that'll make a nice checkin and probably be worth including in the
next release.

However, if that's not enough of a challenge for you, the next two obvious
steps will be to:

1. Add a tabs dialog to allow finer control than the ruler provides.
2. Add tab leader support to the file format and drawing code.

As you're thinking through your design, spend a few cycles on how you'd like
to make #2 happen. It's not necessary right away (since the ruler doesn't
allow you to set leaders), but it's a natural as soon as we've got the
dialog in place.

Enjoy!

Paul

PS: For more background on the whole POW / ZAP / SHAZAM concept, see the
following introduction:

http://www.abisource.com/mailinglists/abiword-dev/99/September/0097.html

PPS: For the truly anal, no, we haven't spec-ed how to represent tab
leaders in the tabstops property so that they're unambiguous and easily
parsed. (That's why it's not coded already.)

My first guess would be that the leader character should either be a prefix
or explicitly delimited, but whoever actually writes the code gets the most
say on what the right balance of readability, compactness, and parseability
should be. (For example, you'd be surprised how long it took to decide the
syntax of "at least" semantics for paragraph line spacing. Tha answer seems
obvious now, but I threw out a lot of dumb ideas first.)



This archive was generated by hypermail 1.03b2.