[MEI-L] page sizes

[TW]

Me, too!

Thomas


2012/12/10 Laurent Pugin <laurent at music.mcgill.ca>:
> Hi Johannes,
>
> I am of course interested in participating to a SIG on layout questions. Who
> else?
>
> Laurent
>
> On Thu, Dec 6, 2012 at 7:55 PM, 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
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>