corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian C <...@amham.net>
Subject Re: lenses for styles?
Date Sat, 27 Jun 2015 03:20:00 GMT
On Sat, Jun 27, 2015 at 2:09 AM, Peter Kelly <pmkelly@apache.org> wrote:
>> 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.

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
> 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)
>



-- 
Cheers,

Ian C

Mime
View raw message