Tom
> -----Original Message-----
> From: Paul Rohr [mailto:paul@abisource.com]
> Sent: 13 November 1999 01:31
> To: abiword-dev@postman.sourcegear.com
> Subject: POW -- Tabs
>
>
> 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.)