[WebODF] OpSetParagraphStyle and OT

Philip Peitsch philip.peitsch at gmail.com
Wed Jun 26 12:05:30 CEST 2013


On 26 June 2013 19:58, Philip Peitsch <philip.peitsch at gmail.com> wrote:

>
> On 26 June 2013 03:26, Friedrich W. H. Kossebau <friedrich at kogmbh.com>wrote:
>
>> (There is also anothe issue, in that there are the parameters
>> "styleNameBefore" and "styleNameAfter", of which only "styleNameAfter" is
>> used, and for the other so far no use is seen. So ideally
>> "styleNameBefore" is
>> removed and "styleNameAfter" is renamed to just "styleName")
>>
>
> +1 for this.
>
>
>> Now here are the samples where things fail ATM (always assuming A's ops
>> have
>> priority):
>> Doc: <text:p>Text</text:p>
>> A: [<setParagraphStyle pos="0" styleNameAfter="S1" memberId="A"/>]
>> B: [<setParagraphStyle pos="3" styleNameAfter="S2" memberId="B"/>]
>> Obviously hard to know if both target the same paragraph.
>> Proposal: fix by identifying the paragraph with by its first position
>
> ...
>>
>  Using this proposal, there is another issue:
>> Doc: <text:p>AB</text:p><text:p>C</
>>>
>>> text:p><text:p/>
>>> A: [<setParagraphStyle pos="3" styleNameAfter="S1" memberId="A"/>]
>>> B: [<removeText pos="0" length="1" memberId="B"/>]
>>> How can the setParagraphStyle op be transformed against the removeText
>>> op, in
>>> such a way that the pos attribute again points to the begin of the
>>> paragraph?
>>> There is no information in the removeText op which paragraphs are
>>> affected and
>>> how.
>>
>> The desired intent is that each client end up with the same document,
> though the ops
> are processed in a different order right.
>
> Consider the following scenario:
> <text:p>P1</text:p>
>
> A: [<setParagraphStyle pos="P1 start" ...>]
> B: [<splitParagraph pos="P1 start" ...>]
>
> Client A processes A then B, and ends up with the style applied to both
> paragraphs (this is the intended result).
> Client B splits first, then needs to realise that the style should be
> applied to the new paragraph as well.
>
> If setParagraphStyle carries both the start and end of the paragraph
> positions, it would be trivial
> to tell where the old styled paragraph ended. Every paragraph up to this
> point is expected to carry the
> new style. For the above example, client B would perform the following
>
> 1. Apply splitParagraph at position 1 (just after the 'P'). This inserts a
> new cursor position.
> 2. Transform setParagraphStyle end pos (or length) by +1
> 3. setParagraphStyle fetches all paragraphs in the specified range and
> applies the style to these
>
> Is there a glaring hole in that approach?
>

A further thought on this.

The key problem with the removeText is that it can change the paragraph
boundaries. Potentially to cope with this, the setParagraphStyle can assert
that it's start position *is* a
paragraph boundary, and if this isn't the case, skip to the next following
paragraph
(as long as the following paragraph start is before the setParagraphStyle
end).

This would handle the the following case:
<text:p>P1</text:p><text:p>P2</text:p>

A: [<setParagraphStyle pos="P2 start" ...>]
B: [<removeText pos="P2 start" length="-1"...>]

In this case, the style applied to P2 should be discarded by client B, as
the supplied position
no longer indicates the start of a paragraph.

-- 
Philip Peitsch
Mob: 0439 810 260
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/webodf/attachments/20130626/ac35225a/attachment.html>


More information about the WebODF mailing list