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

[avox]

Hi Tim!

As Craig already pointed out, SVG 1.2 print would be a minimum to support
Scribus's color functions. In fact I've looked into the usability of SVG for
Scribus myself, but there are some problems, see below. It's also very
unlikely any application but Scribus could open such a file.


Tim Boyden wrote:
> 
> 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
> 

No, Craig was talking obout an object like an image or external graphics
which 
is visible on more than one page and might extend beyond the dimensions of
either
page.
This might be solvable by reusing the same object and place it twice on
different 
pages, but Scribus also supports objcts which are completely outside any
page.



> - 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
> 

Since Scribus has it's own layout algorithm, we need to specify the
position of each glyph separately. The current solution of using one
tspan per character is admittedly somewhat clumsy and will be
improved in a later version.



> - 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.
> 

Might be possible, but Scribus has lot's of attributes for any pageitem
which have no representation in SVG.
Even if it was possible to use SVG as Scribus's native fileformat, there
are advantages to be the owner of your fileformat. Scribus evolves
much faster than SVG standards and is far ahead in some areas. OTOH
there are some SVG features we don't want to implement. So instead of
using some strangely warped version of SVG it's much better to roll our
own fileformat.

Anyway, the XML format of 1.3.5 is just an intermediate format based
on the 1.3.3 format; and not what we plan for 1.4. 
Using standardized XML attributes is a good idea and we'll probably do
just that for "NAME" and some others.

/Andreas
-- 
View this message in context: http://www.nabble.com/Comment-about-object-tag-names-and-xml-file-format-tp15701418p15734920.html
Sent from the Scribus mailing list archive at Nabble.com.