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.
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
Yes, it seems like this is the order of support we should have for
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?
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
San Francisco, CA
USA PH 510.499.0894
MSN, AIM, Yahoo Chat: kidproto
Jabber Chat: rejon@...896...