[MEI-L] symbol/symbolDef

[Roland, Perry (pdr4h)]

Just to clarify:

The purpose behind the symbolDef/symbol pair is to encode *user-defined* shapes/signs/symbols so that they can be rendered.

This is distinctly different from classifying/identifying shapes/signs/symbols in a facsimile, which  can/should be handled using @facs on MEI elements.

Just a reminder:

Don't forget about @altsym which can be used to link an MEI element directly to a <symbolDef>.

--
p.

__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________________
From: mei-l-bounces at lists.uni-paderborn.de [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent Pugin [laurent at music.mcgill.ca]
Sent: Tuesday, March 20, 2012 4:05 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] symbol/symbolDef

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

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l