[MEI-L] page sizes

[Laurent Pugin]

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
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20121210/3698b11d/attachment.html>