palemieux
commented
2 years ago @btsimonh Can you provide a test?
Closed btsimonh closed 1 year ago
palemieux
commented
2 years ago @btsimonh Can you provide a test?
btsimonh
commented
2 years ago see imsc-tests PRs. Did not cover the color issue....
palemieux
commented
2 years ago @nigelmegitt It looks like getSpanAncestorColor() does not pick up the backgroundColor specified on the rb element, and thus linePadding does not work. Thoughts?
<?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="en"
xmlns:tt="http://www.w3.org/ns/ttml"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
xmlns="http://www.w3.org/ns/ttml"
xmlns:tts="http://www.w3.org/ns/ttml#styling"
xmlns:ebutts="urn:ebu:tt:style"
ttp:contentProfiles="http://www.w3.org/ns/ttml/profile/imsc1.1/text">
<head>
<styling>
<style xml:id="r1"
tts:color="white"
tts:lineHeight="125%"
tts:textAlign="center"
tts:displayAlign="after"
ebutts:linePadding="0.25c"/>
<style xml:id="s1" tts:backgroundColor="#00000080"/>
</styling>
<layout>
<region xml:id="r" style="r1" tts:extent="80% 80%" tts:origin="10% 10%" />
</layout>
</head>
<body region="r">
<div>
<p style="r1">
<span style="s1">ruby container boxed with </span><span tts:ruby="container">
<span tts:ruby="base" style="s1">padding</span><span tts:ruby="text">0.25em</span></span>
<br/>
<span style="s1">a span on a 2nd line</span>
</p>
</div>
</body>
</tt>
nigelmegitt
commented
2 years ago @palemieux The spec (pdf, see Appendix D) for ebutts:linePadding says it applies to line areas. I'm not sure, in a CSS world, how the area in which ruby is painted interacts with what we may consider a line area. Nevertheless, I think it makes sense to apply line padding to ruby areas: it's just unspecified behaviour at the moment.
In particular I'd be concerned that the layout requirements are unclear. Should line padding cause adjacent rubys applied to different ruby base text to be spaced apart further? What if that would cause a line break?
I don't think this is straightforward at all.
btsimonh
commented
2 years ago The below sample file illustrates various boxing with Ruby.
In the test above, @palemieux has boxed the ruby base; in this case even with the patch, the ruby container has been padded, but it's background is transparent, and so the padding not shown. We can't duplicate the color from the ruby text to the ruby container, else we end up with (6) below - undesirable for semi-transparent boxing. We could pad both the ruby container and the ruby base...
The other thing I'm not sure about is if a ruby container's height should be the size of the base and text, or the base only. For background color render in Chrome it's the height of the base span. For other purposes, it's the combined height?
In the below, speaking from a personal 'what would look good' perspective, (3) should get line padding either side of the text '0.25em'. For me, this would satisfy the line padding intent. @nigelmegitt - if line padding from two ruby texts were to conflict, they should not change the position of anything - just like line padding currently is only visual, an has no impact on line length (or does it?)? Edit - I see it DOES impact line length. Would have been nicer if it did not :(.
However, in terms of the constructs, (1) and (4) make most sense to me, the others produce undesirable results in browsers (box overlaps), and are more complex to author. I tried really hard to understand how to control browser ruby text background presentation, and decided it was variable amongst browsers and likely to change, so not worth further effort for the moment.
Another 'boxed' presentation which I do not think can be simply achieved would be a rectangular box which (just) covered both base text and ruby text for the line. I think (5) should probably do this, but does not.
1 padding0.25em
2 padding0.25em
3 padding0.25em
4 padding0.25em
5 padding0.25em
6 padding0.25em
nigelmegitt
commented
2 years ago @btsimonh I'm struggling to see how the renders you pasted are an improvement looking at the ruby? In particular, if we were applying linePadding to ruby then I would expect to see it on the "0.25em" immediately following "3 Padding", but it looks like it is absent both pre- and post-PR. Perhaps I'm missing something...
btsimonh
commented
2 years ago @nigelmegitt - the PR only fixes the padding on the base text. i.e. the primary line is padded 'correctly' - now the word 'padding' has padding on the end :). As for padding the actual ruby text, I stopped before that because I can't suggest boxing them anyway because the boxes of the ruby text and ruby base conflict in the browser presentation without a lot more rework and understanding of what browsers are meant to do. Since I could not find a good definition of what browsers were meant to do.... we may be on a loser.
nigelmegitt
commented
2 years ago Ah, I see it now, thank you @btsimonh - this is an improvement for those test cases. For the line beginning 6, why is the background colour on the right edge of the line grey not black? If we're making a change, we should try to make it fit the spec here.
Just an observation: the line beginning 5 seems to have a big problem with the current render, because it should have a background colour, but doesn't. That should be orthogonal to the line padding, but maybe there's a common cause.
btsimonh
commented
2 years ago For the line beginning 6, why is the background colour on the right edge of the line grey not black because the black is 'double opacity 0.5' - i.e. this is an undesirable use of background colour on outer AND inner elements. The outer element has been padded, resulting in the grey (half opacity black). The inner element not, and the opacity should be 0.75 (i.e. it's not black, just darker). It's the same issue for general TTML with <1 opacity for backgrounds on P, when you want to change to a different colour on a span. You can't, because the span opacity adds to the p opacity. (unless..... what if the span opacity was 0???? - please let me know!!)
nigelmegitt
commented
2 years ago The outer element has been padded, resulting in the grey (half opacity black)
This is a bit confusing from a terminology perspective. To pad the outer element (the <p>?) there would need to be a tts:padding attribute present, which there is not.
The right edge of the line area is the bit at the right edge of the word "padding", where the darker colour applies, formed by the multiple application of tts:backgroundColor with a semi-opaque black value. This test case reveals an interesting question: should only the innermost <span>'s semi-opaque background colour be used to extend the line, or the combined set of <span> backgrounds that apply behind the text?
If the former, the behaviour is correct, but if the latter, then not. This isn't a case that is dealt with in the EBU-TT-D specification, and indeed it does not apply there, because nested <span> elements are prohibited in that specification.
Arguably this is something we should consider as some kind of clarification in the IMSC specification, i.e. what to do if there are nested <span> elements. Given that ruby in TTML requires nested spans, it's feasible to generate this effect, though I'd suggest to any authors that they avoid it, and only set the background colour on the outermost span on the line.
btsimonh
commented
2 years ago We must be able to have colours on separate spans on a line, else you can't change background mid line. The issue of background colours combining does make things difficult, and not ideal :). but nothing to be done.
I believe in this case the behaviour (of the patched version) is to spec, extending the background colour of the last span of the line (which happens to be a ruby container). The presence of extra background colour on the ruby text is an example of how not to do it?
btsimonh
commented
2 years ago The outer element has been padded, resulting in the grey (half opacity black)
This is a bit confusing from a terminology perspective. To pad the outer element (the
<p>?) there would need to be atts:paddingattribute present, which there is not.
agree. It's meant to mean 'the outer of the two nested spans'. i.e. the (modified) line-padding mechanism has padded the ruby container which has a background on it. And the ruby base has not been padded by line-padding, but also has a background on it, which results in the double application of opacity on the word 'padding', hence the word's background being darker. This points to it being undesirable to apply background with opacity to multiple spans which are children or parents (unless you want that presentation).
Interesting; Added one more case (7) to the above, renders OK in pre and post PR:
1 padding0.25em
2 padding0.25em
3 padding0.25em
4 padding0.25em
5 padding0.25em
6 padding0.25em
7 padding0.25em
nigelmegitt
commented
2 years ago I've opened #238 which takes a different tack in addressing this: I found that the rb element appears to have its layout implemented differently to other elements, and to be deprecated in HTML. By using just a span instead, many of the issues disappear. ~However it does appear that backgroundColor does not propagate in the way it probably should, so there may be more work to do.~ Comment edited see https://github.com/sandflow/imscJS/pull/238#issuecomment-1320317183 : this fixes the background-color propagation in the example provided in #237.
palemieux
commented
1 year ago Replaced by #238
When applying line padding, if the start or end of line element is a span inside an RB element, then instead apply the padding to it's RUBY parent. Not that this is more of a bandaid than a fix, as nested spans will have the same issue - start and end elements are only taken from leaf nodes, so any enclosing nodes may cut off the padding.
Also addresses background colors and ruby
Also avoids splitting rt text into spans (as they are not recombined).