[MEI-L] page sizes

[Byrd, Donald A.]

I've been thinking about this issue. There's something about it I don't 
understand, but I can't figure out what it is; so I'll go ahead as best 
I can.

Laurent, Perry and Johannes' ideas generally make a lot of sense, but I 
think Andrew's point about the problem with physical units for editions 
meant for digital consumption is a good one. It seems to me we should 
think in terms of three categories of units:

1. absolute units, well-defined: inch, cm, mm, point, pica, etc.
2. absolute units, ill-defined/variable: pixel
3. relative units: distance between staff lines; percent of display width

My CWMN editor Nightingale is a real-life example (though admittedly 
it's not nearly as flexible as what MEI needs). To oversimplify 
slightly, internally, Nightingale keeps coordinates of musical symbols 
relative to their system in terms of either of two units: one absolute 
(DDIST) and one relative (STDIST).

* DDIST = 1/16th point = 1/1152nd inch (assuming a point is exactly 
1/72nd inch, which is not exactly the traditional value)

* STDIST = 1/8 the distance between staff lines

Nightingale assumes it's displaying music on a conventional page; it 
gets the page size from the operating system and keeps margins in... 
well, some absolute units; I can't find the code at the moment.

Finally (and I suspect MEI already handles this), I'd like to point out 
that two sizes of staves -- "normal" and "cue-size" -- aren't always 
enough; there are published performing editions that use three staff 
sizes. (In fact, I wouldn't be surprised if editions with _four_ sizes 
exist, though I don't know of any.)

I'm not sure if this is helpful, but I hope so.

--Don


On Fri, 2 Nov 2012 20:33:18 -0400, Andrew Hankinson 
<andrew.hankinson at mail.mcgill.ca> wrote:

> The concept of "physical" unit doesn't really translate well to
> editions that are meant for digital consumption only. If I have a
> page meant for a tablet or digital music stand display, what does the
> "inch" unit mean? Does it mean render it as a physical inch on the
> screen, regardless of how many pixels it takes to represent it? Or
> does it mean render it using a fixed number of pixels-per-inch,
> regardless of how large or small it makes it from one display to
> another. E-ink displays challenge this concept, since they don't
> really have pixels, and high-resolution displays also challenge it
> since the number of pixels it takes to represent a single physical
> unit can be completely different. So we'll probably need some sort of
> proportional unit so that we can say that the page margin is a
> percentage of the rendered display rather than a fixed unit of
> physical measurement.
>
> I would suggest looking at the CSS3 documentation for how they deal
> with proportional and physical sizes, since they support both.
> Apparently their baseline unit is "ch", which is the width of the "0"
> when rendered in a given font. That seems to be a good analogue to
> the inter-staff space measurement.
>
> Also relevant to this discussion, in case it was forgotten:
>
> http://code.google.com/p/music-encoding/issues/detail?id=73
>
> -Andrew
>
> On 2012-11-02, at 7:19 PM, Johannes Kepper <kepper at edirom.de>
> wrote:
>
>> Dear all,
>>
>> during discussions at the AMS meeting in New Orleans, we came up
>> with a couple of issues we'd like to discuss.
>>
>> The current definition of page sizes expressed in real-world units
>> and the relationship to musical units is less than ideal.
>> Especially, the @page.scale attribute on <scoreDef> causes some
>> confusion. Right now, it allows expression of the relationship in
>> the format "1:1.5", but "50%" is also allowed. The directions for
>> scaling are not absolutely clear from the current documentation.
>>
>> Rather than explaining the current situation, I would like to
>> introduce our proposal for a better definition:
>>
>> scoreDef/@page.units (pre-existing, but maybe better called
>> @page.unit) will define the real-world unit used to describe pages.
>> It allows 'cm', 'in', 'mm'.
>>
>> scoreDef/@page.rightmar and other margins take decimal numbers and
>> will use the unit defined in @page.units to describe all kinds of
>> margins on the page. This explicitly includes the distance between
>> two staves, independent of their size (see below).
>>
>> scoreDef/@interline.size will replace the current @page.scale. It
>> will hold the decimal number of real-world units (using @page.units)
>> matching one interline distance. This interline distance (which is
>> already used by MEI) is a musical unit which describes half the
>> distance between two staff lines, or using a different description,
>> the distance a note head moves when stepping up a second. For
>> instance, an @interline.size of "1.2" and a @page.unit of "mm" would
>> say that the distance between two staff lines is 2.4mm, or the full
>> height of the staff is 9.6mm. This assumes, of course, that the
>> distance is measured from the middle of the individual lines and
>> disregards the thickness of the lines themselves. The guidelines
>> don't say anything about this yet, but at least to me, it seems
>> easier to leave that out of the calculation. If we really want to
>> say something about the thickness of the line, it can be done later
>> on using a different attribute (eventually, the thickness might
>> change almost everywhere for manually drawn staff lines).
>>
>> It is open for discussion to what degree this interline distance can
>> be made the default in certain contexts. For instance, the
>> description of @width says it needs the value of @unit, specified on
>> the same element, in order to be processed correctly. This means
>> that every measure specifying its width also needs to specify the
>> corresponding unit. While interline distances might be a reasonable
>> default here, it is certainly not for page/@width. This is clearly a
>> separate issue, but it is closely related, and should be given
>> additional consideration.
>>
>> For cue-sized staves, the existing staffDef/@scale can be used to
>> specify the size as a percentage of the default. The data type for
>> this should also allow the value "cue" for cases where you don't
>> want to be extremely precise about the exact size of the staff. Then
>> again, a new scoreDef/@cuesize could be used to specify a default
>> for cue-sized staves. Considering the question of scope (does this
>> affect the size of cue notes in addition to cue staves?), one could
>> make an argument that it should be @cuesize.staff and @cuesize.note
>> instead.
>>
>> It also should be made clear in the guidelines that the
>> staffDef/@scale does not affect margins at all, as they should
>> always be measured in real-world units (see above).
>>
>> It would be great to get some feedback on all this, especially from
>> people with engraving experience?
>>
>> Best regards,
>> Laurent, Perry and Johannes
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>



--
Donald Byrd
Woodrow Wilson Indiana Teaching Fellow
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington