[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