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