Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to space base characters where shiftRuby kicks in for group ruby? #258

Closed
r12a opened this issue Feb 16, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@r12a
Copy link

commented Feb 16, 2017

10.2.36 tts:rubyOverflow
https://www.w3.org/TR/2016/WD-ttml2-20161117/#style-attribute-rubyOverflow

jLReq makes a distinction between (a) handling of annotation alongside a single base character, and (b) annotation alongside multiple base characters in the shiftRuby case. For (b), the base characters are spread evenly as in this diagram.

img2_3_36

How would one apply that behaviour specifically to the ruby items where shiftRuby has been applied to prevent overflow?

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented May 9, 2017

I'm not sure what the diagram is showing.

Are the spaces between base characters authored that way (B A S E)?
Or are the spaces between base characters artificially inserted after the fact (BASE)?

In either case, shiftRuby will move the annotations and will not introduce artificial spacing between base characters. Whether the annotations are applied to a single base character or multiple base characters, shiftRuby will not alter base characters or the relationship/positioning between base characters.

@r12a

This comment has been minimized.

Copy link
Author

commented May 10, 2017

Are the spaces between base characters authored that way (B A S E)?
Or are the spaces between base characters artificially inserted after the fact (BASE)?

The gaps are automatically created (in a similar way as, i assume, would happen for shiftBase in order to produce a gap at the start of the line per your diagram in 10.2.37, or when using rubyAlign set to spaceAround).

Jlreq expects overflow to be handled as shown in your diagram in 10.2.37 when an annotation appears alongside a single character, but in the case where a group ruby annotation appears alongside multiple characters, it calls out a different behaviour:

Group-ruby at the line head: Make adjustments so that the top of the ruby text is aligned with that of the first base character, and add the same amount of inter-character space between the base characters and between the end of the last base character and the end of the last ruby character after the last base character (the method specified in JIS X 4051) (see Fig. 3.87). [which is the figure in my first comment box above] [my emphasis]

I was wondering how a content author would obtain that behaviour, if they wanted it. I assume that they would start by setting rubyOverflow to shiftRuby, and then set rubyOverhang to none, and then set rubyAlign to something. However, i see two problems:

  1. there doesn't seem to be a way to set rubyAlign so that either the start or end of both the base and annotation are aligned, but there are also gaps around the base characters.
  2. i'm not sure how you'd make that apply only in the case where the group ruby happens to start or end a line, unless you put in hard line breaks and set styling explicitly for those cases.

So, i guess the answer is, you can't produce that behaviour in TTML.

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented May 10, 2017

So, i guess the answer is, you can't produce that behaviour in TTML.

I don't believe you can and I don't see any need for it in a subtitle context.

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented May 16, 2017

Suggest we close since there is no action to be taken.
@r12a thoughts?

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented Jul 7, 2017

@nigelmegitt
Given that Japanese subtitle authors and consumers do not expect this type of functionality, I suggest we close as non-issue.

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2017

@dae-kim Just so we understand where our basis for this comes from, is your evidence that authors and consumers do not expect this type of functionality only the lack of support for it in Lambda CAP? Or are there other data points we can use to support it?

@dae-kim

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2017

@nigelmegitt Based on conversations with Japanese subtitle companies based in Japan, they have never heard of this requirement. Nor have their customers asked for any such functionality (even as image based subtitles). The general reaction to this feature from the Japanese subtitling industry is, "the rules for media entertainment is different from one for printing material".

@r12a

This comment has been minimized.

Copy link
Author

commented Aug 17, 2017

Based on the information that this aspect of jlreq is not supported for TTML in Japan at the moment, the i18n WG is now closing the pointer to this issue in its review tracker. Thank you.

@skynavga

This comment has been minimized.

Copy link
Collaborator

commented Aug 21, 2017

In the future, a new keyword could be added to support this behavior, e.g., shiftRubyDistributeBase, or perhaps shiftRubyDistribute as a short hand. In any case, the I18N WG has closed this issue in their review tracker. I am marking as works for me and closing at this time.

@skynavga skynavga closed this Aug 21, 2017

@skynavga skynavga added this to the Editor's CR Work List milestone Aug 21, 2017

@css-meeting-bot

This comment has been minimized.

Copy link
Member

commented Aug 31, 2017

The Working Group just discussed ttml2#258 How to space base characters where shiftRuby kicks in for group ruby?, and agreed to the following resolutions:

  • SUMMARY: Disposition agreed by WG
The full IRC log of that discussion <nigel> Topic: ttml2#258 How to space base characters where shiftRuby kicks in for group ruby?
<nigel> github: https://github.com//issues/258
<nigel> Glenn: This was a very interesting case that Richard raised, where the JLReq shows a
<nigel> .. requirement that we didn't implement. Dae told us that the Japanese subtitle companies
<nigel> .. have never asked for it, and it probably came out of printed material, so on that basis
<nigel> .. i18n closed this on their tracker. I proposed a possible future direction in case this
<nigel> .. behaviour is needed, and propose to close this for now.
<nigel> Nigel: I support the current proposition, to do nothing but indicate how we'd do it in the
<nigel> .. future if we had to.
<nigel> SUMMARY: Disposition agreed by WG
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.