Cannot position and size text in front matter

[ahankinson]

I can find no way to position and size text boxes in front matter. <p> supports @x and @y, but there may be multiple paragraphs in a box, and boxes may have width and height, which is not supported. I would think <div> would behave as a block-level element (like HTML) but it seems to be missing any positioning or sizing attributes.

Currently I have the following markup within <front>:

<front xml:id="m-40">
  <pb xml:id="m-23" n="1"/>
    <div xml:id="m-28">
      <p xml:id="m-29">Second livre
        <lb xml:id="m-30"/>de chansons à quatre 
        <lb xml:id="m-31"/>Nicolas Duchemin
        <lb xml:id="m-32"/>1549
      </p>
    </div>
  <div xml:id="m-24">
    <p xml:id="m-25">Qu’est il besoing chercher toutes les nuictz</p>
  </div>
  <div xml:id="m-26">
    <p xml:id="m-27">Crequillon</p>
  </div>
</front>

[pe-ro]

Would allowing @x and @y on <div> be sufficient? Or does it also need @x2 and @y2 in order to define its bounding box? Would @ulx, @uly, @lrx, and @lry better suit this purpose? Should these bounding box attributes be added to all block-level elements -- those in model.textcomponentLike (lg, model.listLike (biblList, castList, list), p, quote, table) -- and any x and y coordinate attributes removed?

Without opening up a discussion just yet of a similar music style attribute/specification), would it be a reasonable alternative for text block elements to allow a @style attribute with CSS content?

[pe-ro]

Do the same requirements also apply to <anchoredText>?

[ahankinson]

It might be splitting hairs, but I see @ulx, etc. to be defining a box that sits on top of the content (e.g., in the <zone> element), while @x, @y, @x2 and @y2 to be defining a box for the content. So for this particular case, I think the latter would be a better solution.

I tried looking it up in TEI, but it doesn't seem like they have the same concept of block-level elements.

I think we should wait on @style until after this release. That's a much bigger can of worms.

It would be nice to have it on <anchoredText> too.

[pe-ro]

When you say "[i]t would be nice to have it", what "it" are you referring to -- @style or the x/y attributes?

BTW, I think you're right -- your view of @ulx, etc. vs. @x, etc. is splitting hairs. :-)

[ahankinson]

"It" = the @x/@y/@x2/@y2 constellation of attributes for positioning and sizing blocks.

[pe-ro]

As used up to this point, the @x/@y/@x2/@y2 attribute set has been used to identify a start/end pair of coordinates. As a simple example, <line> uses x, y to mark its starting point and @x2, @y2 to identify its terminal point. I don't think a bounding box fits with this approach. I'm more inclined to see bounding boxes as bounding boxes, regardless of whether they contain content or are "on top of" content. Even when they're "on top of" something, they're still identifying stuff that falls in the box (and by extension, excluding stuff that falls outside).

[ahankinson]

If that's the case, then I think we should choose one system and stick with it, since we now have at least three ways of defining spatial layout**:

• @x/@y/@x2/@y2 -- could be a line, but can also be a box.
• @x/@y/@width/@height
• @ulx/@uly/@lrx/@lry

Personally, I think that if we're to tackle any sort of overhaul of this, it should be for the next release since it will affect backwards compat. Adding @x2/@y2 or @width/@height seems like the simplest solution since it will not affect backwards compat.

**(And <div> doesn't allow any of them!)

[pe-ro]

The "problem" is not as dire you imply --

• @x/@y/@x2/@y2 is employed for lines and curves, not boxes (although there's some fudging going on with <hairpin>)
• @x/@y/@width/@height is only used on <graphic> where it mimics HTML usage
• @ulx/@uly/@lrx/@lry is used for bounding boxes/coordinate system definitions

A single system cannot work in all cases. For example, some things, such as slurs and ties, may need @x/@y/@x2/@y2 to mark the endpoints of the curve AND @ulx/@uly/@lrx/@lry to define its bounding box. Also, @x/@y + @width\@height is a commonly accepted substitute for @ulx/@uly/@lrx/@lry where @x/@y represent the bottom left corner of the image and the upper right corner is defined by width and height. This "shortcut" is a reasonable way to scale an image when the coordinate system is unknown, as when embedding images in text. Ultimately, of course, everything has to work within a single coordinate system, but there's a lot of stuff going on, each perhaps with its own spatial markup requirements.

[ahankinson]

OK, so possibly just @x/@y/@width/@height for <div> would be a suitable solution?

[pe-ro]

That's ok with me, but I think we need to decide which corner @x/@y represents -- the bottom left, top left or something else? I don't want to make this decision willy-nilly as it may have far-reaching implications. So, I'd like to gather a lot more input before moving ahead. @kepper? @lpugin?

[kepper]

The problem I see with @x / @y / @height / @width is exactly the ambiguity you're describing. Of course we may state clearly in the guidelines which point is meant by @x / @y, but this doesn't force people to look in the guidelines in the first place. @ulx / @uly / @lrx / @lry seems much safer in this regard. I understand the motivation for more styling options, especially since it may be problematic to use this values for describing an existing source, but I'm afraid none of our proposals so far offers sufficient complexity for this, and we would need a much more HTML / CSS-like solution for that. I don't think that this is the best solution already, but for this very moment, I think I'd prefer @ulx / @uly / @lrx / @lry, because they don't fall behind the other solutions, and there is less ambiguity about their meaning.

[pe-ro]

I'm inclined to agree, but wanted someone else to confirm it. I think this mean that @ulx / @uly / @lrx / @lry should be available on elements that currently use @x / @y and that we have to keep @x / @y / @x2 / @y2 to identify start-end points for things like ties and slurs, but that we can add @ulx / @uly / @lrx / @lry for bounding boxes. Some elements may end up with one or the other or both sets of attributes.

[pe-ro]

My previous comment implies that I'm not as conflicted as I actually am. For instance, what should be used on <accid> -- @x / @y, @ulx / @uly / @lrx / @lry, just @ulx / @uly or some other "corner"?

[kepper]

I think this depends on the task at hand. Do you try to encode an existing source's accid? In that case, wouldn't a @facs be more appropriate? In case of prescribing how to render it: Wouldn't that require way more than just a simple bounding box? I'm thinking about the definition of an "attachment point" (probably somewhere at the notehead, but where?), about the definition of measurement units etc. I don't think that any kind of bounding box mechanism based on @x/@y, @width/@height or @ulx/@uly + @lrx/@lry will be able to cover this properly. @lpugin, @craigsapp, @th-we?

[raffazizzi]

Using positional attributes on text elements is way too procedural; the positioning of the divs in your example belongs outside of MEI (ie your processing).

[pe-ro]

@x / @y are intended to be page coordinates (or viewport coordinates in the electronic realm):

<classSpec ident="att.xy" module="MEI.shared" type="atts">
  <desc>Output coordinate attributes. Some elements may have their exact rendered *output*
  coordinates recorded. x and y attributes indicate where to place the rendered output.
  Recording the coordinates of a feature in a facsimile requires the use of the facs
  attribute.</desc>

Offsets (@ho / @vo / @to) address relative position, although not in terms of an attachment point, but rather in terms of the position determined by software (or by markup, I guess).

In many cases, certainly for an accidental attached to a note, it's not necessary to explicitly set the position of the affected note as the attachment point. This is already taken care of by the fact that the <accid> element is a child of the <note>.

[pe-ro]

Raff -- While I agree that in most cases, text layout can be left to the renderer / browser, there has to be provision for absolute, author-determined positioning. It's often best to put this info in an external location, like a CSS file, but it's also acceptable to put it inside the markup. HTML allows it, why not MEI?

[lpugin]

I am also not sure where this would lead us. We do not necessary want to have a full css system built-in and this should be a separated module, but since we have @x and @y on /p it is a good opportunity to clarify this. I am not sure the bounding box is a good way to go. They make sense for facsimile, where @ulx, @uly, etc. are perfect. To me, it would make more sense to have additional attributes for specifying the size of the text and the alignment. With text elements, I would expect @x and @y to refer to the baseline of the text (left, right or center depending on the alignment attribute mentioned above).

[ahankinson]

Size of the text and alignment don't always capture all of the necessary information. You can have a text box that does not take up the full width of the page (as above) but is not positioned at either left, center, or right. So you would need, at a minimum, x/y/w/h.

If I don't store it in MEI, where should I store it, @raffazizzi? It seems like a strange line to draw (no pun intended!), especially since we're already doing positioning on many other elements.

[pe-ro]

We have <rend> to do these things. As an element, it operates on the text inside the element. This syntax was chosen specifically to avoid having to provide positional info on the outer element itself. For instance,

<p>
  <rend fontname="myFont" fontsize="12pt" halign="center">This text is centered.</rend>
</p>

The question remains, however, do we need to provide some mechanism for positioning the paragraph and/or giving its dimensions? These can be left (as @raffazizzi has advised) outside of MEI entirely, in which case we should probably remove @x / @y from text block elements. But if these attributes aren't sufficient, then ... ?

[ahankinson]

Even having x/y/w/h on <rend> would be fine, I think.

[pe-ro]

But I think Jo's right that ulx / uly / lrx / lry are preferable to x / y / w / h. Do you see a problem with this configuration?

[pe-ro]

The next question is, Can @x / @y on text block elements go away?

[raffazizzi]

If need be, I second adding x/y/w/h (or ulx/uly/lrx/lry) on <rend>. The element is explicitly procedural so at least it allows to keep this information off <div> (and other similar declarative elements).

[ahankinson]

I still see an important distinction between a box "above" (i.e., in a descriptive role) and a box "containing" (i.e., in a prescriptive role). Maybe I'm just in a mental rut, wouldn't it be useful keep the two systems separate?

[lpugin]

I am not sure <rend> makes a lot of difference. Actually, this would mix levels of what you are defining as procedural with declarative ones, which in a way makes is worse than having attributes.

[lpugin]

Sorry, I did not see all the comments when sending my last one. @ahankinson : if @x / @y refer to the left point, center point, or right point of a text element (for left, center or right aligned text respectively), why do you need a box?

[ahankinson]

Because text can wrap within these boxes, so you need to know the rightmost boundary (if x,y refers to the leftmost). Or am I missing something obvious?

[lpugin]

OK, I would assume you would encode the line breaks, as we do for page or system breaks.

[ahankinson]

I don't think I would assume that there would always be line breaks.

[lpugin]

OK, so possibly just @x/@y/@width/@height for <div> would indeed be a suitable solution, I think. And since MEI uses left to right and bottom up orientation, I would assume the point to be the bottom left one.

[pe-ro]

Isn't @ulx / @uly / @lrx / lry a better option? It removes any question about which point @x / @y represent.

[bwbohl]

Hi all, just trying to get really old stuff done or at least close old tickets. Can anyone of you revise this against the current schema and help us decide wheter tand how to fix this or dismiss it

[ahankinson]

As far as I can see it is still not possible to define a box of text with a fixed position and size. anchoredText seems like a good candidate, but it doesn't allow you to set the width and/or height.