Darwin Information Typing Architecture (DITA) PlugIn, Adobe InDesign

[Erik-57]

Submitted on 09/24/2008 - 22:08
Submitted by anonymous user: [84.150.202.91]

Submitted values are

   Your contact information:
     Name: Erik
     Email Address: ditassp2@...
   About your Scribus program:
     Version: 1.3.3.12
     Prebuilt/Compiled: Prebuilt
     Build Date:
   Your operating system and CPU:
     Type: Windows
     Version: 2000/XP
     CPU type: 32bit  Intel/AMD (i386)
   Your request content:
     Subject: Darwin Information Typing Architecture (DITA) PlugIn, Adobe  
InDesign
     Message:
Hi,

are there any plans to create a DITA plugin for Scribus like mentioned below  
for Adobe InDesign and DITA?

http://blog.reallysi.com/2008/01/call-for-partic.html

http://dita2indesign.sourceforge.net/

cheers,

Erik







The results of this submission may be viewed at:
http://www.scribus.net/?q=node/158/submission/21



_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[avox]

Erik-57 wrote:

     Subject: Darwin Information Typing Architecture (DITA) PlugIn, Adobe  
InDesign

     Message:
Hi,

are there any plans to create a DITA plugin for Scribus like mentioned below  
for Adobe InDesign and DITA?

http://blog.reallysi.com/2008/01/call-for-partic.html

http://dita2indesign.sourceforge.net/

No. I've some ideas of making XML+CSS the native format for Scribus text frames.
It would allow to store the XML in external databases and do round-trip editing (just for
the content, CSS formatting would be one-way).

I've no ideas if and how we could restructure the XML on import without breaking the
round-trip editing facility. What kind of restructuring would be needed for DITA?

/Andreas

[Steve Herrick]

On Thu, Sep 25, 2008 at 10:35 AM, avox <avox@...> wrote:
>
> No. I've some ideas of making XML+CSS the native format for Scribus text
> frames.
> It would allow to store the XML in external databases and do round-trip
> editing (just for
> the content, CSS formatting would be one-way).

I floated this idea way back at the dawn of this list, years ago.
Without digging up those emails, I recall that the arguments in favor
were, first, consistency and second, portability, and the arguments
against were, first, how fine-grained would the control be?, and
second, how many times are we gonna re-invent the file format?

--
Steve Herrick

Maybe we can eventually make language a complete impediment to understanding.
- Hobbes the tiger

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[avox]

Steve Herrick wrote:

On Thu, Sep 25, 2008 at 10:35 AM, avox <[e-mail]> wrote:
>
> No. I've some ideas of making XML+CSS the native format for Scribus text
> frames.
> It would allow to store the XML in external databases and do round-trip
> editing (just for
> the content, CSS formatting would be one-way).

I floated this idea way back at the dawn of this list, years ago.
Without digging up those emails, I recall that the arguments in favor
were, first, consistency and second, portability, and the arguments
against were, first, how fine-grained would the control be?, and
second, how many times are we gonna re-invent the file format?

The Scribus fileformat is due for a complete overhaul anyway.

What were the details of your idea? My idea is to allow *any* XML
and use the CSS 'display' and 'class' attributes to provide links
to Scribus's style system. On first import, Scribus could synthesize
Scribus-styles from existing CSS formatting.

When saving, Scribus would use the 'class' attribute to point to a Scribus
style. The 'display' attribute would control if that is a paragraph style,
char style or other. Direct formatting would be translated to CSS attributes
or to a limited set of Scribus specific custom attributes.
Unknown attributes would be preserved by Scribus. Element names would be
meaningless to Scribus, since anything Scribus needs to know will be in the
attributes.

/Andreas

[Steve Herrick]

On Thu, Sep 25, 2008 at 1:15 PM, avox <avox@...> wrote:

> The Scribus fileformat is due for a complete overhaul anyway.

I thought we were in the middle of that right now.

> What were the details of your idea?

Well, I'm not a programmer, so it was all a bit fuzzy. :)

My idea is to allow *any* XML
> and use the CSS 'display' and 'class' attributes to provide links
> to Scribus's style system. On first import, Scribus could synthesize
> Scribus-styles from existing CSS formatting.

Well, *any* XML would encompass ODF and HTML, and I hope we can lump
in plain text, too. My thinking was that Scribus would simply replace
the existing characteristics, or better still, support them natively.
I assume all CSS would have to be inline, to allow fine-grained
control. Stylesheets would still exist, but to supply CSS that would
be pasted into inline tags.

> When saving, Scribus would use the 'class' attribute to point to a Scribus
> style. The 'display' attribute would control if that is a paragraph style,
> char style or other.

I'm not sure why you'd need that. What's wrong with simply having a
paragraph tag, an object tag, and a character tag?

Direct formatting would be translated to CSS attributes
> or to a limited set of Scribus specific custom attributes.
> Unknown attributes would be preserved by Scribus. Element names would be
> meaningless to Scribus, since anything Scribus needs to know will be in the
> attributes.

Sounds good.

Another thought just occurred to me: SVG is also XML. It makes my head
hurt to think about applying CSS to SVG, though I can't think of any
technical reason you wouldn't be able to. Anyway, I think that as long
as we're using XML natively, we could start to blur the line between
Scribus and Inkscape.

--
Steve Herrick

Maybe we can eventually make language a complete impediment to understanding.
- Hobbes the tiger

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus

[avox]

Steve Herrick wrote:

On Thu, Sep 25, 2008 at 1:15 PM, avox <[e-mail]> wrote:
...
> My idea is to allow *any* XML
> and use the CSS 'display' and 'class' attributes to provide links
> to Scribus's style system. On first import, Scribus could synthesize
> Scribus-styles from existing CSS formatting.

Well, *any* XML would encompass ODF and HTML, and I hope we can lump
in plain text, too. My thinking was that Scribus would simply replace
the existing characteristics, or better still, support them natively.
I assume all CSS would have to be inline, to allow fine-grained
control. Stylesheets would still exist, but to supply CSS that would
be pasted into inline tags.

> When saving, Scribus would use the 'class' attribute to point to a Scribus
> style. The 'display' attribute would control if that is a paragraph style,
> char style or other.

I'm not sure why you'd need that. What's wrong with simply having a
paragraph tag, an object tag, and a character tag?

Not sure what you mean by 'tag' here. An XML element or an attribute?

'display' is needed anyway to control the layout, for example it controls if the
element is a block element (paragraph) or a inline element (character sequence)
or none (nonvisible elements).

> Direct formatting would be translated to CSS attributes
> or to a limited set of Scribus specific custom attributes.
> Unknown attributes would be preserved by Scribus. Element names would be
> meaningless to Scribus, since anything Scribus needs to know will be in the
> attributes.

Sounds good.

Another thought just occurred to me: SVG is also XML. It makes my head
hurt to think about applying CSS to SVG, though I can't think of any
technical reason you wouldn't be able to.

Using SVG this way would be quite unsatisfactory for the user :-).
Textframes primarily display character content, the elements are just for
formatting and grouping. OTOH in SVG most content is defined by elements
without any character content. Vector data is not text data.

/Andreas

[Steve Herrick]

On Mon, Sep 29, 2008 at 6:23 AM, avox <avox@...> wrote:

> Not sure what you mean by 'tag' here. An XML element or an attribute?

I was thinking an element.

> 'display' is needed anyway to control the layout, for example it controls if
> the
> element is a block element (paragraph) or a inline element (character
> sequence)
> or none (nonvisible elements).

Hm, true. My XML is rather rusty...

> Using SVG this way would be quite unsatisfactory for the user :-).
> Textframes primarily display character content, the elements are just for
> formatting and grouping. OTOH in SVG most content is defined by elements
> without any character content. Vector data is not text data.

That's generally true, though I've made a number of half-page and
full-page files in Inkscape for use in a Scribus file (or at work,
Illustrator and InDesign), and they included full paragraphs of text
in SVG.
--
Steve Herrick

Maybe we can eventually make language a complete impediment to understanding.
- Hobbes the tiger

_______________________________________________
scribus mailing list
scribus@...
http://lists.scribus.info/mailman/listinfo/scribus