[MEI-L] page sizes

[Andrew Hankinson]

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