There has been a user complaining in several reports in the bug tracker about the Inkscape SVG giving away more information than he would like and the Plain SVG not including as much information as needed and I think it raises various questions.
How plain should Plain SVG be? Should it include metadata? (Based on SVG having a metadata tag I think it probably should include some form of metadata)
Inkscape has as a stated goal conforming closely to the SVG specificiation but inlcudes a whole lot of information in the Sodipodi and Inkscape namespace. The stock response is this someone helps compatability with Sodipodi but is this really true anymore? Surely some of it like including the sodipodi version number is just as likely to confuse the matter?
The old sodipodi docbase attribute seem like it could have been useful to avoid link breakage if a the drawing file has been moved around. Is this actually doing anything useful? Users have expressed privacy concerns as it effectively embeds the path to their homedirectory including username in every document.
It seems there must be a way to express a lot more of the old sodipodi metadata using SVG (or Dublin Core or other parts of XMP we are already using). If the old timers ;) could clarify if any of this cruft is useful anymore it would make it easier to write clear bug reports and break into much smaller parts which bits might be replaced (hopefully making the same information available in Plain SVG where possible).
Given the importance of the OpenDocument standard and how they are essentially using their XML namespaces to fill out gaps not covered by SVG might it be better to include their namespaces rather than adding any more to the Inkscape (or Sodipodi) namespace?
I hope people can clarify what old bits are still needed and what could potentially be cleaned up and replaced with standard SVG. With a bit more information hopefully I will be able to add useful comments to bug reports and perhaps add some goals for clearing out the old non-standard cruft somewhere on the Roadmap.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Oct 24, 2005, at 7:45 AM, Alan Horkan wrote:
Given the importance of the OpenDocument standard and how they are essentially using their XML namespaces to fill out gaps not covered by SVG might it be better to include their namespaces rather than adding any more to the Inkscape (or Sodipodi) namespace?
Before going into this more, you should look over how they're doing things in more detail.
They were actually more of using other namespaces mixed together willy-nilly to retool their existing OpenOffice format. They were initialy very far from SVG compliant, I believe they have improved things somewhat, but not in the "we're trying to be standard" kinda way, but more in a "here are our internal guts, let's tag them with familiar sounding names" way.
Skimming the list's archive might give you a bit of a jumping off point to look from.
On 10/24/05, Alan Horkan <horkana@...44...> wrote:
Inkscape has as a stated goal conforming closely to the SVG specificiation but inlcudes a whole lot of information in the Sodipodi and Inkscape namespace.
There's no "but" here, as I recently wrote here. Including other namespaces does not make our SVG invalid or non-compliant.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, 24 Oct 2005, bulia byak wrote:
Date: Mon, 24 Oct 2005 14:48:54 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] SVG standards and Sodipodi cruft
On 10/24/05, Alan Horkan <horkana@...44...> wrote:
Inkscape has as a stated goal conforming closely to the SVG specificiation but inlcudes a whole lot of information in the Sodipodi and Inkscape namespace.
There's no "but" here, as I recently wrote here. Including other namespaces does not make our SVG invalid or non-compliant.
Closely conforming would imply using the SVG specification where possible as opposed to Sodipodi using it only when convenient.
I'll take it as a good sign that you are not arguing in favour of more sodipodi and inkscape markup.
- Alan
On 10/24/05, Alan Horkan <horkana@...44...> wrote:
I'll take it as a good sign that you are not arguing in favour of more sodipodi and inkscape markup.
Of course I'm not arguing for or against it in general. It all depends on what you want to express. Whenever there's a standard facility we should use it, otherwise we should invent our own.
As for sodipodi:docbase, I agree it may be a good idea to remove it, but we need to check first where and when it's used in the code, if at all.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Alan Horkan wrote:
On Mon, 24 Oct 2005, bulia byak wrote:
Date: Mon, 24 Oct 2005 14:48:54 -0300 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] SVG standards and Sodipodi cruft
On 10/24/05, Alan Horkan <horkana@...44...> wrote:
Inkscape has as a stated goal conforming closely to the SVG specificiation but inlcudes a whole lot of information in the Sodipodi and Inkscape namespace.
There's no "but" here, as I recently wrote here. Including other namespaces does not make our SVG invalid or non-compliant.
Closely conforming would imply using the SVG specification where possible as opposed to Sodipodi using it only when convenient.
I'll take it as a good sign that you are not arguing in favour of more sodipodi and inkscape markup.
- Alan
Hopefully, all that the extra namespaced data that is provided is of use not for rendering, but for editing. Inkscape would only break the spec if its extra namespace allows for different rendering than would occur for a file with only svg: and xlink: namespaces.
Extra namespaces by themselves would only break a parser limited to XML 1.0, which is flat. I don't think that any such parsers are used much anymore. But the rule for 1.1+ is to ignore anything for which you are not looking.
All "plain" should do is remove the editing-oriented payload.
Bob
On Mon, 24 Oct 2005, rjamison wrote:
Alan Horkan wrote:
On Mon, 24 Oct 2005, bulia byak wrote:
On 10/24/05, Alan Horkan <horkana@...44...> wrote:
Inkscape has as a stated goal conforming closely to the SVG specificiation but inlcudes a whole lot of information in the Sodipodi and Inkscape namespace.
Closely conforming would imply using the SVG specification where possible as opposed to Sodipodi using it only when convenient.
All "plain" should do is remove the editing-oriented payload.
So is the metadata editing-oriented?
the tracker request to remove the sodipodi:docbase attribute https://sourceforge.net/tracker/index.php?func=detail&aid=1326232&gr...
As I said earlier I also wonder what else is actually needed, some of the Sodipodi namedview stuff seems like it could be expressed using a standard SVG viewBox.
Cascading style sheets had me wondering if a Layer could be expressed as a class of groups? Something like: <group id="Layer_1" class="layer"></group>
I suppose there are more creative ways to avoid using custom markup but I was hoping people might have a better idea of why the sodipodi or inkscape markup seemed necessary before I try and get rid of it.
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
Quoting Alan Horkan <horkana@...44...>:
Cascading style sheets had me wondering if a Layer could be expressed as a class of groups? Something like: <group id="Layer_1" class="layer"></group>
That would be a very poor use of CSS classes; among other things, it pollutes the CSS class namespace. It's not like there are any standard CSS attributes to associate with the desired behavior for layers, so it would also necessarily amount to a nonstandard extension of CSS. Unlike XML, CSS has no real "namespaces" facility for application-specific annotations.
There is no disadvantage to using attributes in a custom namespace to make non-presentational annotations to a conforming SVG document; that sort of thing is the express purpose for which the Namespaces in XML standard was introduced.
In fact, the alternative -- trying to co-opt "standard" facilities into representing things that the standard doesn't specify (for example, using a "magic" CSS class to denote editing behavior) -- frequently has very bad long-term consequences.
Trust me, we've thought this stuff through already. The only true issue here is whether or not a particular existing sodipodi-namespace (or even inkscape-namespace) attribute is still useful.
As far as I can tell, sodipodi:docbase can probably go (we need to keep the C++ field, but there's no reason to save it to the XML), but bulia is still in the process of verifying that before we actually remove it.
-mental
On Mon, 2005-10-24 at 15:47 -0400, mental@...3... wrote:
The only true issue here is whether or not a particular existing sodipodi-namespace (or even inkscape-namespace) attribute is still useful.
Well, actually no, there's also the issue of whether to preserve metadata in "plain SVG" which you pointed out.
My feeling is anything inside the metadata tag should always be kept in "plain SVG", although that will require some architectural changes.
-mental
mental@...3... wrote:
As far as I can tell, sodipodi:docbase can probably go (we need to keep the C++ field, but there's no reason to save it to the XML), but bulia is still in the process of verifying that before we actually remove it.
I'm not an experienced Inkscape user, let alone a developer, so please forgive if I'm saying something stupid, but isn't sodipodi:docbase needed for referencing external images?
I noticed that Inkscape stores absolute pathnames of images. But when I copy an SVG and all images I used within it to another computer with a completely different directory tree structure, it still works; therefore I came to the conclusion that Inkscape uses sodipodi:docbase and either sodipodi:absref or xlink:href to construct relative pathnames.
BTW, is there a better way to distribute an SVG with included images than creating a folder for each document and copying every image into that folder manually before including it into Inkscape? It's quite tedious to do this manually, and if you forget to do it, the recipient misses one or more images.
On 10/25/05, Roel Schroeven <rschroev_nospam_ml@...1051...> wrote:
BTW, is there a better way to distribute an SVG with included images than creating a folder for each document and copying every image into that folder manually before including it into Inkscape? It's quite tedious to do this manually, and if you forget to do it, the recipient misses one or more images.
Yes, this feature is most well know as "Collect for output". All external files used are copied to a defined by user directory, including the project file, and all references to these files are changed to the new ones (it's implemented in Scribus, if you want to have your own personal experience how it works)
We discussed it a while ago (some time beginning of September, IIRC) and the common reaction was that it would be a very helpful feature.
Alexandre
Alexandre Prokoudine wrote:
On 10/25/05, Roel Schroeven <rschroev_nospam_ml@...1051...> wrote:
BTW, is there a better way to distribute an SVG with included images than creating a folder for each document and copying every image into that folder manually before including it into Inkscape? It's quite tedious to do this manually, and if you forget to do it, the recipient misses one or more images.
Yes, this feature is most well know as "Collect for output". All external files used are copied to a defined by user directory, including the project file, and all references to these files are changed to the new ones (it's implemented in Scribus, if you want to have your own personal experience how it works)
We discussed it a while ago (some time beginning of September, IIRC) and the common reaction was that it would be a very helpful feature.
That would be nice indeed, but until then I'll get by with using the script mentioned by Jon. Thanks for your response!
On Oct 25, 2005, at 6:42 AM, Roel Schroeven wrote:
BTW, is there a better way to distribute an SVG with included images than creating a folder for each document and copying every image into that folder manually before including it into Inkscape? It's quite tedious to do this manually, and if you forget to do it, the recipient misses one or more images.
There's a script that will embed all images directly in the SVG. The operation will probably be implemented as a built-in function at some point.
Jon A. Cruz wrote:
On Oct 25, 2005, at 6:42 AM, Roel Schroeven wrote:
BTW, is there a better way to distribute an SVG with included images than creating a folder for each document and copying every image into that folder manually before including it into Inkscape? It's quite tedious to do this manually, and if you forget to do it, the recipient misses one or more images.
There's a script that will embed all images directly in the SVG. The operation will probably be implemented as a built-in function at some point.
Aha, thank you.
The script states it only works for png and jpg, but from reading it I have the impression that the only thing needed to make it work for other image formats is to add detection for their magic numbers. Is that correct? If so, I can easily add support for bmp (my coworkers often use that format).
Roel Schroeven wrote:
The script states it only works for png and jpg, but from reading it I have the impression that the only thing needed to make it work for other image formats is to add detection for their magic numbers. Is that correct? If so, I can easily add support for bmp (my coworkers often use that format).
Well, kinda. The SVG spec only requires JPGs and PNGs to be read from a document. It is likely that the resulting SVG won't be visible in some implementations. I think that Inkscape will still show them though.
http://www.w3.org/TR/SVG/struct.html#ImageElement
--Ted
On 10/24/05, rjamison <rwjj@...127...> wrote:
Hopefully, all that the extra namespaced data that is provided is of use not for rendering, but for editing. Inkscape would only break the spec if its extra namespace allows for different rendering than would occur for a file with only svg: and xlink: namespaces.
I would stress that this is not simply "hopefully", it's guaranteed per design. Any deviation from this is a bug.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
participants (9)
-
unknown＠example.com -
Alan Horkan -
Alexandre Prokoudine -
bulia byak -
Jon A. Cruz -
MenTaLguY -
rjamison -
Roel Schroeven -
Ted Gould