<div dir="ltr">Think of "virtual units" as "diatonic steps" and then there should be no confusion. </div><div class="gmail_extra"><br><div class="gmail_quote">On 7 July 2017 at 17:22, Byrd, Donald A. <span dir="ltr"><<a href="mailto:donbyrd@indiana.edu" target="_blank">donbyrd@indiana.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure. As I said, both Gould and Ross talk about "half spaces".  --DAB<br>
<br>
On Jul 7, 2017, at 11:03 AM, "Roland, Perry D. (pdr4h)" <<a href="mailto:pdr4h@eservices.virginia.edu">pdr4h@eservices.virginia.edu</a>><br>
<div class="HOEnZb"><div class="h5"> wrote:<br>
<br>
><br>
> Hi Don,<br>
><br>
> You make a good argument for the term "staff-space" or "space".  However, MEI doesn't use this distance as its unit of measurement. Instead, MEI uses *half the distance* between adjacent staff lines, hence the need for a different term.  Perhaps "interline distance" and "virtual unit" aren't intuitive, but they accurately describe the situation, which "staff-space" or "space" do not.  Of course, we could start using the entire distance between staff lines as the unit, but that would mean changing all existing MEI markup and software.<br>
><br>
> --<br>
> p.<br>
><br>
><br>
>> -----Original Message-----<br>
>> From: mei-l [mailto:<a href="mailto:mei-l-bounces@lists.uni-paderborn.de">mei-l-bounces@lists.<wbr>uni-paderborn.de</a>] On Behalf Of Byrd, Donald A.<br>
>> Sent: Tuesday, July 04, 2017 11:26 AM<br>
>> To: Music Encoding Initiative <<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a>><br>
>> Subject: Re: [MEI-L] Coordinate system confusion [and terminology]<br>
>><br>
>> This reminds me of another source of coordinate system confusion, namely the term for the<br>
>> distance between staff lines. Verovio source code calls it a "double unit", and half that<br>
>> distance a "virtual unit" or "VU" or just "unit"; none of those terms is at all intuitive.<br>
>> Johannes calls it the "interline distance", which is much better, but rather long, and "half<br>
>> interline distance" is way too long (and clumsy). Well, look at Chapter 1 of _Behind<br>
>> Bars_. Her term is "stave-space", or just "space" for short; half that distance, of course, is<br>
>> a "half space". Ross' _Art of Music Engraving and Processing_, the only other book I<br>
>> know of that says much on the subject, just uses the term "space'. So, for example, both<br>
>> might describe a certain stem length as "2-1/2 spaces".<br>
>><br>
>> I submit "stave-space" (or "staff-space" on my side of the Puddle) as the full term and<br>
>> "space" for short are both the most standard and the best terms.<br>
>><br>
>> --Don<br>
>><br>
>><br>
>> On Jul 4, 2017, at 11:16 AM, Daniel Alles <<a href="mailto:DanielAlles@stud.uni-frankfurt.de">DanielAlles@stud.uni-<wbr>frankfurt.de</a>><br>
>> wrote:<br>
>><br>
>>> Thank you, Johannes, that really helped and made that clear. So I can continue using the<br>
>> Edirom-coordinates for ulx etc.<br>
>>><br>
>>><br>
>>><br>
>>> Zitat von Johannes Kepper <<a href="mailto:kepper@edirom.de">kepper@edirom.de</a>>:<br>
>>><br>
>>>> Dear Daniel,<br>
>>>><br>
>>>> that's a real confusion, and we need to make it clearer in the<br>
>>>> guidelines. *Pixel* coordinates are always with the origin in the top<br>
>>>> left corner. *Music* coordinates, however, are always bottom up. @ulx<br>
>>>> and so on are always in pixel units, but @vo (vertical offset) is<br>
>>>> specified in interline distances (half the distance between two staff<br>
>>>> lines, or, in other words, the vertical distance between a C4 and a<br>
>>>> D4, or any other two adjacent notes). If you want to specify that a<br>
>>>> dynamic is written above its default position, it seems more natural<br>
>>>> that values go up (i.e., @vo="3"). This means that for musical units<br>
>>>> the origin has to be bottom left. I know it's confusing in the<br>
>>>> guidelines, and we will address this at some point. If you don't<br>
>>>> mind, you're invited to prepare something on Git and submit a pull<br>
>>>> request ;-)<br>
>>>><br>
>>>> Hope this helps,<br>
>>>> jo<br>
>>>><br>
>>>><br>
>>>>> Am 04.07.2017 um 14:48 schrieb Daniel Alles <<a href="mailto:DanielAlles@stud.uni-frankfurt.de">DanielAlles@stud.uni-<wbr>frankfurt.de</a>>:<br>
>>>>><br>
>>>>> Dear all,<br>
>>>>><br>
>>>>> at the moment, I am a little bit confused about how MEI defines its coordinate system:<br>
>> It is possible to add the attributes @ulx, @uly, @lrx and @lry to for example a surface, as<br>
>> written in part 12 of the Guidelines, which places the origin of the coordinate system in the<br>
>> upper left corner. All the examples in that part show that behavior, ulx/uly is always 0/0.<br>
>> This would correspond to the coordinate systems used in SVG and DOM and (which is<br>
>> what I use for my work) Edirom Editor. On the other hand it is written in part 22.3, that<br>
>> MEI uses a coordinate system in which "the y-axis points from bottom up". That would<br>
>> mean, that ulx/uly could never be 0/0.<br>
>>>>><br>
>>>>> So now my questions: Is it sufficient to use the coordinates like in the examples, with<br>
>> the origin in the upper left corner? Would that "override" MEIs original coordinate system?<br>
>> If not: Isn't the possibility to encode areas from top-left to bottom-right corners a semantic<br>
>> error in MEI, if the coordinate system is pointing from bottom-left to top-right?<br>
>>>>><br>
>>>>> Best,<br>
>>>>> Daniel<br>
>>>>><br>
>>>>><br>
>>><br>
>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> mei-l mailing list<br>
>>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
>><br>
>> ---<br>
>> Donald Byrd<br>
>> Woodrow Wilson Indiana Teaching Fellow<br>
>> Adjunct Associate Professor of Informatics Visiting Scientist, Research Technologies<br>
>> Indiana University Bloomington<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> mei-l mailing list<br>
>> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
>> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
> ______________________________<wbr>_________________<br>
> mei-l mailing list<br>
> <a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
> <a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
<br>
---<br>
Donald Byrd<br>
Woodrow Wilson Indiana Teaching Fellow<br>
Adjunct Associate Professor of Informatics<br>
Visiting Scientist, Research Technologies<br>
Indiana University Bloomington<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" rel="noreferrer" target="_blank">https://lists.uni-paderborn.<wbr>de/mailman/listinfo/mei-l</a><br>
</div></div></blockquote></div><br></div>