[MEI-L] page sizes

[Raffaele Viglianti]

I might not have too much to contribute, but I'd like to follow the SIG's
work closely. I am particularly interested in which role the layout module
could play for handling parts.

Raffaele


On Mon, Dec 10, 2012 at 11:28 AM, TW <zupftom at googlemail.com> wrote:

> 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
> >
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121210/c3ade997/attachment.html>