[MEI-L] page sizes; break discussion down? Layout SIG?

[Byrd, Donald A.]

I've been trying for the last few weeks to figure out how to contribute 
to the discussion. One thing I've been doing is writing something about 
Nightingale's use of coordinate systems, including units, but not yet 
covering page layout, which (as you say) is an issue that can be 
separated out.

Anyway, I think your ideas are super, Johannes! -- both separating 
discussion into "more digestible" chunks and establishing a Layout SIG. 
My future is still very unclear, but I'd like to participate in it, and 
at the moment, it looks like I'd have time.

--Don


On Thu, 6 Dec 2012 19:55:29 +0100, Johannes Kepper <kepper at edirom.de> wrote:
> Hi all,
>
> there are so many different approaches, models, proposals etc. that I
> completely lost my overview. It would be great to hear Craig's
> response regarding CSS for music, but the general intention of most
> of these things seems to be the wish for a clearer separation of
> content and rendition in order to allow multiple renditions from the
> same source content.
>
> While I appreciate the discussion so far, I wonder if we couldn't
> break it down to more digestible issues. The question of units and
> their relationship seems to be such an issue. The possibilities of
> expressing pages in MEI seems to be another. Adopting a common
> algorithm, it seems the whole discussion would be easier to conquer
> when we divide it? At the same time, we need to make sure that we
> keep all the bits and pieces together. I would suggest to establish
> something like an MEI Layout SIG (special interest group), which
> coordinates the discussion of this. This group should also consider
> to apply for a session and maybe an additional workshop at the
> conference next year in May, as this seems to be an ideal time frame
> to prepare and discuss these issues. Hopefully, there will be a large
> part of the community available in Mainz, so we could take decisions
> there. Who would volunteer to participate in such a group, and what
> modus operandi would you suggest?
>
> Johannes
>
>
> Am 06.12.2012 um 18:29 schrieb Laurent Pugin:
>
>> Hi Craig,
>>
>> Thank for the very detailed report. I particularly like the randomly
>> placed staves of figure 7 ;-)
>>
>> There is certainly some interesting information about spacement,
>> especially vertically. This is closely related to the discussion we
>> had about units, and I agree that we can probably find a better name
>> than interline. I am not sure about the use of horizontal placement
>> system outside Score, though.
>>
>> For the general organization of the music, it is actually very
>> similar to what we have in Wolfgang (the music notation software
>> create by Etienne Darbellay, on which Aruspix is partially based
>> on). Maybe not surprisingly since they are from the same generation.
>> I don't really see how this can become a CSS for music. Could you
>> tell us more about it?
>>
>> As I understand it, it would be fairly similar to what we would like
>> to achieve with the layout module in the sense that separating
>> content and presentation is what CSS does. A difference with the
>> layout module is that we have an additional level in the hierarchy,
>> namely the systems. In Score (as in Wolfgang), we have staves
>> directly within a page, because this is enough for representing
>> them. This is a very economic way of representing a page of music
>> and it maybe has to do with the memory limitations they had when
>> they started these software applications. I am not sure this would
>> be optimal for MEI, and this is why I change the internal
>> representation in Aruspix.
>>
>> As I said, the layout module was proposed for two reasons, 1)
>> because a page-based representation did not seemed to be an
>> interesting option at that time, and 2) because it does offer a
>> separation between content and presentation (i.e., we can have
>> several presentations for the same content). This second argument
>> seems to be appealing to several of us. I must confess, however,
>> that implementing it is quite of a challenge. I am a little be
>> concerned that because of this, it will become a very powerful
>> solution that will not be used beyond simple cases because of the
>> complexity involved. It works well with Renaissance music since the
>> general score organization is simple, we should be able to go beyond
>> this proof of concept. As we already discussed, maybe re-considering
>> a page-based representation is a way to go. This does not mean that
>> the layout module cannot exists in parallel. But I can see a fairly
>> direct path from the Score representation as described to a MEI
>> page-based representation, and this can very well be useful to you
>> Craig, as it would be for OMR people and maybe others who would like
>> to have a very detail source encoding. What do you think?
>>
>> Best,
>> Laurent
>>
>> On Fri, Nov 30, 2012 at 4:40 AM, Craig Sapp <craigsapp at gmail.com> wrote:
>> Hi Everyone,
>>
>> In case you were eagerly awaiting it, attached is the final version
>> of my analysis of staff placement in SCORE.
>>
>>
>> SCORE data itself has no concept of physical units (with some minor
>> caveats), so it would be a good model to observe.  The physical
>> units are defined at the last minute when you are ready to print,
>> and are not defined while editing the music in the SCORE editor,
>> which matches the idea which you are headed towards.
>>
>> See page 50 of the attached PDF for example default spacings in
>> SCORE which is a good basic roadmap to how default spacing units are
>> defined in SCORE.
>>
>>
>>
>> > This interline distance (which is already used by MEI) is a
>> musical unit which describes
>> > half the distance between two staff lines,
>>
>> I complain about how you are defining "interline".  Interline is
>> Latin for "between lines", not "halfway between lines".  This will
>> cause continual confusion, such as losing your spacecraft:
>>     http://mars.jpl.nasa.gov/msp98/news/mco990930.html
>> How about "@semiline", "@hemiline", or "@demiline" instead?   Or
>> maybe "@halbline" :-)
>>     http://www.dailywritingtips.com/semi-demi-and-hemi
>>
>>
>> * The nominal physical length of scoreDef/@interline.size in SCORE
>> is 3.15 points (0.04375 inches, 1.11125 mm).  This is when you print
>> out the music using the default staff scaling and print size.
>> Vertical values are always represented by this step size, and the
>> data files themselves do not indicate that the final physical
>> rendering is at 3.15 points (which is why I had to measure it off of
>> the example on page 50).
>>
>> * So in SCORE, the distance between two staff lines is 2.0 "steps".
>> And this means that the height of a staff is 8.0 steps.  Every staff
>> has an independent scaling factor which only affects the vertical
>> dimension (there is no staff-level scaling for the horizontal
>> dimension).   So if a staff has a 50% scaling, all of its steps
>> would be 1/2 of the size of the nominal height.
>>
>> * The default "successive staff spacing" is 18.0 steps, so there are
>> 18.0 - 8.0 = 10.0 steps from the top of one staff to the bottom of
>> the next.  This default spacing is the framework over which
>> individual staves may be scaled.  This framework is also how SCORE
>> avoids using physical measurements to place individual staves
>> vertically on the page.  Staves can be placed anywhere vertically,
>> but their placements are in relation to their default positions.
>> For example, a staff could be placed 15 steps above the top of the
>> staff below by adding an extra offset of 5 steps to its default
>> position (In SCOREese, set P4=5 for the top staff).
>>
>> * The staves each have their own scaling factor (called the staff's
>> P5 in SCOREese).  If P5 is 0.5, then the local staff's step size is
>> now 1/2 of the default step size.  This scaling factor only affects
>> the height of the staves, not the length of the staves.  Object
>> placed on a staff will have the staff's P5 scaling applied to their
>> horizontal and vertical dimensions (they will shrink by 50% if the
>> staff is scaled by 50%), their vertical placement will be scaled as
>> well, but not their horizontal placement which is independent of the
>> staff scaling.  Note that changing the scaling of a staff does not
>> affect its default position on the page, but if there is a vertical
>> offset from the default position, that offset will be scaled.
>>
>> * The horizontal distances in SCORE are described on a different
>> scale than the vertical distances.  They are described as the
>> fractional position along the left/right sides of the default staff
>> length.  The nominal length of a staff is 7.5 inches.  This length
>> is divided up into 200 units, so the left side of staves are at 0.0,
>> and the right side is at 200.0.  A length of 540 points (7.5 inches)
>> divided by 200 is 2.7 points, so "200" was probably used to give an
>> approximately equivalent unit to vertical steps.  It would have been
>> more elegant to set the default horizontal and vertical units to be
>> the same by using a different vertical scaling...  In any case the
>> horizontal units are 6/7 of the vertical step units, so if you set a
>> staff's scaling to 6/7 (85.71428...%), the horizontal units will
>> match the vertical steps locally for that staff.  Another way of
>> thinking about the relationship between the horizontal and vertical
>> units in SCORE is that the default length of staves is 171.428...
>> steps long.  So all vertical and horizontal units can be related and
>> a final scaling can be given to match to the specified @interline
>> physical distance between steps.
>>
>> * horizontal units cannot be scaled within the SCORE editor, and can
>> only be scaled at print time, such as to match the staff lengths to
>> the distance between page margins.
>>
>> For final placement on a physical page, there are three important values:
>>
>> (1) The distance from the left side of the page to the left side of
>> the staff (the "left margin", although the system brackets will fall
>> into this margin, so not exactly the same as a text margin).  The
>> default left margin is 0.5 inches (plus a fixed extra 0.025 in).
>>
>> (2) The distance from the bottom of the page to the bottom line of
>> the first staff.  This is also not exactly a "margin" in the text
>> sense, since notes/slurs/dynamics can fall within this bottom
>> margin.  The default bottom margin is 0.75 inches (plus a fixed
>> extra 0.0625 inches).
>>
>> (3) The page scaling.   This is the method to control the horizontal
>> scale which is not possible within the SCORE editor (other than
>> trivial zooming).  But the page scaling will also affect the
>> vertical scale at the same time.  The origin for the page scaling is
>> the point defined by (1) and (2) above.  In other words the page
>> scaling does not affect the page margins, but rather only affects
>> the scaling of the music (you have to scale the music so that it
>> falls at the correct top and right margin positions on your page.
>>
>> Notice that only two margins are defined when printing from SCORE.
>> This perhaps gets to the point that Andrew was trying to make:
>>
>>
>> >  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.
>>
>> SCORE uses a single origin when printing the music on a page (left
>> and bottom margins).  And it is up to you to scale the music to
>> correctly fit within the top and right margins of your desired paper
>> size (or screen size, e-reader size, etc.).  This could be done by
>> specifying the top and right margins instead of scaling, but
>> page-level scaling and top/right margins cannot be controlled
>> independently in SCORE.
>>
>>
>> -=+Craig
>>
>>
>>
>
>
> _______________________________________________
> 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
Indiana University, Bloomington