Subject: Re: Zero-length Runs and show codes
From: Paul Rohr (paul@abisource.com)
Date: Wed Feb 14 2001 - 11:59:32 CST
At 02:08 PM 2/14/01 +0100, Jesper Skov wrote:
>Present status is that I have removed most zero-length Runs and have
>introduced a new end-of-paragraph Run. Most of the editing logic seems
>to be working and the blocks/lines/runs work sensibly together.
Wonderful! I'm really really happy to hear this.
>There's still a lot to be done (redraw flaws need fixing, proper show
>modes behavior, mouse pointer selection, selection of page/line
>breaks, etc), but I think I might actually get it done this time.
Great. If you've already got all the editing interactions with the piece
table working (including undo), then you're definitely in the home stretch
now.
However, if you start running out of time, please post a patch with TODOs
and a summary of remaining work, in case anyone else feels like following in
your footsteps. ;-)
>However, I have some (simple) questions:
>
> o how do I draw the funky q (reversed/mirrored P)?
#define UCS_PILCROW ((UT_UCSChar)0x00b6)
This glyph (aka the ¶ entity in HTML) is in the Latin-1 range of
Unicode, so I'd assume that it should be available in most decent fonts.
http://www.unicode.org/charts/PDF/U0080.pdf
If not, then we should extend the existing glyph substitution logic to
handle this case as well.
> o what font should be used, and what size? If the previous text is
> 28pt should the 'q' be sized like that as well?
Yes. We definitely want these to be proportional.
Your best bet is to draw that character using the same font as its
neighboring text. I forget whether it should look left (into the end of
the prior para) or right (into the next one), but it's probably similar to
the cursor-sizing logic. I'm sure Randy will know.
>And about followup features:
>
> o About show codes mode (presently show paragraphs mode): page/line
> breaks are shown by drawing a line with text in it.
Uh, that should only be true for forced column and page breaks. Forced line
breaks should draw inline at EOL with a special symbol, just like you're
doing at EOB.
AFAIK, there's not an appropriate Unicode glyph for this in most fonts, so
just draw something like the "enter arrow" with the same sorts of
GR_Graphics calls as used for tabs.
In summary, all of the inline stuff should be drawn proportional to the
current fontsize, in the same grayish color. Some of these can use glyphs
from the font (to get the size and positioning right):
UCS_PILCROW (at EOB)
UCS_MIDDLE_DOT (for spaces)
Others need to do some math to figure out what size to do the relevant
GR_Graphics calls:
left-to-right arrow (for tabs)
down-and-then-left arrow (for forced line breaks)
Page, column, and section breaks are different. In Normal View, they're
always drawn with lines of some sort (dotted or dashed or something) to show
the separation. Obviously, there's no need to draw calculated breaks in
Page View mode -- which is all we do now -- because you can see where they
happen on the page.
Forced page and column breaks, which need to be selectable, are drawn even
more prominently. (IIRC, they get labels on top of those lines.)
> I've disliked that because it looks weird. Maybe because the only
> other place I've seen anything like this used is in WP5 where it
> would be <linebreak> or <pagebreak> instead of something drawn.
>
> Would anyone object if I made AbiWord show codes work like that?
Yep. ;-)
> Also, IIRC, the codes are drawn using available space and do not
> properly reserve screen estate. That needs fixing since it can
> result in some weird looking pages.
Examples, please? I'm trying to think of a screw case where the approach
described above couldn't work, and nothing comes to mind.
> o I plan to make all special page/line/paragraph breaks
> selectable. In show codes mode they will be visible and they will
> be highlighted. In !show codes mode they will just be one pixel
> wide and invisible (but still editable).
Excellent. Without something like this, cursor-based editing doesn't quite
Just Work.
One minor suggestion, though -- keep the widths the same even when the
breaks are invisible. Not only will this be easier to code, but it makes
for a much more consistent and predictable user experience.
In short, what you select should be the same "size" whether you're currently
seeing it or not. This is already true for spaces and tabs, and the same
principle should apply for breaks of various kinds. People very quickly get
used to the idea that:
I just selected a single something, but it's invisible.
By getting the widths and locations right, people can quickly infer what
they just selected by noticing the answers to 2 questions -- Where is it?
How wide is it?
between two words ==> either a space or a tab, so check the width
at the end of a paragraph ==> obvious
at the end of a line ==> obvious
bottom of column, full width ==> obvious
bottom of page, full width ==> obvious
In fact, as soon as you get the hang of this, you rarely need to turn on the
View All mode, because you can tell what's going on based on this selection
feedback. View All simply becomes a more explicit cheat sheet.
> This may be post 1.0 - but more likely it's needed for completion
> of the end-of-paragraph code.
Yep. However, feel free to commit earlier patches which don't include this
functionality. The behavior we currently have in CVS works, but it's very
annoying.
Keep up the good work!
Paul,
pixel pusher
This archive was generated by hypermail 2b25 : Wed Feb 14 2001 - 14:00:56 CST