Staff styling, page dimensions, and measurement units

[clnoel]

We need a way to specify the type of paper or image sizes that a <score> is associated with. We also need a way to specify the default size/distance between staff lines on that page, and a way to override that in order to make staves that are small/cue-sized (or larger I guess), than the default.

This was originally listed in https://github.com/w3c/mnx/issues/185#issuecomment-948018127 as Out-of-Scope "C".

[clnoel]

Further comments from others about this include: @notator says in https://github.com/w3c/mnx/issues/185#issuecomment-951820471

The solution is to define the staff sizes using gap units - see point 2 in #185 (comment) above. A note about size dimensions: Each of your definitions is going to be used inside a different definition, so the gap lengths used inside the elements are going to have a different relation to the page size in each case. The staves in the Flute part-booklet(s) need to be bigger (larger rastral) than the staves for the flutes in the conductor's or pianist's scores. But the gap is still the unit of length inside all the definitions. Nobody has commented yet on this proposal. What do you think?

@ahankinson says in https://github.com/w3c/mnx/issues/185#issuecomment-951850634

MEI has vu (virtual unit) measurements, which are defined as "half the distance between the vertical center point of a staff line and that of an adjacent staff line."

Making it half of a staff height instead of a whole means that you're more likely to be working with integers, since there are a number of measurements and placements that use 1/2 height as a unit (such as the default placement of a slur end point below a note head).

Verovio uses this extensively to provide even scaling.

@notator says in https://github.com/w3c/mnx/issues/185#issuecomment-951883028

The most important things are that

• we agree that some kind of virtual unit must exist, and that
• we understand how it is going to be used.

How big it is is a matter of taste and convenience. (My gap would be twice as big as a vu.) Personally, I find it easier to visualize the distances I want to stipulate in terms of the whole "distance between the vertical center point of a staff line and that of an adjacent staff line.". I don't think that the distance "gap/2" has anything special about it. There are lots of places where other fractions are required: the size of small staves or font heights, for example.

Note that this topic is related to both <score> and <part> elements.

My own proposal (I think I made it in a previous issue, but I haven't tracked down which one) is:

1. Define each score with a designed "virtual unit" for both height (like either the MEI vu or @notator 's gap). and width (probably standard notehead width, but I can be flexible). These do not have to be the same, as long as they are both defined.
2. The units on the height and width can be px, pt, cm, mm, or in. (Please note that these cannot be relative in my proposal. You have to have something defining the units.
3. From this point, any measurement that is unit-less is using a virtual height unit or virtual width unit as its unit.
4. Optionally define a page-height and page-width. This can be in any of the above units, or a "unitless" multiple of the virtual height and virtual width.
5. From this point, any measurement that is a percentage is a percentage of the page-height or page-width (if they are not defined, then percentage units should be ignored!
6. Now, you can define margins and distance between systems on the <page> elements, probably as percentages.
7. Then, you can defined staff height and distance between staves in staff-layout elements, probably in virtual units
8. Finally, you can define measure widths, if you really want to, probably as percentages, in the <system> elements.

[notator]

See https://github.com/w3c/mnx/issues/248#issuecomment-958093102

[joeberkovitz]

I'm going to try to take on units in sufficient depth that this issue's resolution can ultimately be folded into the styles proposal #263. It can also inform the way in which dimensions are specified for scores, pages and layouts.

As background, I recommend reading at least this material on CSS units, since this problem has been thought about a lot already. We should not be trying to figure it out all over again in a different way.

• CSS Length Explained
• CSS Distance Units Specification

Referring back to both the CSS spec concepts and @clnoel's very helpful suggestions above:

• We need a set of absolute units for expressing distances in physical terms on various devices
• We need a a staff-line relative unit for expressing distances in terms of virtual height (a staff line)
• We need a font-relative unit for expressing distances in terms of virtual width (the width of some standard glyph)
• We need percentages of some dimension relevant to the context in which a value is being specified

This list is slightly different from @clnoel's because I am not prescribing a "units road map" that strictly proceeds from pages to layouts to systems. We will often need units at a fine-grained level (e.g. offsetting one end of a slur relative to a default location) in situations when we have no defined page and/or no defined layout. But the spirit of this list is the same.

Absolute length units

For absolute units let's adopt the existing CSS definitions of px, mm, cm, in, pt. All of these are ultimately keyed to the pixel unit px, which is defined as follows:

• For print media, a pixel is 1/96 of an inch.
• For screen media, a pixel is the whole number of device pixels that best approximates the reference pixel for the user. In turn, a reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length.

This definition is cribbed from the CSS specification; to understand better what it means in practice, please read the above-mentioned Mozilla article. Using an identical definition to CSS means that MNX implementations on the web can directly map from all MNX absolute units into browser pixels using simple numeric ratios, or no ratio at all in the case of px. Messing with this in any way will lead to a divergence between MNX absolute units and web-browser absolute units, creating horrible problems for web implementations since it is very hard to tell exactly how each browser interprets intentionally fuzzy terms like "reader" and "arms length". Different browsers have their own way of scaling pages and making use of font-size preferences built into the OS.

For non-web-based MNX implementations, the rendering application gets to figure out how to interpret the spec language. Despite the apparent (and purposeful) vagueness it's not all that hard; many multiplatform applications today figure out how to rescale displays on different devices based on a virtual unit scheme.

Virtual units

I propose the following virtual units:

• st: the vertical distance between the center points of of two adjacent staff lines
• vu: the same as 0.5st
• nb: the horizontal width of the noteheadBlack SMuFL glyph in the music font being used
• em: the desired height of glyphs in the textual font being used

Note that relative units are contextual. In contexts where no staff is defined (e.g. a page dimension) staff lines don't make sense.

Proportional units

Rather than allow % which immediately begs the question "percentage of what?", lets adopt explicit proportional units:

• ph, pw: percentage of page height, width
• sh, sw: percentage of system height, width

I do not think we should be using page height percentages in general, even for things like staff or system spacing. This is makes it necessary to have page dimensions in all cases, which I see as a mistake (see #266).

Default units

In all cases where the context defines the height of a staff line is defined, the default unit is st. Otherwise it is px.

[joeberkovitz]

Now that we have some units defined here and a proposed general method for handling style properties we can come back to the original goal of the thread, to tackle staff sizing and page dimensions. We'll begin with style property definitions and then offer a few examples.

page-size

• Values:
  • auto (it's up to the application and/or end user)
  • a4 | letter | legal | ... (i.e. one of the standard CSS paper size keywords)
  • portrait | landscape (can be combined with keywords)
  • 8.5in 11in (explicit absolute dimensions)
• Default: auto
• Inherited: yes
• Applies to: pages dynamically created as part of a <score>, and to any explicit <page>

  page-margin

• Values:
  • auto (whatever the app deems the printable area of the page)
  • 5mm (used for all 4 sides)
  • 5mm 8mm (top/bottom, then left/right)
  • 5mm 8mm 5mm 8mm (top, right, left, bottom - this is standard TRBL ordering for 4-value CSS margins)
• Default: auto
• Inherited: yes
• Applies to: pages dynamically created as part of a <score>, and to any explicit <page>

  staff-line-spacing

• Values:
  • auto (it's up to the application)
  • 10px (a distance in absolute units)
• Default: auto
• Inherited: no
• Applies to: staves in a score

Here is a toy document illustrating the way these can be used as per #263, including an override of the staff line spacing in the full score:

<mnx>
    <global>...</global>
    <part name="Violin">...</part>
    <part name="Viola">...</part>
    <layouts staff-line-spacing="8px">
        <system-layout id="violin-part">
            <part-layout part="Violin"/>
        </system-layout>
        <system-layout id="full-score" staff-line-spacing="5px">
            <part-layout part="Violin"/>
            <part-layout part="Viola"/>
        </system-layout>
    </layouts>
    <score name="Violin Part" page-size="A4" page-margin="8mm" system-layout="violin-part"/>
    <score name="Full score" page-size="A3 landscape" system-layout="full-score"/>
</mnx>

Notes:

• The reason that the properties are called page-size and page-margin is that these page properties need to be inherited to work nicely this way, while the more ubiquitous size and margin for various boxes and directions on the page can not be inherited, so dodging this bullet in advance here.
• If a <score> has explicit <page> elements to micromanage system breaks, text, titles and whatnot, then the page-size and page-margin properties could be attached directly to those <page> elements. This only makes sense insofar as pages in the same score have different paper sizes, orientations and margins, which seems a bit unusual.

[mdgood]

@clnoel @joeberkovitz In general MNX tries to consolidate places where MusicXML can represent things multiple ways into just one way of doing things. I am curious as to why the opposite approach is being taken here, with so many different measurement units being allowed where MusicXML only has one choice.

MusicXML generally has just one unit, the virtual unit of tenths of staff space, with a single optional conversion into a single physical unit (millimeters) via the <scaling> element. The exception is font sizes in points, and that might have been better done with tenths as well.

Could someone please provide more rationale for all the different units and mixtures of units being proposed here? It seems more complex than the MusicXML approach. That is fine if that is what is needed for MNX's use cases, but I am not understanding that connection yet. Thanks!

[joeberkovitz]

Really great question @mdgood. Actually I believe you are asking two questions. One is, why are there different families of units allowed? (absolute, virtual, proportional) The other is, in any given family, why do we need more than one unit?

The answers are going to be longer than I would like, so hopefully the entertainment value is worth it :-) It is worth going into this because these are not arbitrary decisions and I agree they haven't been fully explained.

I won't justify the need for virtual units since we agree on need for those.

So let's start with the rationale for absolute units:

• MusicXML takes the approach of privileging a single virtual unit, "tenths", and allowing it to be coupled to a physical unit via <scaling>. However, in scores with varying staff line spacings, "tenths" forces the selection of exactly one staff as the basis of a single unit for measuring everything. This feels arbitrary to me, because there's not necessarily a logical basis for saying one staff is "more fundamental" than another. Worse, for objects that don't live on a staff at all like page size or title text, it forces the odd hoop-jump of converting a physical unit into a virtual unit so that it can ultimately get converted back to a physical unit via the scaling factor.
• MNX in contrast permits physical units to be used everywhere, and virtual units to be used anywhere where there is a context where that virtual unit makes sense. So objects that are not on a staff can be simply defined in the physical units that make sense for them: pages in inches or mm, fonts in points or pixels
• MNX allows the sizing of different staves in a score to be defined in physical units without picking one as a reference point.
• MNX's virtual units are relative to the staff containing an object, rather than to some "reference staff". Consequently, within the notational content of any given staff, the virtual units for positional offsets, note sizes, etc. are always relative to the staff's size. This means this content can remain invariant even when the staff size is changed, in that none of the virtual units in that content need to be proportionally adjusted (as they would if they were expressed in "tenths" of the document's reference staff). Note that MNX's layout mechanism allows parts to be displayed in alternative layouts that may use different staff sizes for the same part, so this is not just a thought experiment.

Next: why do we have many flavors of physical units?

• It's just for the convenience of encoders. One could just pick mm for sure. But we have a world that is sadly not unified on the metric system. Since all the physical units are freely convertible into each other, it just doesn't seem like a big deal to be ecumenical about this and support the same ones as CSS. Just a bunch of scale factors. It feels nice to do US paper sizes in inches. It's nice to specify fonts in points or px.

Why do we have multiple flavors of virtual units?

• st and vu are just minor variations of the fundamental st. We could get rid of vu I suppose, the motivation was to be friendly to other interchange formats. Or we could add a new unit to represent tenths (although relative to the containing staff only) with the value of 0.1st.
• em and nb are useful virtual units that MusicXML lacks. em is actually useful when positioning text, since it is relative to the text font of an object and can vary depending on the font family. nb is just the music-font analogue of em, for a music font, allowing a measure of how wide or narrow the music font family is. Since the font and size are not necessarily speced in the document but could be dynamic, this is not just some calculatable ratio off of physical units or staff line size.
• If we really want to get minimal on virtual units, we could go with just st and em and leave the others for another day.

Why do we have proportional units?

• I would be OK with getting rid of them but I've seen some support for this idea already. For example when we eventually get into talking about text boxes interspersed with system flow, those sit on the page and it would be nice to say that the width is say 100% of the printable area.

I hope that was fun. More to the point, I hope it makes sense!

[mdgood]

Thanks @joeberkovitz! I agree that different flavors of the same unit that are scaling factors are no big deal. And I agree that the em and nb units can be useful for font-related data. We've had that requested for MusicXML in the past.

But I'm still confused about the "jumping through hoops" part regarding virtual units. This is the part of MusicXML that is perhaps more attuned to the needs of native formats than any other! The music notation software that I have worked with puts all or nearly all positioning and sizing in virtual units. Sometimes there are exceptions: e.g. Finale has fonts in points, while Sibelius uses staff spaces for even that. Scaling of differently-sized staves is done relative to a reference staff size, similar to how MusicXML does it.

For use in native applications, the much greater mix of absolute and virtual units seems like a step backward in convenience. It is striking since nearly everything else in MNX is a big step forward.

Of course this is influenced by the choice of native software that I've worked with, which is a small sampling of all the apps out there. (Although I didn't come up with the idea for MusicXML's scaling; that came from Doill Jung.) I'd like to hear from developers of native apps that use a similar mix of physical and virtual units similar to what is proposed for MNX.

[joeberkovitz]

This is great @mdgood. I'm really eager to hear what people think, thanks for kicking off this angle of discussion.

I do want to clear up one possible misunderstanding. This proposal doesn't ask apps to internally support an arbitrary mix of virtual and physical units. I agree, that would be a step backward. Any app that relies on virtual (physical) units can always convert MNX's physical (virtual) units on import to its preferred scheme. These conversions are not difficult, and are done already today by some apps when importing MusicXML. As you say, there is a mix of schemes out there. On export, apps and other encoders should always "export their own truth", expressing properties in the units that make sense for them. As an admittedly extreme example, it feels like a definite hoop-jump to make apps export a standard paper size in units that vary from score to score.

Anyway, very much looking forward to more feedback!

[cecilios]

@joeberkovitz I don't like the idea of using pixels (px) in MNX. Your suggestion that all absolute units are based on the pixel unit is true only for CSS that is mainly oriented to web pages, an thus pixel is the natural reference unit for CSS, that has to be converted for print media using a fixed conversion factor: a pixel is 1/96 of an inch.

To me, the situation with MNX is different. It is not oriented to web pages. It is a universal format not necessarily tied to web pages. Thus, the reference absolute units must be, IMO, a real physical unit (I would vote for the metrical system, more culture agnostic than the inches system) and all other absolute units must derived from the basic unit. Thus, converting real world units to presentation device units (pixels, dots per inch, or whatever) is an application dependent issue, based on presentation device, device resolution, desired resolution, scaling factors, zooming, etc., and not the opposite.

[cecilios]

@joeberkovitz I'm having fighting thoughts about nb. Your argument is that it is the equivalent to em for music. But space in music is not computed as space for texts, so I really do not find a use case for it: just to express the width of a measure? Probably the possible use cases are so marginal that it is not worth the costs introduced in having to deal with this new unit. What use cases do you have in mind?

As to multiple flavors for virtual units, I'm in favor of removing vu and use only tenths and em, for two reasons:

• A primary design goal for MNX is ease of migration from MusicXML, so it is a contradiction to see that MNX uses many virtual units but not ... tenths! Although the conversion between st and tenths is trivial, what is the need to change something well stablished that works? why MNX needs to change to st instead of continuing using tenths?

• Having many alternatives to express the same is an entry point for mistakes and errors, with no gain. So I would suppress vu.

[joeberkovitz]

@joeberkovitz I don't like the idea of using pixels (px) in MNX. Your suggestion that all absolute units are based on the pixel unit is true only for CSS that is mainly oriented to web pages, an thus pixel is the natural reference unit for CSS, that has to be converted for print media using a fixed conversion factor: a pixel is 1/96 of an inch.

@cecilios based on the above, I think you have misunderstood the units proposal, perhaps because I did not explain it well. The idea actually is not about being oriented to web pages, although we are borrowing a definition from CSS so as not to reinvent the wheel. I’ll try to restate it here.

For all printed output (as in exporting a PDF for some MNX document) all the physical units are just would you would expect in reality. An inch is an inch, a millimeter is a millimeter, etc. A pixel is defined as 1/96 of an inch by convention. But one could pick any of the units and say it is the fundamental one - the behavior would be the same. We could leave the pixel out of this scheme or include it. Since it’s a useful unit for screens, why not include it, if we’re going to have physical units at all.

For screen media it is different: units are adjusted proportionally based on the screen size and distance from the eye, and also for user preferences (some readers need a larger font size). The spec talks about pixels because we are borrowing the CSS definition, but it would work just as well with any other unit as the fundamental one - for example millimeters. The real goal is the proportional adjustment for different screens and for different human readers, not the adoption of the pixel as fundamental. So here again, changing the definition of the “main unit” to millimeters won’t affect the behavior. We could have said: “an inch is the whole number of device inches that best approximates the reference inch for the user. In turn, a reference inch is the visual angle of one inch on a device with a distance from the reader of an arm’s length.”

What I want to emphasize is that this idea of screen media is in no way unique to the web. If you are writing non-web mobile apps, or tablet apps, or any apps at all for any platform, these needs for adjustment based on device displays and readers needs are real and must be dealt with.

[joeberkovitz]

I am not wedded to nb but just added it for completeness in parallel with em since that is widely understood to be useful.

[clnoel]

I believe that it is important to have nb available. Among other things, sometimes items need to be aligned with the center of a notehead, or 1/3 of the way in. Having this as a reference value instead of pixels or mm (or even staff widths) would be enormously helpful.

In particular, we have run into this problem with precise positioning of articulations in MusicXML. The Finale font being used to generate the XML did not have the same staff height to notehead width ratio as our proprietary font and the precise relative locations was lost because of that.

[cecilios]

@clnoel Christina, thank you for the information about some problems that nb will solve. Then, I agree with using nb.

---

@joeberkovitz

pixels Lets' assume an imaginary MNX document that uses inches and pixels:

...
<aaaa width="96px"/>
<bbbb width="1.0inch"/>
...

When rendering it for print, as 1px = 1/96 of an inch, most programs will render both elements to have the same width. But when rendering for displays having a resolution of, e.g. a tablet with 240ppi or a cellphone with 581ppi, many programs will render both elements with different widths, sometimes aaaa wider than bbbb and other times the opposite, depending on the device resolution.

I'm just saying that using pixels is a source of problems, that there are many factors involved in properly rendering measurements in pixels, and that nobody in this group has raised a single use case requiring to use pixels a as unit. This requirement forces all producer and consumer MNX applications to deal with all the complexities related to using pixels as a unit (and are many).

To me it is a good approach to borrow from CSS, but not blindly. Let's use just what is good and convenient for MNX and not all other possibilities just because they are there. If I could choose, I would prefer not to have pixels in the MNX spec.

Many physical units It is a good idea that application user interfaces allow users to use the units they prefer. But MNX producer applications should not transfer the unit conversion costs to all MNX consumer applications. A file format does not need to support every conceivable physical unit. It is enough to support just one unit. Other arguments:

• MusicXML is doing a good job and does not use many physical units. Nobody has asked for more units.
• It would be wise to follow the KISS principle widely used in software development.
• Having to deal with many units, something as simple as using different scaling factors, is always a source of problems. Remember for instance, when the NASA lost its $125-million Mars Climate Orbiter because spacecraft engineers failed to convert from English to metric measurements. If NASA engineers failed on that, imagine how many MNX consumer applications developed by inexperienced people will fail!

[joeberkovitz]

Thanks for all the feedback so far. Before I follow up below with an amended proposal, it's important to correct two big mistaken perceptions that keep coming back to haunt this discussion. If we don't understand these points properly, it'll make it hard to have a useful conversation.

1. One big misconception is that the need for adjustable display units somehow has to do with "the web" or "CSS pixels". Nope, it comes from the fact that humans now use a wide variety of devices that are held at different distances from the eye, which have different form factors and perceptual characteristics. In mobile apps, all font sizes must be adjusted proportionally to reflect the characteristics of the device. If you're building an iOS app, you'll be doing this. If you're building an Android app, you'll be doing this. The web has nothing to do with this.

2. Allowing pixels as a physical unit on display media, does not mean that pixels and inches get out of step. In CSS, a pixel is defined as 1/96 of an inch. The proposed MNX spec (just like CSS) requires all physical units to be adjusted for display media uniformly, based on the device characteristics. This adjustment is needed whether the pixel is a supported unit or not. The important principle here is that all physical sizes must be adjusted to the device, by the same proportion so that their relationships remain the same.

You can test this yourself. Here's an HTML excerpt using @clnoel's example:

<html>
<head>
    <style>
.pxsize {
    font-size: 96px;
}
.insize {
    font-size: 1.0in;
}
    </style>
</head>
<body>
    <p class="pxsize">The quick brown fox jumped over the lazy dog</p>
    <p class="insize">The quick brown fox jumped over the lazy dog</p>
</body>
</html>

And here's how it renders. On every browser and device that I have tried, both text sizes look identical, which is what the CSS spec requires. On phones, the font size is of course much smaller than an inch if you take out your tape measure, which is the whole point of adjustable display media units: they are adjusted to subjectively "look the same" based on device characteristics.

[joeberkovitz]

On to an amended proposal. I will make this the absolute minimum that I think is necessary, and we can expand it from there.

Absolute length units

There is a single absolute unit: the display millimeter or dm.

It is defined as follows::

• For print media (e.g. printed output, exported PDFs, and onscreen print previews), a display millimeter is an actual millimeter on the page.
• For screen media (e.g. displays designed specifically for viewing on a screen), a display millimeter is the distance on the user's device which best approximates the visual angle of one physical millimeter on a screen display at a distance from the reader of an arm’s length. (See my previous comment for an explanation of why this adjustment is needed.)

Virtual units

I propose the following virtual units:

• st: the vertical distance between the center points of of two adjacent staff lines
• nb: the horizontal width of the noteheadBlack SMuFL glyph in the music font being used
• em: the desired height of glyphs in the textual font being used

Note that relative units are contextual. In contexts where no staff is defined (e.g. a page dimension) staff lines don't make sense. Conversely, every staff in an MNX score must derive its size from the value of its staff-line-spacing style property, even if this value is defaulted by the host application.

What was so bad about tenths?

It was not that tenths were so bad, but MNX does expand the set of use cases and it's worth re-examining whether a single staff-line unit is the best solution for this spec. Let me briefly defend the departure from MusicXML's practice of putting everything into tenths of some "reference staff line".

• Given the existence of multiple scores and layouts, it is very difficult to see how one is to bless one particular staff line as a reference for the others. Let us imagine an ensemble piece with a full score, and one score per part. In the full score, the staves are likely to be small so as to fit on a conductor's page, whereas in the parts, the staves will be larger for performer readability. Are we going to say that the parts are the reference size for the score, or is the score the reference size for the parts? Note that we cannot count on the formatting of the conductor's score being defined first in the authoring process.
• There are many objects in a score definition such as paper sizes and title text that do not have any logical relationship to a staff. Apparently some notation editors force such objects to be sized in terms of staff lines, but not all of them do.
• In MusicXML, I believe the only way to assign a staff a different size from the others is via the <staff-size> element. However, the behavior of this adjustment with respect to positional offsets within that staff is undefined. Are vertical offsets in "tenths" within a 75%-size staff adjusted to be 75% of regular tenths? I would think that making a staff proportionally smaller, should adjust such offsets accordingly. In MNX, these are adjusted by definition, since there is no reference staff, only the current staff in which some offset is used.

[cecilios]

@joeberkovitz I agree with your latest proposal, except on the name dm.

I really appreciate your deep thoughts to structure music representation and value your opinions on this matter. My English is not good enough, so when you wrote "For absolute units let's adopt the existing CSS definitions of px, mm, cm, in, pt. All of these are ultimately keyed to the pixel unit px" probably I didn't understood correctly (and probably still do not understand) the meaning of "ultimately keyed to the pixel unit". I still believe that in MNX the situation is the opposite: we are dealing with printed documents (physical dimensions) that ultimately will be rendered on displays. Thus, pixels are keyed to physical units and not the opposite. This is why I mentioned this and CSS.

it's important to correct two big mistaken perceptions that keep coming back to haunt this discussion.

Being myself the only one that has given opinions about CSS and pixels, it seems that you perceive that I need clarifications on different concepts related to pixels. I appreciate your explanations and thank you for taking the time to write them but, really, I do not need them. I'm perfectly aware of all these terms and of the problems created by using pixels as a measurement unit in applications (GUI design) and web pages. And that is the main and only reason for trying to avoid its use in MNX.

As it can be read in your referred web page, it recommends to use "density-independent pixels (dp)" (instead of px). As pixels depends on devices, using pixels as measurement units causes a lot of problems. The "modern" solution to avoid them is to re-interpret measurements in pixels as density-independent pixels. But, belive it or not, this operation is a source of problems.

As, to my knowledge, no body has requested to use pixels, I argued that it is better not introduce this measurement unit. Apart from many explanations about different concepts, I've not seen yet any argument to defend its introduction, but fortunately, pixels been removed in your latest proposal. Thank you.

As to the dm, I'm not sure it is a good idea to talk in the spec. about display millimeter (or display inch, or whatever units are finally chosen). If the spec talks about display xxxx it is necessary to define it (as you did in your proposal) but talking about "the distance on the user's device which best approximates the visual angle of one physical millimeter on a screen display at a distance from the reader of an arm’s length" will only make the spec. harder to read and might create doubts on the readers. Application developers must not think in terms of viewing angles or arm's lengths. They just must ensure that all distances and lengths are comparably scaled. It doesn't matter what is the real measurement of one dm in the user display as perceived at a distance from the reader of an arm’s length. The user will apply zooming and scaling factors if not satisfied with the appearance.

So, I would suggest about replacing dm by mm (or inch or what the group prefer) as it is more legible and will avoid having to write a long description about it. But do as you prefer. I'm not going to argue on this.

[joeberkovitz]

@cecilios thanks for clarifying. I am sorry if I assumed that you did not understand something that in fact you do. I believe that you are saying, you do not want any display-independent units at all. You would like all absolute units to be interpreted as true physical measurements, assuming that printed output (or an exact onscreen replica of what would be printed) is the way that notated music will be rendered.

That is certainly one way we could go. It would be great to hear from others, particularly from those involved in the notation editing world. As I think is clear by now, I think this project cannot afford to focus exclusively on printed output. It risks addressing MNX to an earlier paper-based era of digital music notation, instead of the present era in which mobile devices are ubiquitous, and are used to both consume and edit music notation in formats that are quite different from a rescaled printed page.

Of course we'd prefer not to add spec language that seems more complex than just, "a millimeter is a millimeter is a millimeter". But by not addressing mobile devices and display scaling, we will actually invite app developers to make up their own solutions to this problem, rescaling things any old way they like. In my view this is likely to lead to a sort of Wild West in which everyone does their own thing.

[mdgood]

@joeberkovitz But we already have a proven scaling approach in MusicXML, where everything (except font size) is in virtual units, and there is an optional conversion to an initial scaling factor in physical units. We don't have a scaling issue and there is no Wild West.

I agree with Cecilio in wanting only a mm unit for a physical unit, but go further and only want that unit used in a single reference scaling element. Screens and paper have the same issue with readability based on distance from the musician, so I don't see the need for any different treatment of physical units between the two. What is different in screen-based music is that scaling can be so easily adjustable, which seems to make physical units even more secondary than they are for print.

Regarding tenths and scaling, the MusicXML spec for tenths states that "When a MusicXML element or attribute refers to tenths, it means the global tenths defined by the element, not the local tenths as adjusted by the element." I would prefer seeing something like tn for tenths of staff space instead of st for both MusicXML compatibility and greater ability to use integers, but either way has its advantages.

In the score / parts scenario, the scaling of staff size to physical units is one of the things that will often change between score and part layouts. Commonly, font sizes do scale with staff size between score and parts, but for some cases like MusicXML credits they may not. So maybe we do keep point size as a physical unit for fonts like MusicXML does, or we add something to the MNX version of credits to handle this case.

In 20 years of MusicXML use I really cannot recall anyone asking for greater use of physical units. Instead the requests have been the other way: to replace the one physical unit in MusicXML (font point size) with virtual units - though that has issues - and to add new virtual units such as the nb proposed here. We can't replace font point size in MusicXML due to compatibility constraints, but MNX can if we want.

Again, this is one part of MusicXML that is most closely matched to how many notation applications already work on both web and desktop. As we build a format for native application use, we find areas like this where not every application works the same way internally. But as MNX does everywhere else, we don't want to design by including a union of how apps work. Instead, we pick one way that matches how a lot of apps work, preferably as simple as possible, and that should be fine. We can always add more features later but it's more difficult to remove them once in.

Of course we don't want to be any simpler than "as simple as possible" - hence the inclusion of additional virtual units. But I still don't see a use case for increased use of physical units compared to MusicXML beyond incompatibility with some existing apps, which I don't think is sufficient.

[joeberkovitz]

Thanks @mdgood for the further explanation of the point of view that you expressed earlier.

I do not think we’re all that far apart. I think we could rename the physical unit to mm. At some point app developers will be forced to apply some notion of display scaling to that and we can try to give them a guideline (as I prefer) or leave out that language (as you and @cecilios would prefer). It may not make that much difference. I’d still love to hear at least from the other co chairs on this point.

I agree that most developers will be using virtual units for all elements within a staff. To your short list of “maybe only font sizes are physical” I would add paper size, margins, and text block sizes for text that lives outside of any staves.

However I am still troubled by the idea that there is one global virtual staff line unit across stages of different sizes (and in different layouts!). Seems to run counter to the whole idea of layouts.

Could you respond to the question of how we define a reference staff size when there may be multiple layouts that use different staff sizes (full score vs parts). It seems so much cleaner to me to define virtual units in terms of physical ones.

[mdgood]

@joeberkovitz I thought I did answer the reference staff size question. We could define the <scaling> element or its MNX equivalent on a per-layout basis if needed. I'm sure other approaches could work too.

[joeberkovitz]

Ok, thanks for clarifying, I must have missed It. I would suggest making the virtual unit scaling factor itself into a style property (and thus specifiable at the layout level, or below). This would seem to afford the best of both worlds.

[joeberkovitz]

@mdgood Can you clarify something for me about MusicXML 4.0? You may have already answered but I want to make sure I get it before offering another revised units proposal, and I want to make sure others understand it too. I'll use a test case to illustrate the question.

Let's say we have a 75% size staff on a system (I'll call this a "cue staff"), along with others of 100% ("regular staves"). As I understand it — you said this above — all positional offsets for objects in the cue staff are going to be expressed in tenths of a regular staff line space, not in tenths of the cue staff containing the object.

Now let's say we have a series of dynamics that we want to position directly above successive notes E, G, B, D, F, etc. on a treble-clef staff. These will have default-y offsets of -40, -30, -20, -10 , 0. Easy relationship: it's exactly 10 tenths per staff line.

Let's now assume that the cue staff contains an exact visual copy of the above notation. What are the Y offsets of the dynamics? It seems that, since positions are always the answer is -30, -22.5, -15, -7.5, 0, because of the smaller scale of this staff. Is this correct? Related to that, do we feel that this is how applications internally represent such offsets on a cue staff, given that the size of a staff can presumably be adjusted without re-creating all the content inside of it?

This question has a large bearing on the way things go from here with units, and I want to make sure we are on board with whatever the answer is before moving forward.

Thanks @mdgood and everyone for thinking about this carefully.

[mdgood]

@joeberkovitz Yes, your understanding of how MusicXML 4.0 works is correct. That doesn't mean that's how MNX should do it, as long as the virtual units are clearly defined. In MusicXML it makes sense since virtual units are used for everything, and for an exchange format the match to native storage doesn't matter so much.

I would guess that apps tend to use local virtual units for positions related to a staff or system, and global virtual units for measurements outside of a staff or system, such as page sizes and credit locations. If people have apps that do otherwise (for those that use virtual units nearly everywhere) that would be great to know.