[MEI-L] Page-based encoding

Raffaele Viglianti raffaeleviglianti at gmail.com
Thu Oct 31 20:52:21 CET 2013

Hi Laurent, thanks for sharing this, a few comments:

On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin <lxpugin at gmail.com> wrote:

> 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.

It makes sense that when the page hierarchy is flipped, the system
hierarchy gets flipped as well, so that you can encode layout data on
systems too. Though I don't think the same logic applies to staff and
measure so I'd be tempted to go with b), because it would make switching
between a page-based encoding and a "standard" encoding easier.

> 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.

+1. Those would be good to have around even outside of a page-based module,
I think.

> 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.
Yes, I'd keep it in a different subtree, so that content can be linked in
the same file if necessary.

In general: I see why this approach to encoding is useful, though if we
make it part of MEI, we should make quite clear when it's ok to encode in
page-based fashion and when it's not. Basically we should discourage this
approach unless it's required for specific (scholarly, justifiable)


> 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.
> Best,
> Laurent
> _______________________________________________
> 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/20131031/806dc7a5/attachment.html>

More information about the mei-l mailing list