> On 25 Jun 2015, at 8:03 pm, Ian C <i...@apache.org> wrote: > > In the same we use lenses to focus in on a document's content > shouldn't we do the same for styles?
Yes, and we do so already, at least in a conceptual sense, though it’s not obvious from the code itself. Abstractly, a lens is a triple of operations - get, put, and create. For lenses which operate on the DOM tree, we represent these explicitly, in the form of the DFLens structure defined in DFBDT.h, and the corresponding but compatible struct WordLens defined in WordLenses.h. These structs add two additional methods, isVisible and remove, which are used for working with the tree node update algorithm in DFBDT.c. In the Word filter, in the ‘formatting’ subdirectory, there are collection of file which each implement one (conceptual) lens for each type of formatting node - pPr (paragraph properties), rPr (run properties), tblPr (table properties) and others. Both of these have a get and put function which operate on a DOM node for the concrete representation, and a CSSProperties object for the abstract representation. These have to explicit create function, but create in this context is equivalent to calling the put function with an empty CSSProperties object. Since CSS properties are maps, not trees, the logic to deal with these is simpler. The put logic checks, for each relevant property, if the old value of the property is different from the new value of the property (either of which could be ‘absent’, i.e. NULL). If there is any change, then the relevant portion of the DOM subtree from the concrete document (styles.xml) is updated to reflect the new value of that CSS property. If there is no change, then it is left as-is; thus, for example, double-underlining (which can be expressed in Word but not CSS) is translated to text-decoration: underline upon get, but if you do a put with text-decoration: underline, it will consider this to be “no change”, and leave the double-underlining there, thus preserving what (in this particular case) are richer formatting semantics supported by Word than can be expressed in CSS. The concrete (DOM) properties are only updated if the abstract (CSS) properties have changed. I would suggest a similar approach for the ODF filter - the way that formatting information is represented in it’s own styles.xml is very similar, the main difference is that properties are represented as XML attributes rather than child elements. The other BDT structures and code used for the main document structure are appropriate for trees (and are more complicated), but do not fit directly with the model I’ve just described. But pairs of functions like WordGetRPr and WordPutRPr are still, conceptually, lenses. — Dr Peter M. Kelly pmke...@apache.org PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
