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

[Craig Ringer]

Tim Boyden wrote:
> In the end I suppose it doesn't matter how it gets into the object
> element in the file format, however if we go by standard tagging
> conventions, it should be applied to the "id" or "name" attributes and
> anything is better than the current status where the tag isn't even in
> the file which makes it a useless feature at present.

I personally tend to agree with you on this; it'd be nice to be able to
 use a standard tag name locate an element by the same name that is seen
by the user in the UI.

Scribus enforces uniqueness for object names, so I'm not sure why the id
attribute could not be used if it'd make the format easier to work with
in external document processing tools.

> I was going to suggest implementing it in a way similar to SVG (which I
> think Scribus should be using an extended version of for it's file
> format anyways).

It does sound nice, but it really would not work out. SVG is not
designed for page layout and typography, and it shows. The text model is
primitive, for one thing. Current versions of SVG also lack support for
colours other than 8-bit RGB and all sorts of other basic things, though
some work is in progress in that area.

> But to my dismay it appears the SVG export feature of
> Scribus as been degraded to embedding a rasterized PNG version of the
> document into the SVG file as opposed to converting the Scribus
> document's elements into SVG vector elements. The feature was much
> better in Scribus 1.3.3.x where it did just that. The 1.3.3.x SVG export
> feature just needed to have the text elements fixed so it didn't break
> up the text elements into individual characters.

Because of how SVG text works it is my understanding that this just
could not be done. There's no way to specify the same level of
typographic control that you get in Scribus, so Scribus has to manually
position characters.

I didn't know about the conversion to raster, though, and I'm very
surprised by that.

It'd be nice if there _was_ a standard format that was suitable for DTP,
but there really isn't. I've been curious about the possibility of
adopting the ODF container format (as distinct from the more specific
ODT format for Writer), and using existing ODF/ODT conventions where
appropriate but in a new and incompatible ODF-for-DTP flavour (as .odt
is ODF-for-wordprocessing, and so on). However, when the use of ODF was
discussed as part of the new format planning this was rejected. I don't
have technical details as to why, and I'm not even sure that the
rejection wasn't really for using Writer-style ODT (which would be
unworkable and make little sense anyway) rather than the general ODF
structure and container.

On the other hand, ODF is:

- Not significantly extensible (even Microsoft did a better job than
OASSIS on this point);

- Not supported by any portable, toolkit-independent format libraries;

- A bit of a pain to work with in XML document processing applications
because of the zip container; and

- there's no existing ODF flavour for DTP defined.

So I'm not really sure how useful using ODF would really be. It'd still
be an, at least initially, Scribus-only format.

> As for my signature, I apologize to the list etiquette Nazis, I was in a
> rush to send the e-mail as I was running out the door and forgot to turn
> it off for posting to the group

Personally I think such signatures are at best meaningless and usually
absurd, whether on mailing lists or otherwise. Sometimes they're forced
on people by overzealous (and underinformed) corporate legal types with
a control bent, but I'm very surprised you're using one by choice.

What will it achieve? Does it have any legal significance or value?

--
Craig Ringer