[MEI-L] Layout discussion

[Eleanor Selfridge-Field]

I'm lurking too and pass on one practical issue: web browsers.  I've been
noticing recently that
Chrome has trouble resolving the printing parameters of attachments
received on A4 paper (it may be the reserve elsewhere).  Presumably some
intermediate software will always stand between MEI and any screen
display.

For me screen layout is the next question after page layout.  Instinct
tells me that separate semantic content from all layout and rending
questions is the better path.  The SCORE approach may be instructive: the
program uses virtual units to etablish the desire aspect ratio.  It also
has a virtual relationship to the physical page.  Note though that in the
music printing industry page sizes may not have the same aspect ratio as
those used with desktop printers.  (AT the AMS I had a discussion about
this with Douglas Woodfill-Harris from Bärenreiter.)

Eleanor


Eleanor Selfridge-Field
Consulting Professor, Music (and, by courtesy, Symbolic Systems)
Braun Music Center #129
Stanford University
Stanford, CA 94305-3076, USA
http://www.stanford.edu/~esfield/








-----Original Message-----
From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
[mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
Behalf Of Byrd, Donald A.
Sent: Friday, November 09, 2012 11:22 AM
To: Music Encoding Initiative; Johannes Kepper
Subject: Re: [MEI-L] Layout discussion

I'm just emerging from a long period of lurking -- with a lot of ignoring
:-| . I (for one) would love to see "a thorough introduction of our layout
tree proposal and its specific qualities."

--Don


On Thu, 8 Nov 2012 14:45:11 +0100, Johannes Kepper <kepper at edirom.de>
wrote:

> Don't blame it on me ? some of you requested to have the following
> discussion completely in public, and I think we should follow that
> suggestion. I expect this thread to be somewhat lengthy. What we
> should try to resolve is how MEI deals with layout-specific
> information, its relationship to the semantic parts of MEI, separating
> out layout info in a similar way than CSS does for HTML, relationship
> of various units (and types thereof), page-based approaches to MEI
> etc.
>
> I will try to summarize the model I briefly introduced in New Orleans
> last week. I would love to see Laurent replying to that, ideally with
> a thorough introduction of our layout tree proposal and its specific
> qualities. This should introduce lurkers to our current state, and
> from there, we can refer back to our proposal from last week and see
> where the discussion leads us?
>
> The basic situation is that we want to preserve differences between
> multiple sources. The most obvious way for doing this is to use the
> <app> / <rdg> elements, which provide a very intuitive way for doing
> so. But, as soon as we also want to preserve detailed information
> about layouts, we have to add many more attributes to each note etc.,
> so it becomes more likely that differences between the sources will
> result in additional <app>s and <rdg>s. Eventually, this will lead to
> a separate <app> / </rdg> for almost every note. While this is still
> possible, it might be regarded as somewhat impractical. The
> alternative for this is to use one file, let's call it common.xml, to
> store all the commonalities between the sources, but also the most
> important differences. Basically, this file contains only @pname, @oct
> and @dur for every note. It will split up into <app>s and <rdg>s where
> the sources differ in this regard, but it will not consider stem
> directions, exact positioning etc.
> Every single source is also represented by a separate file, let's call
> it sourceXY.xml. These files do not contain <app>s and <rdg>s at all,
> they just reflect the musical text as given in the according source.
> They contain elements for all notes etc., but they omit the basic
> attributes as specified in the common.xml. Instead, they use a
> reference to the corresponding elements in this file. Here's an
> example:
>
> common.xml:
> <note xml:id="noteX" pname="c" oct="4" dur="1"/>
>
> sourceXY.xml:
> <note stem.dir="up" sameas="common.xml#noteX/>
>
> It is easily possible to point to a note within a <app>/<rdg> in case
> the basic parameters already differ.
>
> With this strategy, layout information can be separated out quite
> completely. <sb/> and <pb/> are stored only within the sourceXY.xml
> files (though they could be provided in the common.xml within <app>s
> and <rdg>s as well). If one wants to extract a source file completely,
> he just has to resolve all pointers. This is cumbersome when doing
> manually, but with an xml database and an index on xml:ids, it
> shouldn't be too hard. Also, it is still possible to extract
> information about differing stem directions etc., but it requires more
> processing than the <app>/<rdg> approach. Basically, this is a
> compromise somewhere in the middle between source separation and
> integration, which tries to address the most common cases in the most
> convenient way, while accepting some additional hurdles for corner
> cases. Of course it is open for discussion which attributes should go
> in the common.xml, and which attributes should be separated out to the
> individual source files.
>
> The benefit of this approach is that it completely relies on existing
> MEI ? it does not require any further additions to the standard and
> works "out of the box".
>
> But, it does not address all requests catered for with a distinct
> layout tree, which I hope Laurent will introduce.
> jo
>
>
>
> _______________________________________________
> 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 & Music Indiana University,
Bloomington


_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de
https://lists.uni-paderborn.de/mailman/listinfo/mei-l