[Scribus] Comment about object tag names and xml file format

[Timo Stollenwerk]

avox schrieb:
> 1) Allow content of textframes to be stored in external files (or in remote
> database)

The possibility to store Scribus content as external file is definitely
a promising idea and it would make some tasks easier to accomplish.

> 2) Allow content of textframes to be arbitrary XML. Elements and attributes
> are
>     preserved when you save changes from Scribus.
> 3) Scribus attaches its styles to XML content via new "scribus:pstyle" and
> "scribus:cstyle"
>     attributes. Where possible, CSS properties should be used for Scribus
> style properties.
> 4) When attaching XML content to a Scribus frame for the first time, Scribus
> converts CSS
>     styles to Scribus styles. 

In my solution I'm transforming logical structured XML data (DocBook
without CSS or any style information) into Scribus pageobjects.
Predefined global styles are attached to DocBook nodes (e.g. attach the
"Standard-Paragraph" Scribus style to every "para" node in DocBook) by
the XSL stylesheet. Unnamed styles are not allowed (maybe in a later
version, but round-tripping with unnamed styles is very difficult).

> 5) When the user inserts a new paragraph separator, the lowest level block
> element at that position
>     gets divided into two. Eg. <p>blabla|bla</p>  --> 
> <p>blabla</p><p>bla</p>
> 6) Deleting a paragraph separator merges the two lowest level block
> elements, keeping the element
>     name of the block element with the lowest level. If both levels are the
> same, keep the first element
>     name. 
>     Eg.: <chapter><p>BLA</p></chapter><sec>blabla</sec>   
>     -->  <chapter><p>BLAblabla</p><chapter>
> 7) When the user changes the formatting of a run of characters, Scribus
> inserts a new "" 
>     element and sets the appropiate style for it.
> 8) Scribus special characters are inserted as new "<scribus:break>",
> "<scribus:field>" etc. elements. 
> 9) The XML structure is only visible (and editable) in the story editor.

I can't estimate how much work your proposal requires, or how much time
it would cost to implement it, but my diploma thesis ends in 4 month. So
I think I have to come up with a solution that works with the current
Scribus version. Nevertheless I'm interested in discussing these issues.

> Would that work for round-trip editing? The CMS would have to accept and
> preserve the new elements
> and attributes from the "scribus:" namespace. Scribus could provide a
> scribus.css which describes how
> those should be interpreted by other applications.

When the CMS preserves (and maybe show the scribus styles with  a
scribus.css file), round-tripping should be possible.

But in my view the content editor should only be allowed to edit the
logical structure of a document (e.g. define headlines, emphasis) and
not the styles of a document.

Right now I'm working on the implementation of the one-way editing
solution, after that I'm going to deal with the round-tripping issues.

> What about IDs? I guess the normal "id" attribute would have to be
> translated to some "external-id" attribute to avoid clashes within the
> Scribus doc.

Right now I'm generating unique ids for every node in the DocBook file.
These ids are attached to Scribus pageobjects together with the content.
When the content of the DocBook file changes, these changes can be
injected into the pageobject (with the corresponding id), keeping
Scribus styles and layout changes untouched.

Another possibility to attach Scribus pageobjects to DocBook nodes is to
store XPath expressions in Scribus pageobjects to refer to the
corresponding node of the DocBook file (this would even allow to refer
to separate documents). But this would require an additional pageobject
attribute, because XPath expressions are not allowed in the ANNAME
attribute. Is there any field in the current Scribus file format that
could be used to store XPath Expressions?

Regards,
timo