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.
