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
