Subject: Re: Thoughts on text styles, Show Paragraphs, and internal representation
From: Randy Kramer (rhkramer@fast.net)
Date: Sun Jun 25 2000 - 13:11:19 CDT
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
This archive was generated by hypermail 2b25 : Sun Jun 25 2000 - 13:09:56 CDT