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

[Timothy Boyden]

Yes, I agree we have two different goals, however I believe we share the
common goal in having a way to describe a Scribus document so it can be
manipulated on the Internet. XSL transformations with XML schemas definitely
seem like the way to go in this case.

I assuming by structure you mean a tree structure like the following?

<scribusdoc>
    <pageobj id="page1" width="8.5in" height="11in" >
        <graphicobj id="scribuslogo" xpos="25" ypos="25" width="3in"
height="3in" src="images/someimage.tiff" />
        <txtobj id="mytext" xpos="100" ypos="100" >
            <p style="par1">Here is some text.</p>
        </txtobj>
    </pageobj>
</scribusdoc>


For my experimentation, I am looking to simply display a jpeg preview of the
document, followed by a list of text form fields pre-filled to the current
text items in the document, allowing a non-DTP skilled user to make quick
edits to a Scribus document. The possibility also exists to allow the user
to swap out images in the same way. These Scribus documents would be
template documents and the forms would allow limited editing (similar number
of text characters, same size images, etc...). I would equate more what I'm
looking to do to be Adobe Contribute for Scribus documents. More advanced
logic could be programmed to automatically enlarge text or image frames to
fit differently formatted text or enlarged images in future versions.


-Tim
        


On 3/2/08 11:13 AM, "Timo Stollenwerk" <lists at zmag.de> wrote:

> Timothy Boyden schrieb:
>>> From what I've seen I think you could turn a Scribus document into a HTML
>> form with a XSL stylesheet and then submit the changes to a script that
>> could output a new Scribus document containing the changes.
> 
> My approach is the opposite of what you describe. The content of a
> Scribus document contains no structural information about the content,
> so it's hard to generate html forms that make sense. If you generate the
> forms in the way they appear in a Scribus source document, it's hard for
> the user to know where to put the content, even if you use the ANNAME
> attribute to describe every corresponding Scribus Pageobject.
> 
> The general idea is that the CMS takes care about the form generation
> and the content types. That way, the CMS can keep track of the
> structural information of the data and present it to the user in a
> meaningful way.
> 
>> I've done that
>> to a certain extent with a PHP script that I've been playing with. The
>> schema definition will help as a documentation tool for the Scribus format,
>> that could allow me to build a PHP class for manipulation of Scribus
>> documents.
> 
> It should be pretty easy to take my XSL stylesheets and write a wrapper
> class in PHP. It is easy in Python. :)
> 
>> The XSL would also allow you to translate the Scribus doc to display it in a
>> web page, sort of a Scribus viewer plug-in for the web. The most efficent
>> way to do that most likely would be to create a schema that translate
>> Scribus objects to SVG objects. Then create a XSL to display the Scribus
>> doc.
> 
> I don't think this is necessary. Scribus can generate pdf files, and you
> can preview these pdf files in a CMS (e.g. there is a product to preview
> arbitrary files, including pdf, in Plone)
> 
>> The combination of these technologies of course could lead to a web-based
>> version of Scribus.
> 
> I'm trying to avoid this with my solution, because I don't think it
> makes sense to reinvent the wheel in a web-based version. Scribus and
> other DTP applications are complex software products that can't be
> easily be rewritten.
> 
> What I'm trying to do is to seperate the structural information of a
> document from the layout specification so that every application
> (Scribus and CMS) can do what they are best at. Scribus can take care of
> the layout specification and the CMS can take care of handling the content.
> 
> Regards,
> timo
> timo