While I'm thinking about it, what SVG version should we indicate in our output?
If we are including SVG 1.2 features like the flow text stuff, don't we almost have to bump the version number to 1.2?
-mental
On Thu, 25 Nov 2004, MenTaLguY wrote:
While I'm thinking about it, what SVG version should we indicate in our output?
If we are including SVG 1.2 features like the flow text stuff, don't we almost have to bump the version number to 1.2?
If it would require a 1.2-compliant viewer to view the file, then yeah sorta sounds like you'd want to list it as 1.2. However, will this cause conflicts with other software that may reject SVG 1.2 ? If not, then yeah, couldn't hurt to bump it.
Btw, is there an early version of the SVG spec that we support 100%?
Bryce
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote:
While I'm thinking about it, what SVG version should we indicate in our output?
If we are including SVG 1.2 features like the flow text stuff, don't we almost have to bump the version number to 1.2?
If it would require a 1.2-compliant viewer to view the file, then yeah sorta sounds like you'd want to list it as 1.2. However, will this cause conflicts with other software that may reject SVG 1.2 ? If not, then yeah, couldn't hurt to bump it.
Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
Jon
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 25 Nov 2004, Jon Phillips wrote:
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote: Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
Bryce
Bryce Harrington wrote:
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
Sounds good to me.
I can probably also pour on some effort for running through test cases and whatnot to see where we match specs and where we need to tune things. Between all the SVG test cases out there, and my experience getting a solid XForms implementation done, I should be able to at least get the paraneters set for the effort.
On Fri, 26 Nov 2004, Jon A. Cruz wrote:
Bryce Harrington wrote:
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
Sounds good to me.
I can probably also pour on some effort for running through test cases and whatnot to see where we match specs and where we need to tune things. Between all the SVG test cases out there, and my experience getting a solid XForms implementation done, I should be able to at least get the paraneters set for the effort.
Cool, sounds like a plan then. Peter did a good write-up of the major capabilities we'd need. I think this'll be an excellent goal to shoot for as a project.
Jon, using Peter's findings, could you plan out what changes need to be implemented to achieve this, and fold them into the Roadmap win wiki?
Maybe shoot for having "most" items done by around 0.43, 99% by 0.44, and 100% by 0.45. Don't try to be _too_ ambitious - give plenty of time to do a good job. We've got several other equally important initiatives that'll need work in the meantime.
My guess is that Animation will be the major gating item, but maybe not. In any case, this is a frequent request from users so the need for it for SVG Tiny means we can kill two birds. :-)
Bryce
On Fri, 2004-11-26 at 00:34 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, Jon Phillips wrote:
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote: Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
I think sounds like a brilliant idea for 0.42 (a more stable release). Maybe that could be a SVG Tiny + bugfix release.
With the strength of our developers, I think more general goals such as SVG Tiny Compliance are good. After we have compliance with SVG Tiny, I think we will be positioned to aid many new developers for SVG Tiny development on cellphones.
ROCK!
Jon
On Fri, 2004-11-26 at 03:34, Bryce Harrington wrote:
On Thu, 25 Nov 2004, Jon Phillips wrote:
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote: Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
I would strongly support such an initiative.
-mental
On Fri, Nov 26, 2004 at 12:34:39AM -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, Jon Phillips wrote:
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote: Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
As a first glance without looking much at either the spec or inkscape source, I believe we need the following: don't rely on style attributes working (use fill=... attributes); switch; SVG fonts; animation.
Styling We must write `fill="..." etc. attributes instead of using style="fill:...". (I.e. when writing SVG Tiny documents, we must not use style attributes -- or at least use only "redundant" style attributes if that's easier to implement.)
switch Minimum requirement is that we render it correctly (e.g. as a viewer would, showing just one child). Interface for viewing other branches would be nice (perhaps a non-modal dialog box listing the children named by their requiredFeatures, requiredExtensions and systemLanguage attributes. The layers dialog box may be a good base.
SVG fonts: font, font-face, font-face-src, font-face-name, missing-glyph, glyph massifr has started work on this. He's still new to inkscape source code, so could use guidance.
a Especially relevant to Inkview. For Inkscape (editor), ability to launch URLs from the context menu might be nice but not essential. An ability to create <a> elements other than using the XML editor would also be nice.
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set My reading is that we can't claim to support all of SVG Tiny without supporting animation.
Easier in a viewer than in an editor... For editing interface, Brisgeek says that Macromedia Flash is a good example. He couldn't off hand think of free software examples, but mentioned Moho as a gratis-but-non-free example. (Written in Java.) F4L is a non-functional free-software mock-up of the Flash 4 interface. Of course we should search for existing relevant free software.
For advanced stuff (research territory), we may be able to work with the project Opera people at INRIA, possibly working with the Madeus editor. (I mention this example only because our group at Monash has worked with them before.)
(I believe we don't need to do anything to support the foreignObject element. We already have the property of not discarding unrecognized elements like foreignObject and its children.)
pjrm.
a Especially relevant to Inkview. For Inkscape (editor), ability to launch URLs from the context menu might be nice but not essential. An ability to create <a> elements other than using the XML editor would also be nice.
right click on an object, then do create link. creates an a for you on that object.
__________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Peter Moulder wrote:
Easier in a viewer than in an editor... For editing interface, Brisgeek says that Macromedia Flash is a good example. He couldn't off hand think of free software examples, but mentioned Moho as a gratis-but-non-free example. (Written in Java.) F4L is a non-functional free-software mock-up of the Flash 4 interface. Of course we should search for existing relevant free software.
I've worked with quite a few interfaces over the years, including owning Macromind Director 1.0 and being a beta tester on Macromind 3D, using Strata3D, Autodesk 3D Studio, Max, Maya, etc.
Getting an interface together well probably not be *that* hard. Knowing the domain enough to figure out what needs to be coded is where most of the work lies.
Good news is... we don't have to make the UI backwards-compatible with Director 1.0 :-)
On Sat, Nov 27, 2004 at 11:31:31AM +1100, Peter Moulder wrote:
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set
http://wam.inrialpes.fr/software/limsee2/
SMIL editor. Unfortunately non-free (despite the claim on the web site): claims not to allow commercial use.
In practice I doubt this is only partially enforceable legally: use isn't covered by copyright law, so only people who copy or distribute it (or any other action covered by copyright law) need to abstain from using it commercially. I'll see what their plans are and whether they can change their minds. The fact that they claim open-sourceness suggests a certain willingness for it actually to be open source.
pjrm.
On Sun, 28 Nov 2004, Peter Moulder wrote:
On Sat, Nov 27, 2004 at 11:31:31AM +1100, Peter Moulder wrote:
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set
http://wam.inrialpes.fr/software/limsee2/
SMIL editor. Unfortunately non-free (despite the claim on the web site): claims not to allow commercial use.
In practice I doubt this is only partially enforceable legally: use isn't covered by copyright law, so only people who copy or distribute it (or any other action covered by copyright law) need to abstain from using it commercially. I'll see what their plans are and whether they can change their minds. The fact that they claim open-sourceness suggests a certain willingness for it actually to be open source.
It's definitely worth a shot. Make sure to specifically ask if the code can be used under the terms of the GPL. Let them know that we're interested in incorporating SMIL animation into Inkscape.
If they say no to that usage, ask if they'd have any problem if we were to clone/reimplement it in C++ for Inkscape, without using their code directly.
That's a really sweet editor, it'd kick ass if we could have that level of capability within Inkscape. :-)
Bryce
On Sat, 2004-11-27 at 22:59 -0800, Bryce Harrington wrote:
On Sun, 28 Nov 2004, Peter Moulder wrote:
On Sat, Nov 27, 2004 at 11:31:31AM +1100, Peter Moulder wrote:
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set
http://wam.inrialpes.fr/software/limsee2/
SMIL editor. Unfortunately non-free (despite the claim on the web site): claims not to allow commercial use.
In practice I doubt this is only partially enforceable legally: use isn't covered by copyright law, so only people who copy or distribute it (or any other action covered by copyright law) need to abstain from using it commercially. I'll see what their plans are and whether they can change their minds. The fact that they claim open-sourceness suggests a certain willingness for it actually to be open source.
It's definitely worth a shot. Make sure to specifically ask if the code can be used under the terms of the GPL. Let them know that we're interested in incorporating SMIL animation into Inkscape.
If they say no to that usage, ask if they'd have any problem if we were to clone/reimplement it in C++ for Inkscape, without using their code directly.
Well, if you look on the site, the app. is all in JAVA!!! Maybe there is a C or C++ OSS framework or smil editor already. We don't wanna add JAVA into our codebase do we?
That's a really sweet editor, it'd kick ass if we could have that level of capability within Inkscape. :-)
Yes agree. I like the website minus how it doesn't expand with the page.
jon
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 28 Nov 2004, Jon Phillips wrote:
On Sat, 2004-11-27 at 22:59 -0800, Bryce Harrington wrote:
If they say no to that usage, ask if they'd have any problem if we were to clone/reimplement it in C++ for Inkscape, without using their code directly.
Well, if you look on the site, the app. is all in JAVA!!! Maybe there is a C or C++ OSS framework or smil editor already. We don't wanna add JAVA into our codebase do we?
Yes, but a few thoughts on that:
If they are willing to cooperate closely with us, and can do GPL and be willing to change to integrate with Inkscape, that may be the best case situation - they'd have the responsibility for maintaining and developing that section of code, yet we'd be able to fully benefit from it. If they're maintaining it and it works well with Inkscape, then the language it's written in may not be that big of a deal to us.
On the other hand, if they're willing to let us use it under GPL but are not willing to do anything particular to help us, we still benefit. It's been my experience in the past that translating an application from one language to another requires a fraction of the work that creating it from scratch does. _Especially_ Java->C++ or vice versa. Most of the trouble would be replacing libs.
If they're not willing to provide GPL licensing and won't be adapting it for Inkscape's use, we can still lift ideas from it.
Bryce
Bryce Harrington wrote:
Yes, but a few thoughts on that:
If they are willing to cooperate closely with us, and can do GPL and be willing to change to integrate with Inkscape, that may be the best case situation - they'd have the responsibility for maintaining and developing that section of code, yet we'd be able to fully benefit from it. If they're maintaining it and it works well with Inkscape, then the language it's written in may not be that big of a deal to us.
Well... in looking over things, I don't think there's that much that can be leveraged.
There's enough difference in how AWT/Swing is archetected versus GTK+, internal representations, DOM, etc. Also, what's needed to get animation going is conceptually not to much different from what we have now. In extending things to handle plugins and external scripting, we are also doing a lot of what's needed for animation.
The main work will be in UI elements, which again would have to be re-coded to do in GTK+ anyway. Of course, as long as we make our XML tree view reusable and things like that, we can get things tuned up nicely a little faster.
This is an excellent list to start from. I've added this to Wiki:
http://inkscape.org/cgi-bin/wiki.pl?SVG_Tiny_Compliance
Bryce
On Sat, 27 Nov 2004, Peter Moulder wrote:
On Fri, Nov 26, 2004 at 12:34:39AM -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, Jon Phillips wrote:
On Thu, 2004-11-25 at 16:23 -0800, Bryce Harrington wrote:
On Thu, 25 Nov 2004, MenTaLguY wrote: Btw, is there an early version of the SVG spec that we support 100%?
We talked before about SVG Tiny which is a subset of SVG 1.1: http://www.w3.org/TR/SVGMobile/
We don't fully support this though yet...mainly because of lack of support for the switch statement declaring multiple profiles.
What do you think if we set a goal for 0.42 or 0.43 to fully support 100% of SVG Tiny? That'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs.
As a first glance without looking much at either the spec or inkscape source, I believe we need the following: don't rely on style attributes working (use fill=... attributes); switch; SVG fonts; animation.
Styling We must write `fill="..." etc. attributes instead of using style="fill:...". (I.e. when writing SVG Tiny documents, we must not use style attributes -- or at least use only "redundant" style attributes if that's easier to implement.)
switch Minimum requirement is that we render it correctly (e.g. as a viewer would, showing just one child). Interface for viewing other branches would be nice (perhaps a non-modal dialog box listing the children named by their requiredFeatures, requiredExtensions and systemLanguage attributes. The layers dialog box may be a good base.
SVG fonts: font, font-face, font-face-src, font-face-name, missing-glyph, glyph massifr has started work on this. He's still new to inkscape source code, so could use guidance.
a Especially relevant to Inkview. For Inkscape (editor), ability to launch URLs from the context menu might be nice but not essential. An ability to create <a> elements other than using the XML editor would also be nice.
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set My reading is that we can't claim to support all of SVG Tiny without supporting animation.
Easier in a viewer than in an editor... For editing interface, Brisgeek says that Macromedia Flash is a good example. He couldn't off hand think of free software examples, but mentioned Moho as a gratis-but-non-free example. (Written in Java.) F4L is a non-functional free-software mock-up of the Flash 4 interface. Of course we should search for existing relevant free software. For advanced stuff (research territory), we may be able to work with the project Opera people at INRIA, possibly working with the Madeus editor. (I mention this example only because our group at Monash has worked with them before.)(I believe we don't need to do anything to support the foreignObject element. We already have the property of not discarding unrecognized elements like foreignObject and its children.)
pjrm.
SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 2004-11-25 at 19:23, Bryce Harrington wrote:
If it would require a 1.2-compliant viewer to view the file, then yeah sorta sounds like you'd want to list it as 1.2. However, will this cause conflicts with other software that may reject SVG 1.2 ? If not, then yeah, couldn't hurt to bump it.
I guess for now, since we're in freeze, the best thing to do is pick a version of SVG that encompasses all the features accessible from the GUI.
At present, we declare our SVGs to be version 1.0. Are there any 1.1-specific features we use? If not, we can probably leave things as-is for this release at least.
-mental
participants (6)
-
Bryce Harrington -
John Cliff -
Jon A. Cruz -
Jon Phillips -
MenTaLguY -
Peter Moulder