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.