[Libreoffice-commits] core.git: sw/inc sw/source

Ashod Nakashian ashnakash at gmail.com
Mon Aug 21 02:37:33 UTC 2017


Hi Michael,

On Fri, Aug 18, 2017 at 6:32 AM, Michael Stahl <mstahl at redhat.com> wrote:

> On 17.08.2017 17:10, Ashod Nakashian wrote:
> > Hi Thorsten,
> >
> > On Wed, Aug 16, 2017 at 5:22 AM, Thorsten Behrens <thb at libreoffice.org
> > <mailto:thb at libreoffice.org>> wrote:
> >
> >     Miklos Vajna wrote:
> >     > The idea is that per-paragraph signature should be non-chained,
> similar
> >     > to per-document signatures, so the Writer field(s) representing the
> >     > signature(s) should be filtered out before hashing, but otherwise
> this
> >     > just takes the paragraph text as-is. (My understanding is that ODF
> >     > specifies what is the exact paragraph string for a <text:p>
> element.)
> >     >
> >     Hi Miklos,
> >
> >     ok - as long as that could be described (or pseudo code given),
> >     that'll do I guess. Just be aware that text:p can still be quite
> >     complex in xml, with whitespace mangling & all sorts of child
> elements
> >     (see paragraph-content-or-hyperlink / paragraph-content in the
> >     schema).
> >
> >
> > The code currently in master was a temporary first step. The logic I
> > currently have locally ready to push soon is to only use Text portions.
> >
> > Roughly as follows:
> >
> >   OUStringBuffer strBuf;
> >   for (auto& portion : paragraphTextPortions) {
> >       if (portion.TextPortionType == "Text")
> >           strBuf.append(portion.Text);
> >   }
> >   sign(strBuf.makeStringAndClear());
> >
> > I expect this should exclude any unwanted fields/characters/LO-specific
> > conversions etc.
> >
> > Let me know if there are concerns with this approach.
>
> there are some other portions that, depending on what you want to do,
> could be interpreted as containing text:
>
>
Thanks, I think these should be considered for inclusion. Currently I'm
excluding anything that isn't TextPortionType=="Text", so it's limited
coverage.


>
> there are various other functions to get "cleaned up" text from a
> paragraph, such as SwTextNode::GetExpandText() and class
> ModelToViewHelper but i'm not even sure why there are several different
> ones and when to use which one.
>
>
These don't seem to give us what we need, and I couldn't find an
obvious/easy way to extend them. GetExpandText uses ModelToViewHelper, so I
tried using ModelToViewHelper with Replace but (though it should've worked)
since it depends on the hints to be up-to-date, it's failing (at least in
some scenarios hints are empty, which means it returns the display text as
default, which includes all fields).

For now I have a small helper (sadly, which adds yet another way of getting
"cleaned up" text) that uses the UNO API to enumerate the text portions of
the current TextNode and constructs the text to be signed per the above
pseudo-code. Ideally we'll convert that to internal API and extend
ModelToViewHelper with a new flag/enum to return signable text. Hopefully
I'll get to it once I reach a stable milestone.

Thanks,
-Ash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20170820/582eb07d/attachment.html>


More information about the LibreOffice mailing list