[MEI-L] coordinates

[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?

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.


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?


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".


> [...] 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.

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

There are certainly more questions to come.
Thomas Weber