[MEI-L] symbol/symbolDef

[TW]

2012/3/19 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>
> I'd like to hear from the "rendering team" (Laurent, Craig, Thomas) whether SVG is so widely-used and widely-accepted that we should import its elements here exclusively.  How important is it to allow other "markup", such as PostScript or other existing schemes?
>

I hesitated to dig into this when writing my last mail, but as you're
asking for it:  In case I'll be losing myself in an excessive
monologous vector graphics discussion, I'll put the blame on you,
alright?

As PostScript is a programming language and not markup, I'd vote
against putting that into MEI.  (If I had to pick my favorite
programming language, I might choose PostScript, but I think MEI is
the wrong place for it.)  I feel that SVG is the only viable choice as
it's the only open vector graphics standard I'm aware of.  Of course,
there's PDF, but I think that's hardly possible to "inline", and SVG
is XML and therefore feels pretty comfortable inside XML.

The graphics model behind SVG is basically identical to the one that
PostScript and PDF use, and I think that pretty much any more recent
2D graphics technology copied from Adobe's model.  So in the end, it's
only about parsing, the rendering should not be too problematic
(within reasonable bounds).

When I wrote my last mail, I thought about replacing <line> and
<curve> with something along the lines of <svg:path>.  Not full SVG,
just <svg:path>.  To allow composite symbols, maybe also <svg:use>.
That should be fully sufficient for music--we don't need all this
fancy stuff like masks, patterns, clipping, gradients, animation and
the like.  SVG's line, polyline, polygon, circle, ellipse and rect
elements are convience elements that don't really give you anything
that path can't give you.  PostScript is happy without those.

I'd also lean towards a stricter subset of the path syntax that can
easily be parsed and rendered using any available 2D graphics
technology (PostScript/PDF, Windows' GDI+ or whatever they are using
nowadays, Apple's Quartz, Cairo, HTML canvas, whatever).  I'd maybe
restrict paths to the operators M,L, C and Z.  All other operators
are, again, convenience operators, except maybe for A/a.  However A/a
is omitted from the SVG Tiny/Mobile profile because it's the most
complex of the operators to implement[1].  On the rendering level, A/a
are usually broken down to approximating C operations anyway, so in
that sense it *is* a convenience operator.

I'd also maybe restrict the filling rule to non-zero-winding, which
seems to be the more common one.

To facilitate parsing, I'd demand whitespace between each operator and
number.  SVG allows things like "M.5-4.1.2 3", but this compressed
syntax (which is legal) isn't always parsed correctly--namely by
librsvg, the SVG library that e.g. Wikipedia uses.

Subsetting of course has two sides:  On the one hand it greatly
facilitates processing, but on the other hand you can't throw in any
SVG you might have generated.  So I'm not sure what's the best
solution, full SVG (or SVG Tiny) or only <path> with restrictions to
the path syntax.

Is it sufficient if <symbolDef> can specify outlines of symbols, like
they are defined in a font?  Otherwise, we'd also have to consider
stroke widths, dash patterns, line caps and line joins.  Not to forget
stroke and fill color.  I think that's it.  I don't think we'd need
transparency effects, would we?  I'm not sure if we'd need SVG
transformations.  <symbolDef> seems more like defining glyphs of a
font rather than painting fancy graphics.  For simple glyph outlines,
we wouldn't even have to consider fill colors, stroking, dash
patterns, line caps and line joins.

Once again, I might be seeing this too much from the implementor's
perspective with all this subsetting and stripping convenience
functionality...

Thomas


[1] http://www.w3.org/TR/SVGMobile/#paths