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

[Craig Ringer]

Timothy Boyden wrote:
> I would like to see Scribus move to using an implementation of SVG as
> it's file format and I think there a lot of good reasons for doing so -
> industry support, extensibility, numerous applications to manipulate it,
> it's fully documented, etc...
>   
Do you feel strongly enough about this to come up with a summary of how 
most existing Scribus features can be mapped to SVG >= 1.2 ?

- Multiple pages of different sizes etc
- Objects spanning across pages
- Automatic text flow and linked frames
- Columns
- Arbitrary shaped text areas
- Separate text flow outline from object outline/clipping path
- Layer blending modes
- manual kerning, pair kerning, etc
- All the other text positioning and styling features
- Arbitrary referenced/embedded objects (PDF, etc)

Personally if you can provide a convincing argument that the required 
features can be supported in a sane way and with a minimum of 
nonstandard extensions I think it'd be pretty cool. I don't rate your 
chances of convincing anybody with the time and interest to do the 
coding, though, as the conversion would probably land up being closer to 
a rewrite of large parts of the Scribus core than you might expect.

 From what you've said below I wouldn't be too surprised if SVG was in 
fact capable of all the above and more. I suspect I've underrated it 
because all the major public implementations are so horribly limited.

The existing Scribus format is very much like a dump of Scribus's 
internal data structures, just written out in XML instead of a binary 
format. (This is kind of mean, but it's a little like Office Open XML, 
in that it's XML in syntax but not really in spirit or utility). Using 
something else would require huge changes and a large amount more 
abstraction away from the file format. That'd almost certainly be a good 
thing, but it'd be a truly huge project.

Personally, I'd love to see a DTP app that used PDF as its native 
format. PDF mixes text, vector artwork, and raster artwork seamlessly. 
It's is much faster than XML-based formats, it's standard, it's easily 
appended to without rewriting, absolutely huge documents are quite 
practical and fast, it can embed arbitrary objects or link to external 
ones, other tools understand it, and it's extremely extensible. It 
supports commenting, articles, annotations, links, etc etc internally. 
It plays well with job specs like JDF. A PDF-native DTP app would be 
eminently possible, though it'd probably have to disable a lot of 
features when faced with PDF content it hadn't generated or that'd been 
modified by an external tool. This isn't even worth laughing at, let 
alone considering, as an idea for Scribus, though.

> As you can see SVG (the original not just the newer SVG Print extension)
> was designed for print purposes. It only uses sRGB as a fallback when
> displaying the SVG document on screen. The newer SVG Print 1.2
> specification is meant to allow the SVG document type to integrate with
> other print industry standards such as JDF.
>
>   
OK, that does sound interesting. It seems I've underrated SVG based on 
what I've seen of tools that use it and comments on problems with its 
text model etc.
> Basically the W3C is doing all the work to develop an open, well
> documented format, that is designed for print. It's just a matter of
> someone picking up from there and developing the ultimate DTP
> application to take advantage of that. Unfortunately that's not me, I am
> not a programmer. But if such a tool was available, I would influence my
> peers to use it and would contribute in any way that I could whether it
> was testing, documenting, or providing support.
>
>   
Rather than basically rewriting Scribus to use SVG, I suspect it'd be 
much more practical to extend Inkscape with DTP features. There's 
already a little movement in that direction with things like work on ICC 
based colour support. I'm pretty sure it'd be a vastly smaller and more 
practical job - at only truly huge instead of nigh-impossible.

--
Craig Riner