<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div>
><br>
> There is perhaps a way, that i started to explore for change tracking<br>
> without much success (but i didn't pursue this very long). It seems<br>
> possible to specify additional formatting at layout stage (QTextLayout<br>
> class I think). I don't know how usable this is. Camilla should know much<br>
> more than me about this one.  <br></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Unfortunately it's very limited and doesn't begin to cover what we will need </blockquote>

<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
from it.<br></blockquote></div><br><br>Well, we then really need to make a decision, which is better be very well discussed and thought out.<br>The situation is the following (add some if I have missed any):<br><br>Current QTextDocument/QTextLayout does not allow us to do:<br>

<br>- <b>change tracking</b>: we want to be able to display/hide tracked changes inline. For this we need to be able to switch visibility on a text fragment. The way I believe it should be working is that we would put a flag/text property on a text fragment. At layout stage (line lay out within QTextLayout internal), we would ignore these fragments.<br>

- <b>DFM writing</b>: we want to be able to display/hide text formatting. This IMHO should also be handle within QTextLayout internal layouting/drawing. It is after all purely a display option. The document content/formatting is not changed.<br>

-  <b>something about Bidi I can't remember</b><br><br>Now, we have so far managed to work around these limitations one way or another. The solution I am proposing for DFM (ie having different versions of each style), can be used for implementing it, although there is the problem of the undo/redo action it will create (same problem as when switching show/hide changes in change tracking). Independently of DFM, I think having "style profiles" would still be a killer feature both in Words and Author (I can look into this while I am through with parent style saving), and for this sole use case, the undo/redo action actually should be created.<br>

<br><br>So the question is: is it time for us to fork QTextDocument/QTextLayout in order to implement these properly? The main problem is the maintenance burden. However I am not sure it really would be that much, I think these classes are now really mature and won't change that much. However, since I personally don't have the time to do all this, the decision is not mine.<br>

<br>Pierre<br>