Hi,
Florian Reuter wrote:
Hi Oliver,
thanks for the feedback.
Regarding the <field-start/>, <field-end/> (which is my favorite too) there
seems to be some resistance, e.g. from Svante who dislikes it, 'cause XLS(T) processing
gets worse...
Maybe we can convince him with the fact that the content of the field
resides inside of the normal content flow. Each XSLT processing that
doesn't need the field code (e.g. XHTML) simply skips it. Those that
need to convert the field have to write additional code anyway.
The other thing which bothers me are operations like copy/paste. I tried to use
bookmarks to simulate fields but had enourmous problems implementing operations
like copy/paste.
Selections that do not contain the field completely should not copy the
field command. Bookmarks are handled like that already. See
sw/source/core/docnode/ndcopy.cxx, lcl_CopyBookmarks().
However I agree generic start/end would be cool.
My idea to implement a real generic field would end up having the current SwDoc
to be somehow virtual. I.e. you have to SwDocs. Maybe this will help us for
change tracking too.
I don't think I understand what you mean.
I dislike the idea of moving field content from some additional
SwNode(s) to the field position. It should be in the normal position all
the time. In the 'display field command' mode this content needs to be
hidden and the field start has to be expanded to the command text.
The change tracking problems we have are mostly caused by the fact that
hidden redlines _are_ moved to a certain area in the nodes array. If we
were able to simply hide the text some things were a lot easier.
The challenges here are merging two (or more) text nodes into one
formatting frame and the correct numbering (which BTW not even works
with our current hidden paragraph text fields :-( )
Regards,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
