Subject: zap zap (Rulers and Tabs)
From: Stephen Hack (email@example.com)
Date: Fri Dec 03 1999 - 01:25:01 CST
I got most of the tabs POW coded up, but it's not stable enough to check in.
I'll be out of town for a few days, so I don't want anybody claiming it :>
I might as well zap the hideable rulers while I'm at it (only for unix).
P.S., And keep those segfault reports coming in :<>
On Fri, Nov 12, 1999 at 05:30:39PM -0800, Paul Rohr wrote:
> 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
> The ruler work and file format work is already done to support all four
> kinds of explicit tabs:
> 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:
> If you find yourself adding new classes, then creating new files for them
> would also be entirely in order.
> 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.
> PS: For more background on the whole POW / ZAP / SHAZAM concept, see the
> following introduction:
> 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 2b25 : Fri Dec 03 1999 - 01:25:42 CST