https://bugs.freedesktop.org/show_bug.cgi?id=69416

--- Comment #7 from Michael Stahl <[email protected]> ---
forgot about this for a while, and now comment #6 says that
XProofreader clients actually want to know where the footnotes are,
which looks like a new requirement?

it appears to me that there is no good use-case for providing
the expanded footnote numbers or field contents to grammar checkers,
that is all auto-generated anyway so should be filtered out.

so what can we do here:

a) replace footnotes with ZWSP
   + word/sentence breaking works
   + Writer internals stay internal
   - grammar checker cannot tell that there is a footnote there
b) filter out \u0001 without replacement
   + better than silly numbers in the text
   + Writer internals stay internal
   - grammar checker cannot tell that there is a footnote there
   - grammar checker cannot break sentence/words properly
c) let \u0001 remain in text
   + word/sentence breaking works (but requires special handling of 0x01)
   - leaks Writer internals
   - \u0001 is not guaranteed to be a footnote, could be frame or field...
d) basically a) + add some out-of-band thing like "FootnotePositions" property
   + Writer internals stay internal
   + word/sentence breaking works
   + grammar checker can tell that there is a footnote there
   + grammar checkers that don't care about footnotes can just ignore it
   - requires more code in grammar checkers
e) re-map footnotes to some funky custom code point (Unicode has
   some "private use" area?)
   - not sure what this would mean for ICU break iterators,
     would it require custom ones that treat the new char specially like
     they did \u0002 ?
   - requires special handling in grammar checkers

guess d) meets requirements the best; i think it requires passing the
new property as part of XProofreader::doProofreading parameter "aProperties".

something like a sequence<long> to indicate the UTF-16 code unit positions.

would require getting that property to the GrammarCheckingIterator,
which only has a XFlatParagraph; that would require some property for it too,
hope it's possible to add that. 

the grammar checkers don't accesss XFlatParagraph directly, right?

does everybody agree this is the way to go?

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to