On Sat, Jun 27, 2015 at 2:09 AM, Peter Kelly <[email protected]> wrote: >> On 25 Jun 2015, at 8:03 pm, Ian C <[email protected]> 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.
Thanks Peter, I will try to make it so, and in way that whoever comes along afterwards can see what is happening. > > 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 > [email protected] > > 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) > -- Cheers, Ian C
