Jesper, Sorry, I did have one more thing, that I meant to bring up in a few other threads as well. I am looking forward to the day when AbiWord supports collapsible outlining. In fact, I seem to have volunteered to do it ;-), (but I forecast a five year schedule, which is beginning to seem realistic as I beat my head against C and C++). I think that collapsible outlining will require at least one more thing (attribute?) in the description of a paragraph style. (I think this would be something that specifies the outline level of the paragraph, perhaps any of Heading 1 through Heading 9, and "Body". (I have some thoughts of trying to support body levels 1 through 9 in addition to heading levels.)) My primary point is that, if someone is about to make a change to the ptbl or other data structures, I'd like to make sure that collapsible outlining is considered / included / supported in the same change. Thanks, Randy Kramer Randy Kramer wrote: > > Jesper, > > I have some comments below (in only one area). > > Thanks, > Randy Kramer > > Jesper Skov wrote: > > > > Hi there > > > > This mail is due to some concerns I've had for some time now over the > > internal representation of the formatter (Runs/Blocks). > > > > Caveats > > ~~~~~~~ > > o I don't know enough of how the fmt and ptbl stuff interacts. There > > may be bad assumptions of how things work/can be made to work. > > > > o I very much believe in argumenting by providing working patches, > > but I live a life restricted to a mere 24 hours a day, so I need to > > know there's at least a reasonable chance something will work (and > > be accepted) before I want to spend time on it. So this is "just" > > talk for now. RFC, more precisely. I'll appreciate constructive > > comments, but stuff that just shoots this down (with arguments) are > > _also_ useful :) > > > > Motivation/background > > ~~~~~~~~~~~~~~~~~~~~~ > > > > OK, first my motivation so y'all know what's driving this. Several > > issues which I believe are affected by this, which makes it more than > > a trivial hack (and quite possibly beyond me): > > > > o Code robustness - the work I did recently on the cursor location > > code convinced me that the current mix of Runs which can contain > > the point (cursor location) and Runs which cannot is a bad thing. > > My changes may have fixed some problems, but it was very hard to > > get the code to work as well as it does now (still not perfect, > > actually). This means the code is fragile, and is bound to break > > next time someone sneezes anywhere near it. > > > > o Paul Rohr brought up the remaining implementation details of an old > > POW, also pointing out some of the problems with zero-length Runs. > > http://www.abisource.com/mailinglists/abiword-dev/00/June/0130.html > > > > o Show Paragraphs (show codes?) [I'm not much of a WP user myself, so > > this observation may not be correct]: if I enable show codes I > > would expect to see a marker between Runs of different text > > styles. E.g., <bold> or <font 20>. Currently, this information > > lives in the Runs, not as explicit elements in a block, and thus > > cannot easily be displayed. I feel that may become a problem (or > > maybe I'm just a control freak, I don't know). > > > > This introduces two limitations (that I can think of): > > > > 1) When typing we always inherit the text style from the text to > > the left. So if entering text at the border between two styles, > > and you want the style to the right, you need to manually change > > it before you start to type. > > > > I would love to be able to enable show codes, move the cursor > > right over the formatting code(s) and start typing with the > > style at the right. [I believe this was possible in WordPerfect > > 5, which is the last time I used a WP ;] > > > > 2) There is no way to distinguish between style changes inserted > > automatically and those inserted explicitly by the user. The > > latter type is when the user changes font size, for > > example. The former could be when 'Insert Symbol' changes > > font. This can cause problems, as described in Bug 903 (see > > http://www.abisource.com/bugzilla/show_bug.cgi?id=903 ) > > > > If there were explicit formatting style codes in separate Runs > > in the internal representation, a flag could tell whether the > > cursor (and thus what's typed) should inherit the Run's style or > > go back to a previous Run for that information. > > > > OK, that was fairly structured, I hope. Still reading? Now I'm going > > to pour my brain out of one ear (the left): implementation thoughts, > > random comments and whatnot. The ride may get a bit rough... > > > > Random thought #1 > > ~~~~~~~~~~~~~~~~~ > > I'd like a preference to switch between showing codes as magic > > graphical characters which hardcore WP users may understand, and > > descriptive strings which the rest of the world understands > > (e.g. <newline>, <linebreak>, <EOD>, ...). > > > > Avoiding zero-length content Runs > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > <see http://www.abisource.com/mailinglists/abiword-dev/00/June/0198.html> > > > > All break Runs can contain point. Computed cursor position depends on > > IP offset and hide/show codes mode: > > > > hide codes: nothing to render, impossible to select, but still > > possible to place cursor just before the break (i.e., at > > the offset of the Run). > > show codes: renders whatever is configured for that break. Can be > > selected (and thus deleted). Cursor can move past > > rendered graphics/text. In other words, the break is > > editable like any other text (and the world is a better > > place for some of us :) > > I'm a Word user, and I am used to an approach that is available in > Word. (I also use styles extensively.) Almost always while in Word, I > have the option Show All (nonprinting characters) checked, which > displays the backwards P for paragraph marks, an arrow for tabs, an > elevated dot for spaces, shows optional hyphens (supposedly -- I never > seem to notice those) and shows hidden text. (I haven't looked for > hidden text in AbiWord, but I am sure it is there. Hidden text allows > you to have annotations in a document that you or the recipient can not > normally see, but you can choose to see them if desired.) > > The usefulness (to me) of the Show All (nonprinting characters) is that > I really prefer that the primary styling of a paragraph (indent, hanging > first line, line spacing, etc.) be controlled by the applied style. > Then it is easy to change the paragraph format by applying a new style > (or an entire new template consisting of multiple (named) styles). If I > am editing someone else's document, the option to show hidden text lets > me see if they have "styled" the paragraph by using excessive tabs, > paragraphs, spaces or similar. (Which I sometimes then edit out.) When > working in this mode, I don't need to see beginning an end markers for > "character styles" applied within the paragraph (things like bold or > underline for a word or phrase). > > I hope that AbiWord will support a show nonprinting characters option > (like word) which does not show the styles for runs within a paragraph. > > Aside: While operating as described, I can view the style for each > paragraph in any of several ways, including a drop box on one of the > toolbars which displays the style for the current paragraph or by > turning on an option which displays the style for each paragraph in the > left margin. > > > > > Avoiding zero-length formatting Runs > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > <only me to blame for this one> > > > > Currently FMT Runs have a zero length. Changing this will: > > > > o Allow display (and editing) of FMT codes [same hide/show codes > > behavior as above] > > > > o Avoids multiple Runs in a block having the same offset. It bothers > > me, even though it may be benign. > > > > o Removes the need for fancy cursor location search algorithm (all > > Runs can contain point, so things get _much_ simpler). > > > > Issues: > > > > o How does/should this interact with the ptbl hierarchy? Is it > > possible to keep this just in the fmt hierarchy? This is my > > understanding (at what is the weakest link in my argumentation). > > > > The FMT Runs need to be inserted at the proper places. This can be > > handled by the block insert functions, if the info only lives in fmt > > for the sake of (optional) displaying. > > > > o As I sketch things, "<bold><font40>" will be atomic. The user will > > not be able to delete "<bold>". Instead, the cursor should be > > placed after the code (or the code should be selected) and the > > appropriate (GUI) controls should be adjusted. Would that be > > frustrating, I wonder? > > > > Making it non-atomic, you have to handle insertion of text between > > the formatting elements (i.e., create a new FMT, so you get > > "<bold>hello world<font 40>"). Power users would probably expect > > this behavior, but I don't think making the FMT atomic is > > unreasonable. > > > > o If non-atomic: Should stray FMT codes be left alone? Or always > > cleaned up? I believe the latter is the right approach, since > > they'll die when saving the document anyway. > > > > [by this, I mean something like this: <bold><bold><font20><font40>X > > which results in <bold><font40>X] > > > > Added Bonus! (I think :) > > ~~~~~~~~~~~~ > > Instead of content Runs containing formatting information, they refer > > to the relevant FMT Run. > > > > Internal representation becomes a little leaner (from a quick naive > > look, I think these get replaced with a single pointer: m_fPosition, > > m_pFont, m_pFontLayout, m_iAscent, m_iDescent, m_iHeight, > > m_iAscentLayoutUnits, m_iDescentLayoutUnits, m_iHeightLayoutUnits) > > > > And juggling with the Runs becomes a bit cheaper CPU wise + > > lookupProperties only needs doing once for an "ideal" Run, regardless > > of whether it has been properly coalesced or not. > > > > Cons > > ~~~~ > > o I don't know if this holds water. I need people with a better > > understanding of abiword (and WP in general) to think it through. > > And other people shouldn't get their hopes up - I suspect this baby > > leaks water like waterfall. > > > > o It'll take time to implement. Possibly more than is available > > before 1.0. > > > > Pros > > ~~~~ > > o Show _codes_ would work. Not just show _paragraphs_. > > > > o There would be no magic zero-length-runs, nor any Runs which cannot > > contain the point. Thus the now fragile cursor position computation > > code would become simpler and more robust. > > > > o Show paragraphs POW would be completed. > > > > o Makes it possible to have an "atomic" combination of FMT and > > content Runs such as used by 'Insert Symbol' without messing up the > > text typed in by the user. > > > > Hope I got at least a few brain cells firing maniacally :) > > > > Cheers, > > Jesper
