[MEI-L] symbol/symbolDef

[Laurent Pugin]

I agree with Thomas that SVG is probably the best choice. I also think
that it would be a good idea to have <symbolDef> as a placeholder for
SVG rather than defining our own shapes. I guess we are not directly
talking about rendering MEI here, but more about including the
encoding of shapes within a MEI document, so I don't see any reason
why we should restrict the use to a subset of SVG.

Laurent



On Mon, Mar 19, 2012 at 6:14 PM, TW <zupftom at googlemail.com> wrote:
> 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
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>