Subject: Re: multiple line pastes
From: Paul Rohr (paul@abisource.com)
Date: Tue Mar 28 2000 - 11:48:22 CST
Matt,
You're quite right about the FASTSQUIGGLE assert at block boundaries.
That's the one screw case which never got implemented cleanly. The assert
is there as an annoying reminder to finish the feature.
At 09:41 AM 3/27/00 -0800, Matt Kraai wrote:
>As for the bugs I was actually looking at, it appears that the RTF
>importer always drops the last empty paragraph when reading, both from
>a file and from the Paste buffer. This can be simply fixed by changing
>the lines at the end of ie_imp_RTF.cc:IE_Imp_RTF::_parseFile from
>
> if (ok)
> {
> ok = FlushStoredChars();
> }
> return ok ? UT_OK : UT_ERROR;
>
>to
>
> if (ok)
> {
> ok = FlushStoredChars(UT_TRUE);
> }
> return ok ? UT_OK : UT_ERROR;
>
>but it appears from the comments that the current behavior may be
>intentional. Does anyone know about the RTF importer, and what it
>is trying to do with empty/trailing paragraphs?
I'm not clear on all the details here, but as you've noticed, we need to
make sure that everything works properly in both situations:
- importing an entire document from a file
- reading a selection off the clipboard
I'd be willing to bet that the behavior you're seeing is related to the
latter case. Consider what should happen when any of the following get
copied to the clipboard:
1. a few words inside a single paragraph
2. the tail end of one paragraph and the beginning of the next
3. just like #2, but with an empty paragraph in the middle
4. the tail end, plus two full paragraphs
5. etc.
The original implementation had one too many paragraph breaks (especially in
case #1 above). I'm not familiar with the current logic, but there may be
cases where we wind up with one paragraph too few.
If your fix properly handles screw cases like 1-4 above, then we're all set.
Paul
This archive was generated by hypermail 2b25 : Tue Mar 28 2000 - 11:42:47 CST