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
