[MEI-L] symbol/symbolDef

[Laurent Pugin]

On Tue, Mar 20, 2012 at 7:50 AM, TW <zupftom at googlemail.com> wrote:
> 2012/3/20 Laurent Pugin <laurent at music.mcgill.ca>:
>> 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.
>>
>
> >From Perry's post I got the impression that the module's intent indeed
> was to provide symbols for rendering.  If not, then we'd only be
> saying something like "See, this is how this symbol looks like", and
> the symbol's dimensions and origin wouldn't be significant.  In this
> case, I'd think it would be more (or at least similarly) adequate to
> link to an example in the facsimile rather than redrawing the symbol.
> This was my initial understanding that I expressed in the original
> post.  It would basically provide a means of classifying and
> identifying different kinds of symbols, especially ones that aren't
> covered by MEI (and maybe shouldn't be because they are only used by a
> certain scribe/composer/very special notation or only in a single
> work).

I think we agree. What I meant was not for rendering other MEI
elements (e.g., a <note>). SVG for special symbols would of course be
used for rendering. That is, we would take benefit from the fact that
SVG is a self-rendered (or "renderable", sorry for the neologism?)
encoding.

Laurent