Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Tue, 2011-09-20 at 22:10 +0400, Ivan Timofeev wrote:
2011/9/20 Caolán McNamara <caolanm@redhat.com>:
Hmm, if in normal mode I type in 3-4 I get that range previewed, change
it to "foobar" and it stays previewing 3-4, which isn't great either
really.

In normal layout in Writer and in any modes in other apps, i.e.
brochure layout in Writer is the only dissimilar place. I think that
ideally there must be a filter that keeps the "Range" field out of
incorrect input according to context... 

yeah, 

a) for normal print mode at core/sw/source/core/doc/doc.cxx in
SwDoc::CalculatePagesForPrinting we call
StringRangeEnumerator::getRangesFromString without clearing the
o_rPageVector argument, so if someone has typed 5-6 and then types .
then when aEnum.setRange returns false with e.g. "5-6." the old valid
"5-6" range result remains in the vector so what pages were previously
selected remain unchanged when the range text becomes invalid.

b) while for brochure print mode at core/sw/source/core/doc/doc.cxx in
SwDoc::CalculatePagePairsForProspectPrinting we call
StringRangeEnumerator::getRangesFromString with an empty o_rPageVector
argument and we've already cleared rPagePairs, which gets filled from
the page vector argument, so the prior page selection has been thrown
away.

Indeed, moving the code to clear rPagePairs below the call to
StringRangeEnumerator::getRangesFromString in b would indeed make it
work like a.

mode a is probably prone to nasties though, e.g. we may get different
results between typing an invalid range in (e.g. "1-5.") vs pasting it
in, seeing as when typing "1-5." "1-5" will be seen before . is typed.
So the output will remain 1-5 when the invalid "1-5." is later seen. If
pasted in however we may see "1-5." straight away, and so retain the
range value seen before the paste started.

So I reckon we might be better off modifying
StringRangeEnumerator::getRangesFromString to always clear its page
vector argument, and then its probably worth being more forgiving and
output what valid ranges in the text can be extracted before the
invalid chars are seen.

So "1-5junk" ends up always equivalent to 1-5 (if the return code is
ignored) and "junk" is equivalent to 0.

But what about of my original patch for now?

What do you think about
http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a0e780d8a4194c812f436a2362098202fcfa29e
?, does that make things consistent without any obvious problems ?

C.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.