Move rotate attribute to att.coordinated #681

JRegimbal · 2020-06-25T16:45:19Z

This makes @rotate apply to all elements with the att.coordinated class and not just the zone element. This expands it to the surface and symbolDef elements.

See #674 for more information on @rotate.

This makes rotate apply to all elements with the att.coordinated class and not just the zone element. This expands it to the surface and symbolDef elements.

kepper

I think in general it's better to move this up to att.coordinated. I'm not perfectly sure if I'd prefer to see it in a separate sub-class or not. Normally, I would, but considering where this occurs, I think it's fine to put placement and rotation in one class. What I'm more concerned with is the description. @JRegimbal's clarification in a18fee0 helped, but didn't fully fix it in my perception. Ideally, we should have an image somewhere in the documentation, both in the Guidelines and here as a remark (compare with https://music-encoding.org/guidelines/v4/data-types/data.accidental.written.html). It should be absolutely clear what the center of the rotation is, and if the two points encoded by ulx/uly and lrx/lry are already rotated (so that width and height of that rect can't be derived directly anymore, but one could add att.dimensions to compensate). I'd really like to see more explicit statements about all this before putting it in, even though it's certainly going in the right direction :-)

JRegimbal · 2020-06-29T12:18:47Z

My impression of how @rotate would apply to the other two elements is that, like in zone, the bounding box defined by ulx/uly/lrx/lry would not be impacted by rotation but would inform the user or software that the content should be interpreted as rotated.

So for something like <surface rotation="45">...</surface> that would mean that the entire surface described (including any zones in it) should by default be interpreted as being captured at a 45° angle. Similarly <symbolDef rotation="15">...</symbolDef> would mean that the symbol being defined should be interpreted as rotated 15° from whatever it's normal orientation would be. But in both cases the x-y plane would be unaffected.

Does this seem like a sensible interpretation to you @lpugin and @kepper? If so I can add another commit making this explicit.

bwbohl

Unfortunately I missed the addition of @rotate in the first place… At the moment I'm in eager need of some real world examples for @rotate. As of the name (picking up the question is it the zone or the content that are being rotated) why not pick @rotated which makes it clear in the current facsimile context. (then why limit it to theses facsimile elements? What about born digital documents?)
Concerning symbolDef I'd see more sense in adding@rotate(d) to symbolas otherwise one would need multiple symbolDef just to encode a normal and rotated version of a symbol.

bwbohl · 2020-06-30T23:19:47Z

source/modules/MEI.shared.xml

@@ -689,6 +689,19 @@
          <rng:data type="nonNegativeInteger"/>
        </datatype>
      </attDef>
+      <attDef ident="rotate">
+        <desc>
+          Indicates the amount by which the contents of this zone have been rotated clockwise, with respect


The description is still referring to mei:zone if @rotate is to be moved to att.rotatedthis should be generalised

Oh thanks nice I missed that!

bwbohl · 2020-06-30T23:21:27Z

source/modules/MEI.shared.xml

@@ -7079,7 +7092,7 @@
      <constraint>
        <!-- See http://vocab.org/frbr/core for more-precise entity-to-entity constraints -->
        <sch:rule
-          context="mei:relationList/mei:relation[parent::mei:work or parent::mei:expression or             
+          context="mei:relationList/mei:relation[parent::mei:work or parent::mei:expression or


It's nice that this PR fixes those trailing whitespaces but for the sake of reviewing it would be better not to include such changes ;-)

Ah sorry about that my editor is very aggressive with trailing whitespace.

lpugin · 2020-08-31T08:45:34Z

Anything wrong with this PR? (This is currently blocking the update of the Schema within Verovio)

bwbohl · 2020-08-31T08:54:34Z

need a small fix in the documentation I'd say, sorry for the delay: music-encoding/guidelines#178

lpugin · 2020-09-22T14:20:18Z

How does it look now?

kepper

Apologies for the long wait – this is definitely ready for merge, just as music-encoding/guidelines#178 (to be done tomorrow at the ODD Friday…)

rettinghaus · 2022-11-01T08:41:56Z

Could we revert this particular change? (Yes, I know I'm late to the party.) I don't see the sense in having @rotate on surface. The encoding always follow the main text direction. You would not encode music/text upside down, just because you're too lazy to rotate the folio in front of you.
Same for symbolDef. Why would you define a symbol in a rotated state? If one symbol seems to be rotated on the page you would still use zone, and that seems to be sufficient.

ahankinson · 2022-11-01T09:29:50Z

The intention was to be able to capture the offset of the surface from the main text direction. If an image was rotated by 2° during digitization there was no way to capture this such that the notation and the surface could be aligned. You could capture width and height.

It's explained here: #620

ahankinson · 2022-11-01T09:32:09Z

In fact, looking back at that you agreed with this, and actually suggested @rotate?

rettinghaus · 2022-11-01T09:38:43Z

Then a zone of the size of the surface is rotated. (Or graphic, not the surface itself).
I agreed with #674.

Connected to this is actually #971.

ahankinson · 2022-11-01T09:47:10Z

graphic points to an image file, which cannot be rotated by definition, since all image files assume 90° corners.

zone is an area of the surface. We do not allow nested zones, and I agree with the reasons why. It complicates the parsing for very little benefit.

surface is the abstract space onto which a graphic is projected, and allows the co-ordinates of the zones to be addressed. It allows for a global rotation such that all zones on that surface may be adjusted per this co-ordinate space, if the user desires.

If it helps you can think of a surface as a specialized zone -- naming it differently means we can enforce a single layer of nesting, since otherwise we would be forced to always allow zone within zone to arbitrary depths.

Move rotate attribute to att.coordinated

faaca32

This makes rotate apply to all elements with the att.coordinated class and not just the zone element. This expands it to the surface and symbolDef elements.

lpugin requested review from bwbohl and kepper June 26, 2020 09:37

kepper requested changes Jun 26, 2020

View reviewed changes

bwbohl requested changes Jul 1, 2020

View reviewed changes

Remove explicit reference to zone

dc79cbe

lpugin requested review from bwbohl and kepper August 7, 2020 12:34

bwbohl added this to the MEI 4.1.0 milestone Aug 31, 2020

bwbohl added Component: Core Schema changes to source/modules/* (assigned automatically) Status: Ready To Merge indicates that a pull request is ready for merging Type: Feature Request indicates that new features, that do not break backward compatibility, have been proposed labels Aug 31, 2020

bwbohl self-assigned this Aug 31, 2020

lpugin mentioned this pull request Sep 3, 2020

Mensural notation: rendering of 3-breve rests rism-digital/verovio#1405

Open

lpugin assigned kepper Oct 6, 2020

kepper approved these changes Oct 15, 2020

View reviewed changes

kepper merged commit c020105 into music-encoding:develop Oct 16, 2020

musicEnfanthen removed the Status: Ready To Merge indicates that a pull request is ready for merging label Jan 28, 2022

bwbohl modified the milestones: MEI 4.1.0, MEI 5.0.0 May 26, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Move rotate attribute to att.coordinated #681

Move rotate attribute to att.coordinated #681

JRegimbal commented Jun 25, 2020

kepper left a comment

JRegimbal commented Jun 29, 2020

bwbohl left a comment •

edited

bwbohl Jun 30, 2020

JRegimbal Jul 1, 2020

bwbohl Jun 30, 2020

JRegimbal Jul 1, 2020

lpugin commented Aug 31, 2020

bwbohl commented Aug 31, 2020

lpugin commented Sep 22, 2020

kepper left a comment

rettinghaus commented Nov 1, 2022

ahankinson commented Nov 1, 2022

ahankinson commented Nov 1, 2022

rettinghaus commented Nov 1, 2022

ahankinson commented Nov 1, 2022

Move rotate attribute to att.coordinated #681

Move rotate attribute to att.coordinated #681

Conversation

JRegimbal commented Jun 25, 2020

kepper left a comment

Choose a reason for hiding this comment

JRegimbal commented Jun 29, 2020

bwbohl left a comment • edited

Choose a reason for hiding this comment

bwbohl Jun 30, 2020

Choose a reason for hiding this comment

JRegimbal Jul 1, 2020

Choose a reason for hiding this comment

bwbohl Jun 30, 2020

Choose a reason for hiding this comment

JRegimbal Jul 1, 2020

Choose a reason for hiding this comment

lpugin commented Aug 31, 2020

bwbohl commented Aug 31, 2020

lpugin commented Sep 22, 2020

kepper left a comment

Choose a reason for hiding this comment

rettinghaus commented Nov 1, 2022

ahankinson commented Nov 1, 2022

ahankinson commented Nov 1, 2022

rettinghaus commented Nov 1, 2022

ahankinson commented Nov 1, 2022

bwbohl left a comment •

edited