[MEI-L] page sizes; multiple staff sizes; def. of point

[Raffaele Viglianti]

Dear all,

I side entirely with Andrew on this one. I think real-world units become
useful as part of the encoding only if they are describing a physical
source (after all we want to use MEI for document encoding). Information
about rendering and printing should live somewhere else.

Best,
Raffaele


On Thu, Nov 8, 2012 at 10:43 AM, Andrew Hankinson <
andrew.hankinson at mail.mcgill.ca> wrote:

> Perhaps I'm muddying the waters, but should we start looking at ways of
> further separating the musical structure from the actual appearance? More
> specifically, using CSS to control the appearance of elements, rather than
> interweaving the visual and semantic structure.
>
> For instance, page margins, staff sizes, cue sizes -- all of this could be
> specified in a different style sheet for different media: print, tablet,
> mobile phones, web browsers, etc. A print style sheet could specify in
> points or inches; a display stylesheet could specify in pixels, ems, or
> proportions. Different media will have different presentation needs, and if
> we're to make sure that MEI can operate in both the physical and digital
> worlds simultaneously, this question will become more important, not less.
>
> I'm not *completely* convinced of this since it does complicate lots of
> things, but I think it's worthy of at least a bit of discussion.
>
> -Andrew
>
> On 2012-11-07, at 5:27 PM, Laurent Pugin <laurent at music.mcgill.ca> wrote:
>
>
>
> On Wed, Nov 7, 2012 at 10:25 AM, Byrd, Donald A. <donbyrd at indiana.edu>wrote:
>
>> On Tue, 6 Nov 2012 21:49:55 -0800, Craig Sapp <craigsapp at gmail.com>
>> wrote:
>>
>>> Hi Don,
>>>
>>> On Tue, Nov 6, 2012 at 8:54 PM, Byrd, Donald A. <donbyrd at indiana.edu>
>>> wrote:
>>>
>>>
>>>> Finally (and I suspect MEI already handles this), I'd like to point out
>>>> that two sizes of staves -- "normal" and "cue-size" -- aren't always
>>>> enough; there are published performing editions that use three staff
>>>> sizes.
>>>> (In fact, I wouldn't be surprised if editions with _four_ sizes exist,
>>>> though I don't know of any.)
>>>>
>>>
>>>
>>> I have seen at least three sizes in a score before, and this would
>>> theoretically allow for four sizes:
>>>
>>> In a piano/instrumental score, the piano part typically has the
>>> instrumental part displayed above it in a slightly smaller size.  And I
>>> have seen ossia parts for the instrumental staff which in turn would be
>>> smaller than the instrumental staff size.  So if the piano part also had
>>> an
>>> ossia, then there would be four staff sizes, unless the ossia for the
>>> piano
>>> is the same size as the instrumental part (which it probably should).
>>>
>>
>> Right. My list of CMN extremes
>>
>>  http://www.informatics.**indiana.edu/donbyrd/**CMNExtremes.htm<http://www.informatics.indiana.edu/donbyrd/CMNExtremes.htm>
>>
>> lists the J. C. Bach Concerto for Harpsichord or Piano and Strings in
>> E-flat, Op. 7 no. 5 (Dobereiner ed., 1927), where the 3rd size appears
>> briefly, for an ossia. I'm sure I've seen other instances but I can't
>> recall any; if you have other(s) handy, I'd love to hear about 'em (though
>> I'm not sure others on this list would).
>>
>
> The number of possible sizes would be unlimited since it can be defined
> for every staff individually (in staffDef element) if necessary. Our
> proposal was nonetheless to have a cue-size for the most common cases where
> we have only one size of cue-size staves and to have it defined at a higher
> level (in scoreDef element).
>
> Laurent
> _______________________________________________
> 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/20121108/63e93292/attachment.html>