Consider layout as the place to specify where ruby annotations are placed

[duncdrum]

Import from main repo

<layout> seems a good place to collect general information about the appearance of ruby (left right top bottom), so as to not repeat the @place on every <rt>, <div>, <p>… . In my experience, where ruby appear is a document property, no need to insert into more low level markup. Do we want to give <layout> a special section to specify rt appearance, and the number of ruby streams. I m leaning towards yes.

[martindholmes]

We were attempting to get a simple, straightforward initial implementation of Ruby and the prose section ready for discussion at the Council meeting this weekend, in the hope that it could go into the next release of the Guidelines. With all these additional suggestions and complications, I think we either have to give up that idea entirely, or we have to shelve this sort of thing to be resubmitted as feature requests after the initial implementation. What do you think -- give up on this release for now?

[duncdrum]

Personally, I'd rather see a broader range of phenomena included in the initial release: any text, any language, any time…. As for council's timetable that's up to council, I have little desire to open these issues as feature requests a third time.

[duncdrum]

It still seems overkill to me to demand that editors encode the @place and @type of each individual rt without providing a central place to define this once. In tons of modern documents (japanese and others) there will ever only be one type of ruby appearing in one place whenever they appear. The complex case raised by note00178 seems to me to beyond the scope of a first draft to be submitted soon. If encoders want / need to specify on every element, they still can. But there should be a recommended central place where this would unnecessary inflate the markup burden.

I think <layout> would make sense, but other elements in the header might fit, lets just pick one. I see no disadvantages of providing a central space, so that e.g. rendering in html is more easily achieved.

[knagasaki]

It still seems overkill to me to demand that editors encode the @place and @type of each individual rt without providing a central place to define this once. In tons of modern documents (japanese and others) there will ever only be one type of ruby appearing in one place whenever they appear. The complex case raised by note00178 seems to me to beyond the scope of a first draft to be submitted soon. If encoders want / need to specify on every element, they still can. But there should be a recommended central place where this would unnecessary inflate the markup burden.

I think <layout> would make sense, but other elements in the header might fit, lets just pick one. I see no disadvantages of providing a central space, so that e.g. rendering in html is more easily achieved.

I think usage of <layout> is not necessary, but useful in some cases. So it is not necessary to write it in the Guidelines. Please let me show a simple example to use <layout>, if you still want to make it necessary.

[duncdrum]

Please do share, I don't want to make it necessary, but optional.

For that I think we need a minor change to the content-model of layout, so that processors know where to find the information if ruby should be displayed, (e.g. top or right.

[knagasaki]

Please do share, I don't want to make it necessary, but optional.

For that I think we need a minor change to the content-model of layout, so that processors know where to find the information if ruby should be displayed, (e.g. top or right.

Basically, the position of <ruby> is decided implicitly as right in vertical text and top in horizonal text.
I think it is not a timing to treat the content-model. When the request would occur from wider user community, it should be done.

[duncdrum]

Basically, the position of <ruby> is decided implicitly as right in vertical text and top in horizontal text.

That should be part of the documentation prose imv, not sure where that implicit interpretation originates in the context of TEI. I m not going to open a third ticket with a feature request for a central place.

[knagasaki]

Basically, the position of <ruby> is decided implicitly as right in vertical text and top in horizontal text.

That should be part of the documentation prose imv, not sure where that implicit interpretation originates in the context of TEI. I m not going to open a third ticket with a feature request for a central place.

I agree to write it in the documentation prose (and I'm glad to do so).

[martindholmes]

How about @rubyPlace on the layout element?

[duncdrum]

How about @rubyPlace on the layout element?

Even better, was what I was thinking as well. And solve my main concern

[martindholmes]

@sydb How do you feel about creating a new attribute @rubyPlace on the <layout> element, whose job is to specify the default place for ruby annotations? This would be better than forcing users to supply @place on every <rt>, or to specify a default value in some descriptive prose that a processor couldn't necessarily interpret. @rubyPlace would have the same suggested valList as @place on <rt>.

[duncdrum]

I like TEIC/TEI#2090 as it would also allow to set the @type which in tons of contemporary Japanese documents is also consistent per documents.