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.