Open duncdrum opened 3 years ago
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?
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.
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.
It still seems overkill to me to demand that editors encode the
@place
and@type
of each individualrt
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.
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
.
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 ifruby
should be displayed, (e.g.top
orright
.
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.
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.
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).
How about @rubyPlace
on the layout element?
How about
@rubyPlace
on the layout element?
Even better, was what I was thinking as well. And solve my main concern
@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>
.
I like https://github.com/TEIC/TEI/issues/2090 as it would also allow to set the @type
which in tons of contemporary Japanese documents
is also consistent per documents.
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 specifyrt
appearance, and the number of ruby streams. I m leaning towards yes.