filter for inkscape and OpenDocument
Heya,
I just read your nice interview at groklaw (http://www.groklaw.net/article.php?story=20050130002908154). First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format. I see in your interview you note that there is a needed filter for Inkscape, but it is not clarified what this means. I'm cc'ing the Inkscape development list about this. I just wonder how this OpenDocument format (the newly standardized open office xml format) relates to Inkscape and what you are asking to be done.
Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be difficult. But, what about OpenOffice support for the SVG file format?
Please copy me and/or the Inkscape-devel list and I will make sure they get the response. Or, please reply to me and the list if you are on Inkscape's list.
Thanks, Jon
Jon Phillips wrote:
Heya,
I just read your nice interview at groklaw (http://www.groklaw.net/article.php?story=20050130002908154). First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format. I see in your interview you note that there is a needed filter for Inkscape, but it is not clarified what this means. I'm cc'ing the Inkscape development list about this. I just wonder how this OpenDocument format (the newly standardized open office xml format) relates to Inkscape and what you are asking to be done.
first: the OpenDocument format is something like 99% identical with the old OpenOffice.org format.
i'm not sure what was Daniel idea, but i'll speculate: OpenOffice.org Draw files are XML and very similar with SVG, probably this is why Daniel expect such import filter to be not to hard to develop.
BTW, Daniel, you forgot to mention in the Groklaw article that OpenOffice.org file format is supported also by Scribus: http://www.scribus.org.uk/modules.php?op=modload&name=News&file=arti...
Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be
i think he want the other way around: Inkscape to be able to open OpenDocument files (probably the ones made in OOo Draw)
difficult. But, what about OpenOffice support for the SVG file format?
OpenOffice.org can *export* in SVG. for import, some work (using a xslt filter) is done here: http://qa.openoffice.org/issues/show_bug.cgi?id=2497
On Mon, 31 Jan 2005, Nicu Buculei wrote:
Jon Phillips wrote:
Heya,
I just read your nice interview at groklaw (http://www.groklaw.net/article.php?story=20050130002908154). First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format. I see in your interview you note that there is a needed filter for Inkscape, but it is not clarified what this means. I'm cc'ing the Inkscape development list about this. I just wonder how this OpenDocument format (the newly standardized open office xml format) relates to Inkscape and what you are asking to be done.
first: the OpenDocument format is something like 99% identical with the old OpenOffice.org format.
i'm not sure what was Daniel idea, but i'll speculate: OpenOffice.org Draw files are XML and very similar with SVG, probably this is why Daniel expect such import filter to be not to hard to develop.
BTW, Daniel, you forgot to mention in the Groklaw article that OpenOffice.org file format is supported also by Scribus: http://www.scribus.org.uk/modules.php?op=modload&name=News&file=arti...
Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be
i think he want the other way around: Inkscape to be able to open OpenDocument files (probably the ones made in OOo Draw)
I've investigated and experimented with creating a converter that would enable support for the OpenOffice format in Inkscape. The code appears to already exist in OpenOffice, although it would be some trouble to extricate. However, this problem could be easily addressed if OpenOffice could provide a cmdline script to run their SVG export extension. I.e., a sxd2svg. Given that, we could easily add support for this file format to Inkscape.
Bryce
Bryce Harrington wrote:
I've investigated and experimented with creating a converter that would enable support for the OpenOffice format in Inkscape. The code appears to already exist in OpenOffice, although it would be some trouble to extricate. However, this problem could be easily addressed if OpenOffice could provide a cmdline script to run their SVG export extension. I.e., a sxd2svg. Given that, we could easily add support for this file format to Inkscape.
as a disadvantage, this will require a full working copy of OpenOffice.org installed. i know Inkscape use the same method for importing other file types, but if we consider OpenOffice as a dependency, this is a *huge* one.
On Mon, 31 Jan 2005, Nicu Buculei wrote:
Bryce Harrington wrote:
I've investigated and experimented with creating a converter that would enable support for the OpenOffice format in Inkscape. The code appears to already exist in OpenOffice, although it would be some trouble to extricate. However, this problem could be easily addressed if OpenOffice could provide a cmdline script to run their SVG export extension. I.e., a sxd2svg. Given that, we could easily add support for this file format to Inkscape.
as a disadvantage, this will require a full working copy of OpenOffice.org installed.
Not necessarily. The svg export extension is packaged as an .so. ldd reports that it has some dependencies, some of which may be part of OOo, but if it were necessary to distribute this independently of OOo, I think there's an outside possibility that it could.
i know Inkscape use the same method for importing other file types, but if we consider OpenOffice as a dependency, this is a *huge* one.
It depends. It is only a dependency if someone wishes to import this file format. Presumably, if they did, they are using OpenOffice and will have it installed. So yes it is a large dependency size-wise, but it's much more likely to be present on the user's system than some of the other things we depend on.
Also note that Inkscape will install even if some of its expected extensions aren't installed. It'll warn the user and add an error message to the extensions error log, but will otherwise run fine.
In any case, the point is not that this is a perfect solution but that it is one that could be obtained with a minimal amount of effort.
I think a poor solution would be to expect that someone will write a new OODraw-to-svg converter. If someone is gung-ho to do that, more power to them, but if not, it duplicates effort that would probably better spent at helping OpenOffice gain an SVG importer, too. ;-)
Bryce
Nicu Buculei wrote:
However, this problem could be easily addressed if OpenOffice could provide a cmdline script to run their SVG export extension. I.e., a sxd2svg. Given that, we could easily add support for this file format to Inkscape.
as a disadvantage, this will require a full working copy of OpenOffice.org installed. i know Inkscape use the same method for importing other file types, but if we consider OpenOffice as a dependency, this is a *huge* one.
Wait people, the article was about the OpenDocument format, not OOo.
They are different animals. And OpenDocument woudl be hurt a lot if people start associating it with OpenOffice.org. That's part of the reasonf or the name change. OpenDocument is a separate thing, independent of OOo, and bigger than OOo or KDE or any current supporter. Yes, the OOo format was used as a starting point for OpenDocument, but OpenDocument didn't stay there. I has been expanded, modified and edited with the goal of being a neutral, extensive format that different applications can support.
Cheers,
On Mon, 31 Jan 2005, Daniel Carrera wrote:
Wait people, the article was about the OpenDocument format, not OOo.
They are different animals. And OpenDocument woudl be hurt a lot if people start associating it with OpenOffice.org. That's part of the reasonf or the name change. OpenDocument is a separate thing, independent of OOo, and bigger than OOo or KDE or any current supporter. Yes, the OOo format was used as a starting point for OpenDocument, but OpenDocument didn't stay there. I has been expanded, modified and edited with the goal of being a neutral, extensive format that different applications can support.
Ah, thanks for the correction. You can see the point of confusion though, in that something to do with office document file formats that is prefixed with 'Open' could easily be assumed to be a subset of OpenOffice.org. You may need to be reminding people about this for some time to come...
Bryce
Bryce Harrington wrote:
Ah, thanks for the correction. You can see the point of confusion though, in that something to do with office document file formats that is prefixed with 'Open' could easily be assumed to be a subset of OpenOffice.org. You may need to be reminding people about this for some time to come...
Yes, I totally see that. But OASIS was understandably reluctant to drop the word "Open" because it's such a powerful word. Especially at this time in history.
Like you said, I'll need to be reminding people for some time to come. :-)
Cheers,
On Mon, Jan 31, 2005 at 09:38:24AM +0200, Nicu Buculei wrote:
i'm not sure what was Daniel idea, but i'll speculate: OpenOffice.org Draw files are XML and very similar with SVG, probably this is why Daniel expect such import filter to be not to hard to develop.
The http://www.groklaw.net/article.php?story=20050130002908154 article says "OpenDocument had [prior to submission to TAC] [the advantage of] [r]euse of existing open standards when possible (SVG, [...])."
Is this correct?
Later, the article says "Enhancements such as XForms, SVG, and SMiL were needed to meet the `custom-defined schema' requirement."
Does this mean that OpenDocument supports both SVG and this strange OpenOffice.org Draw format? Why the duplication?
pjrm.
On Mon, 31 Jan 2005 19:02:16 +1100, Peter Moulder <Peter.Moulder@...38...> wrote:
On Mon, Jan 31, 2005 at 09:38:24AM +0200, Nicu Buculei wrote:
i'm not sure what was Daniel idea, but i'll speculate: OpenOffice.org Draw files are XML and very similar with SVG, probably this is why Daniel expect such import filter to be not to hard to develop.
The http://www.groklaw.net/article.php?story=20050130002908154 article says "OpenDocument had [prior to submission to TAC] [the advantage of] [r]euse of existing open standards when possible (SVG, [...])."
Is this correct?
IIRC, OO.o is using SVG namespaces for everything images/paths/vector related. That's it.
Alexandre
Peter Moulder wrote:
The http://www.groklaw.net/article.php?story=20050130002908154 article says "OpenDocument had [prior to submission to TAC] [the advantage of] [r]euse of existing open standards when possible (SVG, [...])."
Is this correct?
Later, the article says "Enhancements such as XForms, SVG, and SMiL were needed to meet the `custom-defined schema' requirement."
Does this mean that OpenDocument supports both SVG and this strange OpenOffice.org Draw format? Why the duplication?
OpenDocument is not attached to OOo. OpenDocument does not include the old OOoDraw format, but it has its own format which is similar, and was inspired by the old format.
My understanding (I'm no expert) is that OpenDocument uses only one format for images, but they regularly copied SVG attributes, using an svg: namespace. For example, here is a rectangle:
<draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="7.62cm" svg:height="5.715cm" svg:x="8.89cm" svg:y="9.525cm">
So it includes SVG attributes and non-SVG ones.
Cheers,
Quoting Daniel Carrera <dcarrera@...674...>:
My understanding (I'm no expert) is that OpenDocument uses only one format for images, but they regularly copied SVG attributes, using an svg: namespace. For example, here is a rectangle:
<draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="7.62cm" svg:height="5.715cm" svg:x="8.89cm" svg:y="9.525cm">
Ugh, I hope that's not the way it's actually done.
Most SVG attributes have no meaning in isolation; it's the elements they're attached to that give them meaning (by definition -- most SVG attributes live in per-element-type partitions, not the global attribute partition).
Actually, since SVG width/height/etc attributes live in per-element-type partitions, it's probably also improper to be inventing "SVG" attribtues in the global attribute partition like that...
-mental
mental@...3... wrote:
<draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="7.62cm" svg:height="5.715cm" svg:x="8.89cm" svg:y="9.525cm">
Ugh, I hope that's not the way it's actually done.
Most SVG attributes have no meaning in isolation; it's the elements they're attached to that give them meaning (by definition -- most SVG attributes live in per-element-type partitions, not the global attribute partition).
But those are not global. That tag only refers to one element, one rectagle. A different rectangle would have different properties.
Cheers,
Quoting Daniel Carrera <dcarrera@...674...>:
mental@...3... wrote:
<draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="7.62cm" svg:height="5.715cm" svg:x="8.89cm" svg:y="9.525cm">
Ugh, I hope that's not the way it's actually done.
Most SVG attributes have no meaning in isolation; it's the elements they're attached to that give them meaning (by definition -- most SVG attributes live in per-element-type partitions, not the global attribute partition).
But those are not global. That tag only refers to one element, one rectagle. A different rectangle would have different properties.
This has to do with the distinctness of attribute names, not their values. Please see Appendix A of the "Namespaces in XML" recommendation[1] (sections 2 and 3 in particular).
In the expanded name notation offered there, the name of the "real" SVG width attribute (for rectangles only) would be:
<ExpAName name='width' eltype="rect" elns="http://www.w3.org/2000/svg"/>
Whereas your example above "invents" an attribute not described in the SVG specification with the following expanded name:
<ExpAName name='width' ns="http://www.w3.org/2000/svg"/>
In other words, the attribute named "svg:width" isn't meaningful in SVG terms, and probably shouldn't have been put in the SVG namespace since the SVG standard does not define it.
I am hoping your example represented a misunderstanding of the OpenDocument specification, rather than a pervasive misunderstanding of XML namespaces in OpenDocument itself[2]...
-mental
[1] http://www.w3.org/TR/REC-xml-names/#ns-breakdown
Admittedly, the appendices aren't normative, but it offers the conceptual basis for the treatment of attributes in section 5.2 of the specification, which is normative.
[2] Or I hope that my understanding of XML namespaces is incorrect. Otherwise, I'm concerned that if OpenDocument uses namespaces in non-conformant ways and becomes widely adopted, it'll force weird XML processing hacks on everybody, not to mention setting a very bad example for standards-compliance.
mental@...3... wrote:
This has to do with the distinctness of attribute names, not their values. Please see Appendix A of the "Namespaces in XML" recommendation[1] (sections 2 and 3 in particular).
I think I understand.
I am hoping your example represented a misunderstanding of the OpenDocument specification, rather than a pervasive misunderstanding of XML namespaces in OpenDocument itself[2]...
Very likely. I am not very knowledgeable of the subject. Please don't take my comments as authoritative on OpenDocument, they are not. If I say something that just doesn't make sense, then I'm probably wrong. :-)
Question: Could it be that when the tag says:
<draw:rect ... svg:width="7.62cm" ... >
That 'svg:width' refers to:
<ExpAName name='width' eltype="rect" elns="http://www.w3.org/2000/svg"/>
And when it says:
<draw:ellipse ... svg:width="11.43cm" ... >
That 'svg:width' refers to:
<ExpAName name='width' eltype="ellipse" elns="http://www.w3.org/2000/svg"/>
Is this possible? I don't understand XML well enough to know this myself.
Cheers,
Quoting Daniel Carrera <dcarrera@...674...>:
Question: Could it be that when the tag says:
<draw:rect ... svg:width="7.62cm" ... >
That 'svg:width' refers to:
<ExpAName name='width' eltype="rect" elns="http://www.w3.org/2000/svg"/>
And when it says:
<draw:ellipse ... svg:width="11.43cm" ... >
That 'svg:width' refers to:
<ExpAName name='width' eltype="ellipse" elns="http://www.w3.org/2000/svg"/>
Afraid not. Attributes with those expanded names are only expressable on the svg:rect/ and svg:ellipse/ elements, respectively. In both examples above, the expanded attribute name is still:
<ExpAName name='width' ns="http://www.w3.org/2000/svg"/>
(which is not defined by the SVG specification anywhere)
In a nutshell:
If an attribute has a prefix, it's in a "public" namespace identified by the associated URI.
If an attribute doesn't have a prefix, it is (conceptually) in a "private" namespace specific to the expanded name (local name AND namespace together) of the element it is attached to[1].
SVG only defines a bunch of width attributes specific to their associated SVG elements, not a "public" svg:width attribute that can be put on any element[2].
If OpenDocument has in fact invented an svg:width attribute, they're putting non-standard extensions in the SVG namespace...
-mental
---
[1] The normative portion of the XML Namespaces recommendation only concerns itself with "public" namespaces; section 5.2 simply notes that attributes without prefixes have no (public) namespace.
The notion of element-specific namespaces is a concept introduced in the appendix to explain the intended interpretation of such namespaceless attributes.
[2] See XLink for an example of the opposite; XLink defines a bunch of "public" attributes (e.g. xlink:href) that can be put on any element (subject to the relevent schemas).
Quoting mental@...3...:
If OpenDocument has in fact invented an svg:width attribute, they're putting non-standard extensions in the SVG namespace...
I just broke down and looked at the OpenDocument standard. Yes, they are in fact doing this.
Unless this has been somehow okayed by the SVG WG, they are polluting the SVG namespace.
What are the appropriate channels to raise these concerns re: OpenDocument?
-mental
mental@...3... wrote:
I just broke down and looked at the OpenDocument standard. Yes, they are in fact doing this.
Unless this has been somehow okayed by the SVG WG, they are polluting the SVG namespace.
I am ignorant of this subject. I know that the OASIS TC is in contact the other standard groups (like XForms) so presumably SVG is one of them.
What are the appropriate channels to raise these concerns re: OpenDocument?
Go here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
You can leave a comment (click on "Send a comment"), join the TC, or simply just join their mailing list and participate in the discussion. The list is office@...676... but I can't figure out how to subscribe. I know you don't have to be a TC member to participate, as I know of other people who aren't members and still contribute there.
It is very important to get representation in the OASIS TC from multiple interested parties. The goal is to make a format acceptable to everyone, and that can only be done if people participate in the discussion.
Also, right now they wer working on the next version of the format. The one that'll meet all of the EU's requirements. And they are in the official "request for public comentary" period until Friday. So, the best time to raise a concern is right now. Send them a comment.
There is also a weekly conference call, general public invited, toll free number. It is every Monday from 4:00PM to 5:00PM UTC. Here are the details for the next one:
http://www.oasis-open.org/apps/group_public/event.php?event_id=6258&day=...
Cheers,
Daniel Carrera wrote:
mental@...3... wrote:
I just broke down and looked at the OpenDocument standard. Yes, they are in fact doing this.
Unless this has been somehow okayed by the SVG WG, they are polluting the SVG namespace.
I am ignorant of this subject. I know that the OASIS TC is in contact the other standard groups (like XForms) so presumably SVG is one of them.
What are the appropriate channels to raise these concerns re: OpenDocument?
Go here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
You can leave a comment (click on "Send a comment"), join the TC, or simply just join their mailing list and participate in the discussion. The list is office@...676... but I can't figure out how to subscribe. I know you don't have to be a TC member to participate, as I know of other people who aren't members and still contribute there.
It is very important to get representation in the OASIS TC from multiple interested parties. The goal is to make a format acceptable to everyone, and that can only be done if people participate in the discussion.
Also, right now they wer working on the next version of the format. The one that'll meet all of the EU's requirements. And they are in the official "request for public comentary" period until Friday. So, the best time to raise a concern is right now. Send them a comment.
There is also a weekly conference call, general public invited, toll free number. It is every Monday from 4:00PM to 5:00PM UTC. Here are the details for the next one:
http://www.oasis-open.org/apps/group_public/event.php?event_id=6258&day=...
Yeah, this should be brought up on the w3c www-svg list: http://www.w3.org/Mail/
Mental, since you did a bit of research on this, might you email them and tell them of the urgency of this as well. Although, with their current speed, I don't know how effective they are at commenting on that spec prior to FRIDAY.
Jon
Jon Phillips wrote:
Mental, since you did a bit of research on this, might you email them and tell them of the urgency of this as well. Although, with their current speed, I don't know how effective they are at commenting on that spec prior to FRIDAY.
Well, you are still allowed to comment after Friday. You can send comemnts anytime. I've seen comments by David Wheeler from last October (well outside the "request for public commentary" period). All I meant is that right now is a very good time to talk to them. But the OASIS TC is always open for public comments.
Cheers,
Jon Phillips wrote:
Daniel Carrera wrote:
mental@...3... wrote:
I just broke down and looked at the OpenDocument standard. Yes, they are in fact doing this.
Unless this has been somehow okayed by the SVG WG, they are polluting the SVG namespace.
I am ignorant of this subject. I know that the OASIS TC is in contact the other standard groups (like XForms) so presumably SVG is one of them.
What are the appropriate channels to raise these concerns re: OpenDocument?
Go here:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
You can leave a comment (click on "Send a comment"), join the TC, or simply just join their mailing list and participate in the discussion. The list is office@...676... but I can't figure out how to subscribe. I know you don't have to be a TC member to participate, as I know of other people who aren't members and still contribute there.
It is very important to get representation in the OASIS TC from multiple interested parties. The goal is to make a format acceptable to everyone, and that can only be done if people participate in the discussion.
Also, right now they wer working on the next version of the format. The one that'll meet all of the EU's requirements. And they are in the official "request for public comentary" period until Friday. So, the best time to raise a concern is right now. Send them a comment.
There is also a weekly conference call, general public invited, toll free number. It is every Monday from 4:00PM to 5:00PM UTC. Here are the details for the next one:
http://www.oasis-open.org/apps/group_public/event.php?event_id=6258&day=...
Yeah, this should be brought up on the w3c www-svg list: http://www.w3.org/Mail/
Mental, since you did a bit of research on this, might you email them and tell them of the urgency of this as well. Although, with their current speed, I don't know how effective they are at commenting on that spec prior to FRIDAY.
I went ahead and summarized the arguements and went ahead and posted to their list.
Jon
On Mon, Jan 31, 2005 at 12:49:14PM -0500, Daniel Carrera wrote:
Peter Moulder wrote:
The http://www.groklaw.net/article.php?story=20050130002908154 article says "OpenDocument had [prior to submission to TAC] [the advantage of] [r]euse of existing open standards when possible (SVG, [...])."
Is this correct?
Later, the article says "Enhancements such as XForms, SVG, and SMiL were needed to meet the `custom-defined schema' requirement."
Does this mean that OpenDocument supports both SVG and this strange OpenOffice.org Draw format? Why the duplication?
OpenDocument is not attached to OOo. OpenDocument does not include the old OOoDraw format, but it has its own format which is similar, and was inspired by the old format.
Does this mean that OpenDocument supports both SVG and some strange format unique to OpenDocument? Why the duplication?
My understanding (I'm no expert) is that OpenDocument uses only one format for images, but they regularly copied SVG attributes, using an svg: namespace. For example, here is a rectangle:
<draw:rect draw:style-name="gr1" draw:text-style-name="P1" draw:layer="layout" svg:width="7.62cm" svg:height="5.715cm" svg:x="8.89cm" svg:y="9.525cm">
So it includes SVG attributes and non-SVG ones.
Support for this format would be much better if it maximized its use of SVG such that the many existing SVG applications could at least render it. E.g. the above would become
<svg:rect class="gr1 P1" draw:layer="layout" width="7.62cm" height="5.715cm" x="8.89cm" y="9.525cm" />
where only the `draw:layer' part isn't in SVG; note that this part isn't relevant to rendering the document[*1], and isn't necessary even for editing the document.
[*1] If OpenDocument layers can express "don't render any of the objects in layer `foo'", then have a stylesheet rule [layer=foo] { display:none }
pjrm.
Peter Moulder wrote:
Does this mean that OpenDocument supports both SVG and some strange format unique to OpenDocument? Why the duplication?
I don't know enough about the format internals to answer this.
Support for this format would be much better if it maximized its use of SVG such that the many existing SVG applications could at least render it.
Makes sense to me. Please please please do talk to the OASIS TC. It's important that the format have what it takes to get the support it needs. That's the whole point of making the format.
Cheers,
On Mon, Jan 31, 2005 at 05:55:13PM -0500, Daniel Carrera wrote:
Support for this format would be much better if it maximized its use of SVG such that the many existing SVG applications could at least render it.
Makes sense to me. Please please please do talk to the OASIS TC. It's important that the format have what it takes to get the support it needs. That's the whole point of making the format.
I'm looking at the OpenDocument specification now, and seeing if I can help in the proposal of a replacement for that part of the specification.
Meanwhile, can someone else please get on their mailing list and discuss this? As Daniel pointed out in reply to mental, we have only until Friday!
pjrm.
Quoting Peter Moulder <Peter.Moulder@...38...>:
Support for this format would be much better if it maximized its use of SVG such that the many existing SVG applications could at least render it. E.g. the above would become
<svg:rect class="gr1 P1" draw:layer="layout" width="7.62cm" height="5.715cm" x="8.89cm" y="9.525cm" />
In principle this approach would be much better; the one caveat is that the SVG specification flatly forbids placing any SVG elements (except for <svg>) under a non-SVG-namespaced parent, so it would need to be SVG all the way up to an SVG root element embedded somewhere in the document.
(Actually, as you may recall, supporting such SVG islands natively is a long-term goal for Inkscape)
-mental
Nicu Buculei wrote:
first: the OpenDocument format is something like 99% identical with the old OpenOffice.org format.
That's not true.
OASIS took the old OOo format as a starting point, but with the help of KDE, Corel, Boeing, and many others, plus the requirements from the European Union, they have made a vastly more powerful format. This format is not OOo-centric.
The OpenOffice.org format specification is 570 pages. The OpenDocument specification is 750 pages.
That's not 99% the same. OpenDocument can do a lot of things OOo can't.
i'm not sure what was Daniel idea, but i'll speculate: OpenOffice.org Draw files are XML and very similar with SVG, probably this is why Daniel expect such import filter to be not to hard to develop.
I don't know enough about the subject to claim that it would be easy or hard. I only meant to say it would be very valuable for the success of the format.
Also, please please don't say "OpenOffice.org". OpenDocument is not an OOo project. OOo doesn't own it, or run it. We don't *want* to run it, because we know that this would only ensure that it won't go anywhere. KOffice and OOo have agreed to give up their formats and switch to a new one controlled by neither, for the purpose of giving that format a better chance to succeed.
BTW, Daniel, you forgot to mention in the Groklaw article that OpenOffice.org file format is supported also by Scribus:
Cool, I did not know that.
OpenDocument and the OOo format are similar. I hope that making OpenDocument filters is not too hard for Scribus.
difficult. But, what about OpenOffice support for the SVG file format?
OpenOffice.org can *export* in SVG. for import, some work (using a xslt filter) is done here: http://qa.openoffice.org/issues/show_bug.cgi?id=2497
Thank you for the link Nicu.
Cheers,
On Mon, 31 Jan 2005 12:10:02 -0500, Daniel Carrera <dcarrera@...674...> wrote:
The OpenOffice.org format specification is 570 pages. The OpenDocument specification is 750 pages.
As a professional technical writer I can tell you that it's not the best argument :)))
However, if the specs of OASIS OpenDocument are available, I would appreciate an URL. The only reason Scribus doesn't support importing files in OpenDocument format is no specs available to read.
Alexandre
Alexandre Prokoudine wrote:
The OpenOffice.org format specification is 570 pages. The OpenDocument specification is 750 pages.
As a professional technical writer I can tell you that it's not the best argument :)))
:-)
At least it shows that it's not just a carbon copy. I guess the better argument would be all the input OASIS got from Corel, KDE, several individuals, as well as the European Comission. There have been several changes to the format. It's not "99% the same".
However, if the specs of OASIS OpenDocument are available, I would appreciate an URL. The only reason Scribus doesn't support importing files in OpenDocument format is no specs available to read.
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
Thank you for asking. :-)
Cheers,
Alexandre Prokoudine wrote:
On Mon, 31 Jan 2005 12:10:02 -0500, Daniel Carrera <dcarrera@...674...> wrote:
The OpenOffice.org format specification is 570 pages. The OpenDocument specification is 750 pages.
As a professional technical writer I can tell you that it's not the best argument :)))
However, if the specs of OASIS OpenDocument are available, I would appreciate an URL. The only reason Scribus doesn't support importing files in OpenDocument format is no specs available to read.
http://xml.coverpages.org/ni2005-01-04-a.html
Jon
----------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hello John,
Sorry for the delay in responding, I just got to school.
First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format.
I'm trying to learn from the failure of the old "ODA" format, to prevent the same thing from happening to OpenDocument. The reason ODA failed was because there was no industry adoption. Hence, I'm arguing that we need to support OpenDocument in as many applications as we can manage. Details in the article.
The OpenDocument format can express vector graphics. In fact, my understanding is that it is either SVG or "essentially" SVG.
Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be difficult. But, what about OpenOffice support for the SVG file format?
It'd be good to draw a distinction between OpenOffice.org and OpenDocument. OOo does not control OpenDocument, it is but one application that supports it. And if all goes well, only one of many. OpenDocument is bigger than OOo or KDE or IBM or any of the current supporters.
But to address your question. If "someone" could write an XSLT transformation between OpenDocument and SVG, OOo could use that to make a filter yes.
Cheers,
Hey, what happened with this discussion? Can you give me an overview of what is happening with it and SVG?
Jon
On Mon, 2005-01-31 at 12:01 -0500, Daniel Carrera wrote:
Hello John,
Sorry for the delay in responding, I just got to school.
First of all, this is really exciting, but I wonder if you could write up more about what is needed of Inkscape for this new format.
I'm trying to learn from the failure of the old "ODA" format, to prevent the same thing from happening to OpenDocument. The reason ODA failed was because there was no industry adoption. Hence, I'm arguing that we need to support OpenDocument in as many applications as we can manage. Details in the article.
The OpenDocument format can express vector graphics. In fact, my understanding is that it is either SVG or "essentially" SVG.
Or do you want a filter that say one has an SVG file, then one can convert that to an OpenDocument file. I don't think that would be difficult. But, what about OpenOffice support for the SVG file format?
It'd be good to draw a distinction between OpenOffice.org and OpenDocument. OOo does not control OpenDocument, it is but one application that supports it. And if all goes well, only one of many. OpenDocument is bigger than OOo or KDE or IBM or any of the current supporters.
But to address your question. If "someone" could write an XSLT transformation between OpenDocument and SVG, OOo could use that to make a filter yes.
Cheers,
participants (7)
-
unknown＠example.com -
Alexandre Prokoudine -
Bryce Harrington -
Daniel Carrera -
Jon Phillips -
Nicu Buculei -
Peter Moulder