<div dir="ltr">
















<p class="MsoNormal">Hi,</p><p class="MsoNormal"><br></p><p class="MsoNormal">Here are a few thoughts for having a page-based encoding option in MEI. The idea is to make it possible to
encode the positioning of elements directly in the content tree. This can be
useful in some uses of MEI where the encoding represents one single source with
one image per page. It is typically the case with OMR, where the data is
conceptually organized by pages related to specific input images. Another use
can be to create overlay images to be displayed on top of a facsimile image
where the position of each symbols needs to be encoded. Whilst I am aware that
anything that can be represented with a page-base module could probably also be
represented with the current stage of MEI with a facsimile tree and references,
the page-based module would make it much simpler. It would also not preclude having
at the same time a facsimile tree with references if necessary.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">A page-base organization for specifying the position
directly in the content encoding tree requires two things. 1) The ability to
encode the document (pages) structure as the main tree, and 2) the ability to
specify positioning.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">1) For the document structure to be encoded, we need to have
page and system elements. The content of a score becomes a list of /page. Each
/page contains a list of /system. In un-measure music /system contains a list
of /staff. In measured music, we can imagine a) /system containing a list of
/staff containing a list of /measure (and then /layer), or b) /system
containing a list of /measure containing a list of /staff. Solution a) seems
more natural to me (if we think how music is written on paper, we first have
staves and then add measure). Solution b) has the advantage of being closer to
the standard MEI focusing on content. This needs to be discussed.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">2) For the positioning, we need to add attributes the
elements that can have a position. Basically, any element with the @facs. We
can solve this by making the att.facsimile class member of att.coordinated.
This provides us with the necessary @ulx, @uly, etc. for specifying the
position. We also need to specify to which image the position refers to. A
simple approach is to add a @surface to /page. As mentioned before, all this
does not preclude to use the standard @facs and facsimile tree scheme at the
same time, for example if a higher resolution image needs to be added for
specific elements. We also need to have a @unit in /page and presumably also be able to specify if the positioning is absolute or relative.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Another point to be discussed it if we want to keep this in
the score subtree or if such encoding could be put into another subtree. One
option would be a /pages element at the same level of /parts and /score. In
other word, this would be a third representation option in MEI.</p>

<p class="MsoNormal"><br></p><p class="MsoNormal">I already made a customization for unmeasured music and I am willing to do one for measured music for option a) or b) and when we agree where to put it. The sample file attached for unmeasured music was generated from the OMR output of Aruspix.</p>

<p class="MsoNormal"><br></p><p class="MsoNormal">Best,</p><p class="MsoNormal">Laurent</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal"> </p>

</div>