corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <pmke...@apache.org>
Subject Re: lenses for styles?
Date Fri, 26 Jun 2015 18:09:49 GMT
> On 25 Jun 2015, at 8:03 pm, Ian C <ianc@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
pmkelly@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)


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message