Hi Adam, On Wed, Nov 20, 2013 at 05:49:59PM +0200, Adam Fyne <adam.fyne@cloudon.com> wrote:
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.If a redline can contain 10 paragraphs inside of it - what's the logic in firing an action when a run inside one of those paragraph ends?
I haven't tried, but I *think* that could be indeed optimized, to just store the start position (XTextRange UNO object) of the redline, and create the redline in the document model when it ends.
Did you mean to say that the 'paragraph redline' is getting converted to fragmented 'run' redlines for each of the runs inside the paragraph?
I don't think there are separate run and paragraph redlines in fact. Redlines are like bookmarks: they just have a start and end position, and there can be anything between the two. And yes, what writerfilter does is splitting up the redlines into small parts, where each part covers a single run, then (I suppose) these pieces are connected together again in core. (That's why I mentioned above that I think this can be optimized.)
Why is the 'RemoveRedline' called at the end of a run if the 'm_aRedlines' contains 'paragraph' redlines? It doesn't make much sense to me.
If you mean the CheckParaRedline() method, it seems OOXML has a method to mark a single paragraph as redlined as well (and then it strictly marks only that paragraph, not a random range like bookmarks), then it makes sense to remove that at the end of the paragraph. If you mean RemoveCurrentRedline(), that's not called at the end of the run, only when a redline ends (endtrackchange token).
The point is that in general redlines are more like bookmarks, not like runs or paragraphs.Redlines should be considered more like runs\paragraphs - because they have content inside of them, not only markers to where a redline is, no ?
Hm, but redlines can contain paragraphs, while if you say redlines are like paragraphs, paragraphs can't contain paragraphs, so the analogy seems a bit misleading to me.
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.Not handled = are in the switch case but do nothing OR are not even in the switch case?
Just grep for it in the 'dmapper' directory, if you get no hit, then not even in the switch-case.
In the switch-case I see 'case NS_ooxml::LN_CT_RPrChange_rPr:' and that's where I've added the line of code below. But how do I know if it's the 'rPrChange' of 'ooxml:EG_RPrContent_rPrChange' or 'ooxml:CT_ParaRPr_rPrChange' token that you've mentioned?
The ooxml:CT_RPrChange_rPr token represents an "rPr" XML element, the above two tokens represent the "rPrChange" XML element in two different contexts. So it's none of them. :-)
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.the 'author' and 'date' are attributes of the redline, not sub-elements. I want the subelements of the 'rPr' to be stored in the 'RedlineParams'.
That's just a detail, you know that you can store any string information both as attribute or as the text of a child element as well.
When I look at the code that processes these nodes - I see that all of these parameters are being processed here http://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/DomainMapper.cxx#2114 and all are being inserted to the 'rContext' or used with 'appendGrabBag'. So it seems like I should add a flag that is turned on when 'rPrChange' is entered, and add a lot of 'if-else' statements in the code that processes all the 'italic', 'bold' etc to check - if the flag is 'on' - insert the property to the 'RedlineParams' structure, otherwise - insert the property to the 'rContext'. Is this the right approach? It will dirty the code...
You don't have to deal with each property individually, you can just handle the collected properties. Have a look at text::XRedline, its makeRedline() method takes a beans::PropertyValues, which is a string-any map in practice. You can add a new "RedlineOldformat" (or similar) key to that map, and the value of that key can be your property list. When you handle that property in sw core, you can convert that to an SfxItemset. (Have a look at how to code handles the "property list" -> SfxItemSet conversion when you append a new text portion with a given set of properties.)
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?The 'SfxItemSet' would hold all the properties from the 'rPr' node? How would I 'set' this 'SfxItemSet' from the importer? (let's assume in the importer's RedlineParams object I will have a list of all the properties and values somehow)
Just pass the property list to core (as described above), and in core you can do the conversion. Hope this helps, Miklos
Attachment:
signature.asc
Description: Digital signature