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


Hi Adam,

On Wed, Nov 20, 2013 at 02:42:25PM +0200, Adam Fyne <adam.fyne@cloudon.com> wrote:
1\ 'DomainMapper_Impl::appendTextPortion' creates a variable called
'xTextRange' but doesn't do anything with it.
How does that end up in the Writer core objects?

The insertTextPortion() or appendTextPortion() UNO calls in that method
already add the string with its properties to the document model, what
is returned is just a reference to already added text, in case you want
to do something with it later.

2\ 'DomainMapper_Impl::appendTextPortion' is being called after every 'run'
of the DOCX. In that function - it calls 'CheckRedline'. 
It looks like 'CheckRedline' simply runs over all the 'redlines' in the
'm_aRedlines' and for each one - calls 'CreateRedline' without really
checking anything.
why is it doing that?

My understanding is that 'CheckRedline' is not checking existing
redlines, but it checks if there are any pending redlines at all. And if
there are any, the relevant redlines in the document model are created.

3\ at first look - it looks like 'm_aRedlines' is holding all the redlines
in the document, but it is not true.
after each paragraph - the redline is being removes (for 'ins' and 'del').
so maybe it should be 'm_aRunRedlines' ? Why would we want it to be a vector
and not a single member? When could it store multiple redlines inside?

A redline may contain multiple runs or paragraphs. When the redline
starts, it's added to m_aRedlines, and once it's finished, it gets
removed. This is handled in AddNewRedline() and RemoveCurrentRedline().
When a run ends, all the action redlines (which are referenced by
m_aRedlines) are "created", then Writer core takes care of actually just
extending existing redlines, if that's necessary.

So if you have a paragraph like "...<ins>X<b>Y</b>Z</ins>...", then
CreateRedline() will be called 3 times, even if the resulting document
model will only contain a single redline.

The point is that in general redlines are more like bookmarks, not like
runs or paragraphs.

4\ Currently - the domain mapper doesn't analyze the nodes that are inside
'w:rPrChange'.
That is because this case 'case NS_ooxml::LN_CT_RPrChange_rPr:' doesn't do
anything (right?)

rPrChange may result in an ooxml:EG_RPrContent_rPrChange or
an ooxml:CT_ParaRPr_rPrChange token, depening on the context. Neither of
the tokens are handled in dmapper, as far as I see.

So I've added inside of it a call to 'resolveSprmProps'.
When I look at the DomainMapper dump now - I see that now it DOES analyze
the nodes inside 'rPrChange' (is this the correct step?)

Yes, all you want from a token is to recurse into its children, then the
only call you need is:

resolveSprmProps(*this, rSprm);

My next step would be to somehow store all these properties in a 'redline
formatting' object, and attach it somehow to the 'redline' object.
How can I do this?

Take a look at how already handled redline properties are handled. E.g.
for NS_ooxml::LN_CT_TrackChange_author, we just store the string in the
impl class using a setter method, you can do the same for new
properties. Inside the impl class, there is a simple RedlineParams
struct that stores currently handled parameters, you can extend that for
you needs.

5\ How would you suggest to store these run properties in the redline?

Should I simply store them as a property map in the redline object in the
Core, and then if the user 'rejects' or 'approves' - convert this somehow
from 'XRange+PropertyMap' to 'Hints',

Or should I store it as an array of 'Hints+Properties' inside the redline
object in Core?

In sw core, SwRedlineData is the class that stores the author, date,
comment string and similar properties. It has an SwRedlineExtraData
pointer, which has two subclasses:

http://docs.libreoffice.org/sw/html/classSwRedlineExtraData.html

As far as I see, currently SwRedlineExtraData_Format only stores the
which ids of the formatting, e.g. the information that "the bold
property has been changed, etc" but neither the old, nor the new value
of the item. If you read SwRedlineExtraData_Format::Reject(), this means
that it knows what attributes have been changed, and if you reject the
change, it resets these attributes to their default value. (If the
change is accepted, then the document model already contains everything,
just the change should be deleted from the redline table.)

So what about adding a proper SfxItemSet to SwRedlineExtraData_Format,
and then when you need to reject the change, you could not just reset
the properties to their default, but you could restore their old values?

Hope this helps,

Miklos

Attachment: signature.asc
Description: Digital signature


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.