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

[Timothy Boyden]

I'll take a shot at your requirements with some Google search results.
I'm not saying it's easy or that it wouldn't be a lot of work, but it is
possible:

- Multiple pages of different sizes etc
	* Handled by SVG page sets:
http://www.w3.org/TR/2004/WD-SVG12-20041027/multipage.html
- Objects spanning across pages
	* Handled by defining a graphic element in the global scope of a
page set
	* Could also be possibly implemented as a flowRegion element:
http://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html
- Automatic text flow and linked frames
	* Handled by a flowRegion element
- Columns
	* Could be implemented as multiple column shaped flowRegions
- Arbitrary shaped text areas
	* Not quite sure what you mean by this, but text can be applied
to any shape path: http://www.w3.org/TR/SVG/text.html#TextPathElement
- Separate text flow outline from object outline/clipping path
	* I would need an visual example of this to understand the
concept, but sounds like a combination of a textpath and flow region
element
- Layer blending modes
	* This should be handled by the SVG Filters spec:
http://www.w3.org/TR/SVGFilterPrimer12/ 
- manual kerning, pair kerning, etc
	* Kern elements, part of the font spec:
http://www.w3.org/TR/SVG11/fonts.html#KernElements
- All the other text positioning and styling features
	* Text spec reference: http://www.w3.org/TR/SVG/text.html
- Arbitrary referenced/embedded objects (PDF, etc)
 	* Handled by the xlink attribute of an image (or other object
type) element: http://www.w3.org/TR/SVG11/linking.html
		Scribus 1.3.5 uses this currently to embed a PNG
formatted image of the document in an exported SVG file.

-----Original Message-----
From: scribus-bounces at nashi.altmuehlnet.de
[mailto:scribus-bounces at nashi.altmuehlnet.de] On Behalf Of Craig Ringer
Sent: Wednesday, February 27, 2008 12:58 PM
To: scribus at nashi.altmuehlnet.de
Cc: scribus at kirsche.altmuehlnet.de
Subject: Re: [Scribus] Comment about object tag names and xml file
format

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
_______________________________________________
Scribus mailing list
Scribus at nashi.altmuehlnet.de
http://nashi.altmuehlnet.de/mailman/listinfo/scribus