display of <milestone> - Githubissues

arlogriffiths commented 1 year ago

@ajaniak : it seems that Salomé has correctly encoded the milestones in DHARMA_INSCIC00142 but the display is not consistent. Do you understand why? In the case of faces C and D, I wonder if the asymmetrical display with a small [ and a big ] is intentional.

danbalogh commented 1 year ago

I can't find a face B in your screenshot, so I don't know if there is a problem there. The funniness in face C and D is surely due to the adjacent gap. When various kinds of gap are adjacent, we wanted to show them in a single pair of brackets. I think Axelle handled this by making the gap elements each output brackets of their own, and then basically eliminating ][ pairs by a text search and replace. But that search and replace cannot differentiate between brackets on the basis of XML element, so it caught this pair too. I don't know if there is an elegant solution to this; maybe Axelle can come up with one. But one possible way to solve this would be simply not to use square brackets for displaying milestones. I've always disliked that, because by my logic, square brackets are for things that the editor deems to be missing from the text: lacunae and their restorations. I think back in the early days I had suggested angle brackets, but that was in tandem with things like line and page breaks. Since line and page breaks are now shown without brackets, differentiated instead by superscript and this little cartouche thing around them, I think milestones should definitely be displayed in the same way, as they are the same kind of thing. That would make our display more consistent AND make your problem go away.

manufrancis commented 1 year ago

I concur with Daniel. Let's display milestone with the same way as lb and pb.

arlogriffiths commented 1 year ago

I concur as well.

Here is a screenshot showing the transition to face B isn't marked at all in the current display, although the <milestone> is encoded.

danbalogh commented 1 year ago

I didn't think to look at the line numbers, but at least I know now why I couldn't find the milestone for face B :) I do not know why it was not displayed; it may be related to the presence of a metrical gap nearby, the there is also an intervening line break and stanza label, so perhaps it's one of those. Axell will hopefully be able to tell.

manufrancis commented 1 year ago

Further thought on the display of <milestone>.

Currently, before the display of milestone between square brackets we have "‡". Since the display of milestone, as <lb>, means to have a superscript oval containing sometimes lot of text (the value of @unit and @n of <milestone> + content of possible <label>), I suggest the following: display any milestone as "‡" with, on mouseover, the contents of the value of @unit and @n of <milestone> + content of possible <label>. In case encoders would like a more visible display of what they first encoded as milestones, they should instead of using milestone divide their edition in <div type="textpart"/>

danbalogh commented 1 year ago

Dear Manu, I definitely disagree with your last thought. The encoding should by no means be determined by how you want something to look. It is a fundamental idea of TEI that we encode what something is, not how it looks. Milestones and textpart divisions are not interchangeable. Textparts encode a feature of the text, a separation that is integral to the text even when abstracted from its physicality. Two (or more) textparts can in principle be present on a single surface. Conversely, milestones encode a feature of the support: a discontinuity or transition in the inscribed surface. Two (or more) segments separated by milestones can be, and often are, present within a single textpart. Ambiguity arises only when these two different kinds of break/transition are simultaneously present. In such cases our policy is to prioritise the unity of the text: we only use textparts when a major semantic division is present in the text. This is another reason why most milestones cannot simply be re-encoded as textpart divisions, since many of them are inside a semantic unit (paragraph, stanza, sentence, etc.).

That said, I share your concern with potentially long milestone labels disrupting the text. (Has anyone actually been using labels for milestones?)

Then again, what I said previously still applies: page breaks and line breaks are specific kinds of milestones, and it would make very good sense to display generic milestones in a similar way.

So, my amended suggestion is to display milestones in the same style as page and line breaks, but to only include the unit and number here, and if a label is present, show that as a mouseover tooltip, but not in the cartouche. I also suggest getting rid of the ‡ symbols.

A possibly useful complication of the scheme could be to do the above only in the edition division, whereas anywhere else in the file (apparatus, or text cited from the edition anywhere else, e.g. in the commentary), milestones could be displayed with nothing but the ‡ sign (and a tooltip). The same might then apply also to page breaks outside the edition, but not to line breaks.

manufrancis commented 1 year ago

Thanks, Dan, for your swift reply.

I concur with your "amended suggestion":

display milestones in the same style as page and line breaks, but to only include the unit and number here, and if a label is present, show that as a mouseover tooltip, but not in the cartouche
getting rid of the ‡ symbol.

As for your "possibly useful complication of the scheme", well, maybe, we can just keep it in store for the moment.

arlogriffiths commented 1 year ago

I also concur. But if it isn't too much of a complication, I'd be happy if Dan's "useful complication" (analogous to what we do with <lb> in apparatus) could immediately be implemented.

@danbalogh — I have encoded <p part="F"><milestone type="pagelike" unit="face" n="B"/><label xml:lang="eng">Back Face</label><lb n="1"/><gap reason="illegible" quantity="1" unit="character"/> kolah-olahan· ... in the inscription that gave rise to my looking into encoding and display of milestones and their labels. It is presently displayed like this:

If I understand correctly, in the new display we shall see a "face B" formatted in a cartouche as in the case of line numbers This unfortunately makes it impossible for me to avoid displaying the value of @n, which I was happy to avoid since in fact I am unable to tell if this final face of a stela was originally its second (B), its third (C) or its fourth (D). Anyhow, that's a problem I can live with.

@ajaniak — Please implement this small extra rule: in the display of @unit, display the initial letter of the chosen value with a capital letter, so we get "Face B" instead of "face B".