[MEI-L] coordinates

Thu Feb 24 13:40:05 CET 2011

Hi Thomas,

Am 24.02.2011 um 12:28 schrieb TW:

> Thanks Johannes, Andrew and Roland,
> 
> 2011/2/23 Johannes Kepper <kepper at edirom.de>:
>> MEI has different approaches to graphics. When you plan to describe an existing image, you should use the @facs-attribute and refer to a zone-element in facsimile (sibling of body). I don't think that this is what you're looking for, but it is surely the better established way to deal with graphics in MEI.
> 
> You're right, I'm more interested in data that allows reproducing the
> graphics and is editable (i.e. no preexisting image).  That's probably
> not what MEI is designed for.  I'm looking for inspiration from
> existing music encoding solutions and whether one already covers
> everything that might be needed or whether it can be extended to do
> so.  So all my comments are from this perspective.  I have only a
> vague idea of what MEI has to accomplish from the musicologist's
> perspective.
> 
> I'll just go ahead and write down questions and things that came to my
> mind while reading in the documentation.
> 
> 
> 2011/2/23 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> Basically, within facsimile you define a number of bounding boxes using <zone>, defined by ulx,uly/lrx,lry coordinates. These all have a unique ID. Then on every musical element, you use the @facs attribute to refer to the unique ID of the corresponding zone.
> 
> I'm not sure whether I understand the <facsimile> element correctly.
> Where do the <graphic>s come into play?  Both <surface> and <zone> can
> hold <graphic>s, so is a <surface> meant to hold a single <graphic>
> for the whole "page", or are the <zones> meant to hold <graphic>s that
> in combination make up the page?  Or are both approaches valid?
> 

Normally you have one facsimile for each source you want to encode. The facsimile contains one <surface> for each page of this source. Within <surface> you'll typically find one <graphic> that points to a digital image of that page (multiple graphics for different kinds of images like x-ray…). The <zone>-elements are normally siblings of that <graphic>. Btw: It seems like you can't refer from a <zone> to a specific <graphic> when there is more than one of them… Seems like a bug to me… 

> What about vector graphics?  If you have the facsimile e.g. as SVG
> data, would it be possible to provide it with @xml:id attributes and
> point to those using @facs attributes?  If I understand the XML specs
> correctly, then an IDREF can only reference an element in the same
> file.  As far as I can see, MEI can only reference graphics as
> external files, not embed them.

You can refer to a SVG instead of a JPG without any problems. You could also include SVGs within <surface> in order to get non-rectangular <zones>. This needs only little customization and is the intended way to go. I hope we have the time to prepare such a customization for the next release. 

> 
> 
> If I'm getting this correctly, there can be more than one <facsimile>
> element.  Wouldn't it be reasonable to give corresponding <zone>s in
> different facsimiles the same "non-unique ID" (would that be of type
> xs:key then)?  Or are the correspondences not always bijective?
> 

You wouldn't do that kind of connecting in the <facsimile>-subtree normally. Instead you would point to multiple <zone>s from the "semantical" element: As @facs is of type xs:IDREFs a <measure> can point to a number of <zone>s. All of them represent this particular measure then. But of course, modelling such relationships is possible in many other ways…

> 
> 2011/2/23 Roland, Perry (pdr4h) <pdr4h at eservices.virginia.edu>:
>> 
>> If on the other hand, you want to specify where a feature is supposed to wind up in rendered version of the encoding, then x and y coordinates should be used.  Because it's impossible to mandate a single coordinate system for all uses/users, the values of x and y are left to the user.  I suppose these values could be contextual, but it probably would be most useful to employ a single, page-based coordinate system.
>> 
> 
> For my targeted application, page-based absolute coordinates wouldn't
> give me much added benefit over a finalized facsimile layout (which
> seems to be sufficiently covered by MEI).  Relative positions would be
> more useful for editable music.  For example, it's more useful to read
> or set the vertical position of an <artic> relative to the note or
> staff (in half staff line line distances, or let me call it "steps").
> I'd most likely leave this relative position constant when I only want
> to display/print one system instead of the whole page, change the page
> margins, change the system breaks, move the staffs up or down a bit,
> add a cautionary accidental and rejustify the line of music or if I
> create parts (or a score) from the data.
> 
> Relative coordinates would of course require thorough documentation
> defining where they are "anchored".
> 

Definitely a good point. As Perry already mentioned, MEI is primarily tailored to describe preexisting notation, whereas output description is surely treated somewhat "stepmotherly". There is definitely room for improvement, and I'm sure to speak for the whole community when saying that help on this is more than welcome… (Though I have to admit that a possible direction of this (interchange between multiple scorewriters) is probably not the foremost goal of MEI)

> 
>> [...] for relative placement MEI uses half the distance between adjacent staff lines as the basic unit of measurement.  (For example, ho=".5" indicates half of the basic unit or one quarter of the distance between two staff lines.)
> 
> I'm not yet convinced of the offsets' usefulness in their currently
> documented form.  The @ho/@vo attributes are specified to be an
> "adjustment of a feature's programmatically-determined location".  If
> the initial location is programmatically determined, then I can't tell
> what effect the offset will have, can I?  Let's take for example a
> <dynam>f</dynam>.  An application might place it at an arbitrary y
> location.  It might have a built-in fixed default y level for dynamics
> that I don't know about, it might try to avoid collisions and keep a
> certain unknown distance from other elements.  If there are other
> elements at the same place, there are different "stacking" orders it
> might choose from, it might even shift the symbol horizontally for
> collision prevention, it might put it above or below the staff,
> depending on how "intelligently" it recognizes vocal parts.  So there
> is a virtually unlimited number of potential
> "programmatically-determined" initial positions.  I think the offsets
> can only be useful if the initial position is clearly defined.

For vertical relative positioning, I'd say the origin is the timestamp of that particular feature. If a <dynam>f</dynam> happens on the second beat, its standard position would be right below a note on this position. Of course this reveals some problems when thinking about the interdependencies between the regular unit of half inter-staff-line distances and the density of the notation, but currently it seems to be the most promising interpretation. This does not help much on vertical positioning, though.

> 
> By the way, is the @stem.length attribute also meant to be in "steps"
> (half staff line line distances)?

Yes. 

> 
> There are certainly more questions to come.

Good to hear – looking forward :-) Honestly, there are definitely too many underdefined issues in the schema / tag library. We try to address as much of them as possible in the next release (which should be stable in the second half of the year), but we're always happy for additional input (and people who regard themselves as community members…). 

Best,
Johannes

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