[Scribus] Comment about object tag names and xml file format
Tim Boyden
tboyden
Wed Feb 27 03:55:47 CET 2008
I've done some work with SVG and you can apply RGB or Hex color values
for elements so I don't think the 8-bit color is an issue anymore if it
ever was. Basically any color you can apply in Illustrator, InDesign or
Photoshop can be applied to an SVG graphic by looking up the Hex code in
the color palette.
I think the font issues are probably related to the coding of the
Scribus SVG export feature. As long as the font file is available to the
SVG file, any glyph within that font should be available to display in
the SVG file. This link gives good information on how SVG handles text:
http://www.informit.com/articles/article.aspx?p=31799&seqNum=2
Now that all being said, SVG currently relies on browser plug-ins to
display on the web, so depending on how the plug-in was implemented, not
all the features of a SVG document may be displayable. That shouldn't be
an issue when using it as a document format for a page layout
application such as Scribus, as long as Scribus developers implemented
all of the features of the SVG XML specification.
This is the truncated source code from a Scribus 1.3.5 SVG file:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink" width="612pt" height="264pt"
viewBox="0 0 612 264" version="1.1">
<g id="surface0">
<image width="2550" height="1100"
transform="matrix(0.24,0,0,0.24,0,0)" xlink:href="data:image/png;base64,
<insert binary data here>/
>
</g>
</svg>
As opposed to the same SVG file from Scribus 1.3.3.x:
<?xml version="1.0" encoding="UTF-8"?>
<svg width="612pt" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg" height="263.52pt" viewBox="0 0 612
263.52" >
<g transform="translate(27, 234)" >
<text>
<tspan x="0" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >A</tspan>
<tspan x="6.165" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >D</tspan>
<tspan x="12.834" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >V</tspan>
<tspan x="18.504" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >E</tspan>
<tspan x="24.336" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >R</tspan>
<tspan x="30.834" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >T</tspan>
<tspan x="36.333" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >I</tspan>
<tspan x="38.988" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >S</tspan>
<tspan x="44.829" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >E</tspan>
<tspan x="50.661" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" > </tspan>
<tspan x="53.163" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >W</tspan>
<tspan x="61.659" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >I</tspan>
<tspan x="64.314" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >T</tspan>
<tspan x="69.813" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >H</tspan>
<tspan x="76.482" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" > </tspan>
<tspan x="78.984" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >S</tspan>
<tspan x="84.825" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >U</tspan>
<tspan x="91.494" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >P</tspan>
<tspan x="97.497" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >E</tspan>
<tspan x="103.329" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >R</tspan>
<tspan x="109.827" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >C</tspan>
<tspan x="116.496" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >O</tspan>
<tspan x="123.498" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >U</tspan>
<tspan x="130.167" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >P</tspan>
<tspan x="136.17" y="7.579" fill="#161413" stroke="none"
font-family="Helvetica Neue LT Std" font-size="9" >S</tspan>
</text>
<path style="fill:none; stroke:none; stroke-width:1;
stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"
d="M0 0 C0 0 216 0 216 0 C216 0 216 11.52 216 11.52 C216 11.52 0 11.52 0
11.52 C0 11.52 0 0 0 0 Z" />
</g>
</svg>
In the Scribus 1.3.5 version of the SVG export, the document is embedded
as a PNG graphic which is a rasterized graphic format. This goes against
the purpose of SVG - Scalable Vector Graphics and as a result is not
freely scalable. That being said, is that important as far as a DTP app
goes? No it's not, as raster graphics like TIFF and JPEG are a
necessity, but by embedding the entire document rather than just the
individual raster images as binary data, prevents one from manipulating
the document later on as we've discussed with 3rd party tools.
Being able to modify a document dynamically via a web form for variable
data purposes or as a web to print solution would be extremely useful,
something Adobe charges a lot of dough for to be able to do with
InDesign documents with their InDesign server product. With SVG, every
element could be a clickable element in a web page, that when clicked
could pop-up a window that allows you to change the text, or text style
or swap the graphic for another from a graphic library. Very powerful
stuff!
I'll post some example SVG docs tomorrow that use complicated fonts as
an example of SVG's text handling skills...
-Tim
On Wed, 2008-02-27 at 10:39 +0900, Craig Ringer wrote:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
More information about the scribus
mailing list