Questions about Domain Mapper
vmiklos at collabora.co.uk
Wed Nov 20 06:29:36 PST 2013
On Wed, Nov 20, 2013 at 02:42:25PM +0200, Adam Fyne <adam.fyne at 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
> 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:
> 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
> 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:
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,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: Digital signature
More information about the LibreOffice