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