[CREATE] SVG Import/Export (was Re: Create projects)

Christoph Schäfer christoph-schaefer at gmx.de
Thu Oct 8 22:13:03 PDT 2009


Am Freitag, 9. Oktober 2009 05:34:08 schrieb Yuval Levy:
> Danke fuer die Erklaerungen, Christoph.

Aber gerne doch :)

>
> Christoph Schäfer wrote:
> > Scribus is primarily designed for creating print-ready PDF and PostScript
> > files, which means, among others, that it doesn't have to support the
> > whole SVG standard (e.g. the animation part).
>
> this explains to me why some of the features (e.g. animations) are not
> editable in Scribus.
>
> wouldn't it be possible to simply "hide" those parts of the document
> that can't be edited (e.g. for an animation, just show the first frame,
> or, better, show the one single frame specified by the animation program
> as being the "master frame" - may require some changes in the specs
> and/or in the animation program, but will result in better
> interoperability). But keep them in the file, i.e. load and save them
> along.

It isn't and probably never will be, as SVG data (just like any other imported 
vector data) are converted to the Scribus graphics model, which is the only 
way to make sure that we can export to PDF/PS reliably (and as of now there 
are still some corner cases that don't work 100% correctly).

>
> I understand the devil lies in the detail, and the difference of purpose
>   of the different tools has consequences on the support of file formats
> and functionalities. And I am sure you thought of such strategies as
> "graceful degradation" in this context.

One thing one has to be aware of is that at least in terms of the creative 
process aimed at printed output, DTP is at the end of the creative "food 
chain". In other words, a DTP program needs to be able to _import_ bitmap and 
vector files, as well as (formatted) text, including text styles. It also has 
to provide a wide set of typographical features. At the same time, a good DTP 
program must be able to hand over reliable _output_ to a printing company. 
This includes a more than robust font support (including quality checks) and 
also colour management.

I'm not sure if I was able to demonstrate the wide range of issues we're 
facing, but please believe me that full SVG support is not on top of the list 
of priorities, especially since SVG is everything but an established standard 
for vector files in common print workflows. Full support of advanced OpenType 
features, support for complex Asian scripts and many more requirements of 
professional typesetting are much more important, not to mention the next 
generation of colour managment and export to more PDF/X versions. And since 
Scribus is cross-platform, we also have to deal with legacy formats like PICT 
for Mac OS (done) or MET for OS/2 and eComStation (not yet done).

>
> > Go ask Quark or Corel for specs of their file formats ;)
>
> or Canon, Nikon, SONY. Nobody's perfect, but we can try to strive to be
> slightly better than the pack.

Of course, and we have to be grateful to those who take the time to 
reverse-engineer the formats whose specs aren't available!

>
> Thanks again for the explanation and have a good weekend.

Same to you!

Christoph


More information about the CREATE mailing list