Heya guys, did you all see that 150 million phones have now shipped that have SVG tiny support!
http://svg.org/story/2006/9/27/121431/107
Anyway, I'm curious to revive this discussion about what we need to do to get Inkscape up to par with using differing SVG profiles.
Here is what we wrote so far: http://wiki.inkscape.org/wiki/index.php/SVG_Tiny_Compliance
I really think our 0.5 is SVG Tiny compliance and I'm curious how we can get there. How can we do it y'all?
Jon
On Fri, 2006-09-29 at 16:11 -0700, Jon Phillips wrote:
I really think our 0.5 is SVG Tiny compliance and I'm curious how we can get there. How can we do it y'all?
Simply supporting SVG Tiny ourselves isn't that hard. I think part of what's needed is the ability to restrict a document and editing on it to a particular SVG profile. This goes beyond just "Save as... SVG 1.2 Tiny" or whatever, though that might not be bad to have either.
-mental
On Sep 29, 2006, at 4:41 PM, MenTaLguY wrote:
On Fri, 2006-09-29 at 16:11 -0700, Jon Phillips wrote:
I really think our 0.5 is SVG Tiny compliance and I'm curious how we can get there. How can we do it y'all?
Simply supporting SVG Tiny ourselves isn't that hard. I think part of what's needed is the ability to restrict a document and editing on it to a particular SVG profile. This goes beyond just "Save as... SVG 1.2 Tiny" or whatever, though that might not be bad to have either.
Sounds like time for "target profiles" or some such.
There are a few things that can be leveraged: UI simplification, tool restrictions, "out of target" warnings, validation, etc.
One feature to help targeting specific profiles would be to add an "out of profile" warning to nodes in the Object tree. Among other things this could aid in "correcting" a file for a target profile. This might be a good first step as it is far simpler than trying to automatically correct SVG and also simpler than dynamic munging of the UI and tools.
An additional UI change that can come in would be a target preview. This work could be leveraged for animation later on down the road, as that would also benefit from a dual edit/preview split. One easy enhancement for the "target preview" UI could be simple lcms display profiles. Then a given SVG Tiny device preview could have things like 12-bit or 16-bit color simulated by the use of CMS. Helping artists avoid "what the heck happened to my gradient" surprises could be quite useful.
And as we move into implementing things, a little implementation tool might be Schematron. First of all, the schematroll is cute.
:-)
However, it does allow for structure validation through simple XPath "test" statements, and for various reasons we have XPath going into our codebase already. One then could use simple rules both for validating SVG in use and for turning on and off parts of the UI and tools.
On Fri, 2006-09-29 at 17:00 -0700, Jon A. Cruz wrote:
On Sep 29, 2006, at 4:41 PM, MenTaLguY wrote:
On Fri, 2006-09-29 at 16:11 -0700, Jon Phillips wrote:
I really think our 0.5 is SVG Tiny compliance and I'm curious how we can get there. How can we do it y'all?
Simply supporting SVG Tiny ourselves isn't that hard. I think part of what's needed is the ability to restrict a document and editing on it to a particular SVG profile. This goes beyond just "Save as... SVG 1.2 Tiny" or whatever, though that might not be bad to have either.
Sounds like time for "target profiles" or some such.
There are a few things that can be leveraged: UI simplification, tool restrictions, "out of target" warnings, validation, etc.
Yep...
One feature to help targeting specific profiles would be to add an "out of profile" warning to nodes in the Object tree. Among other things this could aid in "correcting" a file for a target profile. This might be a good first step as it is far simpler than trying to automatically correct SVG and also simpler than dynamic munging of the UI and tools.
An additional UI change that can come in would be a target preview. This work could be leveraged for animation later on down the road, as that would also benefit from a dual edit/preview split. One easy enhancement for the "target preview" UI could be simple lcms display profiles. Then a given SVG Tiny device preview could have things like 12-bit or 16-bit color simulated by the use of CMS. Helping artists avoid "what the heck happened to my gradient" surprises could be quite useful.
Yes, it seems like this is the order of support we should have for profiles:
1.) "out of profile" warning flag to nodes in the obj. tree 2.) out of target warning in the UI 3.) target save + target preview 4.) UI simplification
Does this sound right in order of priority for implementation?
Also, JonCruz, maybe you could outline a bit of this on the wiki page I sent out previously...how can others plug into this?
I wonder if a chart that details our level of support for the various major SVG specs. would help? This would be a great way to visualize what needs to be added.
What would really be cool is to have some type of testing for each of these areas in the spec, hook this into our crucible testing of inkscape and give us automated testing over how we support these different profiles. This would be cool. Bryce, what do you think about this?
Jon
And as we move into implementing things, a little implementation tool might be Schematron. First of all, the schematroll is cute.
Huh? I like the word, but don't know what this is...
:-)
However, it does allow for structure validation through simple XPath "test" statements, and for various reasons we have XPath going into our codebase already. One then could use simple rules both for validating SVG in use and for turning on and off parts of the UI and tools.
On Oct 2, 2006, at 3:05 PM, Jon Phillips wrote:
And as we move into implementing things, a little implementation tool might be Schematron. First of all, the schematroll is cute.
Huh? I like the word, but don't know what this is...
Ahh... good. Someone took the bait.
This is the Schematrol http://xml.ascc.net/resource/schematron/bilby.jpg
And Schematron: http://en.wikipedia.org/wiki/Schematron
It's a very interesting approach that sets out a simple method to apply XPath expressions as assertions on document structure.
On 10/3/06, Jon A. Cruz <jon@...18...> wrote:
And Schematron: http://en.wikipedia.org/wiki/Schematron
It's a very interesting approach that sets out a simple method to apply XPath expressions as assertions on document structure.
I love Schematron. I use it in all my XML projects and have never needed the XML Schema monstrosity. If we have XPath built in, which Bob is working on, it will be trivial to use Schematron.
On Mon, Oct 02, 2006 at 03:05:20PM -0700, Jon Phillips wrote:
I wonder if a chart that details our level of support for the various major SVG specs. would help? This would be a great way to visualize what needs to be added.
What would really be cool is to have some type of testing for each of these areas in the spec, hook this into our crucible testing of inkscape and give us automated testing over how we support these different profiles. This would be cool. Bryce, what do you think about this?
Well, we'd need to have a test-case for each feature in the spec. Does the W3C testsuite cover SVG Tiny fully enough?
Bryce
On Tue, 2006-10-03 at 00:18 -0700, Bryce Harrington wrote:
On Mon, Oct 02, 2006 at 03:05:20PM -0700, Jon Phillips wrote:
I wonder if a chart that details our level of support for the various major SVG specs. would help? This would be a great way to visualize what needs to be added.
What would really be cool is to have some type of testing for each of these areas in the spec, hook this into our crucible testing of inkscape and give us automated testing over how we support these different profiles. This would be cool. Bryce, what do you think about this?
Well, we'd need to have a test-case for each feature in the spec. Does the W3C testsuite cover SVG Tiny fully enough?
Bryce
Jon Cruz or anyone know the answer to this?
I just looked on their site and looks like the SVG Tiny 1.1 test suite is pretty complete: http://www.w3.org/Graphics/SVG/Test/
They have a web-based and SVG test harness for both basic and tiny...
This would be so cool to hook this test suite in with Inkscape and really would give us a clear mission on becoming fully compliant...I can see it now - autofiling of bug reports with errors...it would be a visual game to try and close out features and bugs because we can clearly see and measure how compliant we are against this test suite.
Bryce, if you think its a good idea, I wonder if you could help us outline how to get up-and-running on this with crucible.
Jon
An idea that I had a long time ago (noting the copyright statement, it was in 2004) is contained in svg-profile.h. The idea was that every verb could contain an Inkscape::SvgProfile object. Then you could adjust which verbs were visible (active) based on the SVG profile. The header file basically implements a fancy bitmask that can grow easily. The idea was also to make everything in a way that could be built into the static verb arrays also.
Looking through the code today, there is a little bit to be desired, but I think it works. I don't believe it's ever been checked in in a state where it is linked into the build.
This doesn't solve many of the SVG feature analysis issues, but it does solve some of the UI issues in 'limiting' Inkscape features so that you don't create invalid SVG.
--Ted
On Thu, 2006-10-05 at 21:55 -0700, Ted Gould wrote:
An idea that I had a long time ago (noting the copyright statement, it was in 2004) is contained in svg-profile.h. The idea was that every verb could contain an Inkscape::SvgProfile object. Then you could adjust which verbs were visible (active) based on the SVG profile. The header file basically implements a fancy bitmask that can grow easily. The idea was also to make everything in a way that could be built into the static verb arrays also.
Looking through the code today, there is a little bit to be desired, but I think it works. I don't believe it's ever been checked in in a state where it is linked into the build.
This doesn't solve many of the SVG feature analysis issues, but it does solve some of the UI issues in 'limiting' Inkscape features so that you don't create invalid SVG.
--Ted
This is very cool Ted...I think you should check it in and we can start fixing it up. I'm very eager to put this SVG Tiny goal on target to drive myself and others to ultimate victory over all that is vector :)
No really, I think if you commit this and document how to do this, this will help us get closer to the UI goal of disabling certain features based upon profiles.
Is there also a class that reads in different profiles so we can start filling out what is in the different specs...something that we can flesh out?
Jon
On Oct 5, 2006, at 9:55 PM, Ted Gould wrote:
An idea that I had a long time ago (noting the copyright statement, it was in 2004) is contained in svg-profile.h. The idea was that every verb could contain an Inkscape::SvgProfile object. Then you could adjust which verbs were visible (active) based on the SVG profile. The header file basically implements a fancy bitmask that can grow easily. The idea was also to make everything in a way that could be built into the static verb arrays also.
I think we might want to shift things around the other way.
That is, I think we should consider verbs to be lower-level atomic items that just do their job but don't know about the higher-level concept of profile grouping.
Then above the verb level we could have the profile manager and profile instances. Each of these could contain the lists of verbs applicable (or a list of those blocked).
I think it's important to approach it this way for a few reasons. The main one is that then there is no profile info hardcoded in the verbs themselves, and the profiles can just be loaded from files at runtime. Among other things this would allow end users to craft custom profiles to target individual phones, etc.
So instead of verbs holding profile info, there would be a set of profiles that have a list of verbs to block or allow, and something else to apply the filtering by profile.
On Fri, 2006-10-06 at 10:40 -0700, Jon A. Cruz wrote:
On Oct 5, 2006, at 9:55 PM, Ted Gould wrote:
An idea that I had a long time ago (noting the copyright statement, it
was in 2004) is contained in svg-profile.h. The idea was that every
verb could contain an Inkscape::SvgProfile object. Then you could
adjust which verbs were visible (active) based on the SVG profile. The
header file basically implements a fancy bitmask that can grow easily.
The idea was also to make everything in a way that could be built into
the static verb arrays also.
I think we might want to shift things around the other way.
That is, I think we should consider verbs to be lower-level atomic items that just do their job but don't know about the higher-level concept of profile grouping.
Then above the verb level we could have the profile manager and profile instances. Each of these could contain the lists of verbs applicable (or a list of those blocked).
I think it's important to approach it this way for a few reasons. The main one is that then there is no profile info hardcoded in the verbs themselves, and the profiles can just be loaded from files at runtime. Among other things this would allow end users to craft custom profiles to target individual phones, etc.
So instead of verbs holding profile info, there would be a set of profiles that have a list of verbs to block or allow, and something else to apply the filtering by profile.
Lets do it...divide and conquer...:) I want in on it...lead me :)
Jon
On Fri, 2006-10-06 at 10:40 -0700, Jon A. Cruz wrote:
I think it's important to approach it this way for a few reasons. The main one is that then there is no profile info hardcoded in the verbs themselves, and the profiles can just be loaded from files at runtime. Among other things this would allow end users to craft custom profiles to target individual phones, etc.
Another very important reason, to my mind, is that it would allow us to do it in terms of a general approach of setting up constraints to which verbs can be shown/active, among which constraints would be "is this verb meaningful for the current profile?"
-mental
On Mon, 2006-10-09 at 18:10 -0400, MenTaLguY wrote:
On Fri, 2006-10-06 at 10:40 -0700, Jon A. Cruz wrote:
I think it's important to approach it this way for a few reasons. The main one is that then there is no profile info hardcoded in the verbs themselves, and the profiles can just be loaded from files at runtime. Among other things this would allow end users to craft custom profiles to target individual phones, etc.
Another very important reason, to my mind, is that it would allow us to do it in terms of a general approach of setting up constraints to which verbs can be shown/active, among which constraints would be "is this verb meaningful for the current profile?"
-mental
Yep, this is a great idea. Jon Cruz hook up the task list and lets do this ;)
Also, looks like SVG Tiny has been renamed SVG Mobile, btw!
Jon
participants (6)
-
Bryce Harrington -
bulia byak -
Jon A. Cruz -
Jon Phillips -
MenTaLguY -
Ted Gould