search

w3c / imsc

TTML Profiles for Internet Media Subtitles and Captions (IMSC)
https://w3c.github.io/imsc/
Other
31 stars 17 forks source link

What fillLineGap does/ affects #254

Closed r12a closed 6 years ago

r12a commented 7 years ago

6.7.6 itts:fillLineGap https://www.w3.org/TR/ttml-imsc1.0.1/#itts-fillLineGap

[From John Klensin. Discussed by the i18n WG] Editorial (I think) It might be helpful if this document were to prominently state/ clarify just what fillLineGap does/ affects. Even if it is just about colouring between lines, I can imagine that, with some choices of type style ad type colouring, poor choices for this value might cause parts of letters of symbols to become effective invisible. If that can't occur, it would be helpful for the document to say so. Conversely, if it can, some cautionary words may be appropriate.

palemieux commented 7 years ago

@r12a Can an example of type style ad type colouring be provided? I cannot picture the scenario John has in mind.

nigelmegitt commented 7 years ago

@r12a I believe our intent is that fillLineGap only affects background painting, and since background is painted behind the text, it would be an error for it to obscure any parts of letters or symbols. Bear in mind also that the only values are true and false, so the actual background colour that applies is separately defined via the tts:backgroundColor attribute.

css-meeting-bot commented 7 years ago

The Working Group just discussed What fillLineGap does/ affects #254.

The full IRC log of that discussion <nigel> Topic: What fillLineGap does/ affects #254
<nigel> github: https://github.com/w3c/imsc/issues/254
<nigel> Pierre: I didn't understand this, but maybe the new examples for #263 will help.
<nigel> Nigel: Maybe!
<nigel> .. I didn't understand either.
<nigel> Pierre: If we get to a point ready to move past CR we will need to ping @r12a.
<nigel> Cyril: A side comment - for rubys in TTML2 would fillLineGap apply?
<nigel> Glenn: The presentation of the ruby is an annotation on a line area effectively so it would
<nigel> .. be simply covered by the line gap as well. The height of the line gap would be predicated
<nigel> .. on the height of the line area, which would in turn be predicated on any annotations and
<nigel> .. the space that they need.
<nigel> Cyril: Would the line gap between the ruby and the base text be filled by fillLineGap?
<nigel> Glenn: Yes it's part of the line area already. It's a bit like the dot on an i.
css-meeting-bot commented 7 years ago

The Working Group just discussed What fillLineGap does/ affects #254, and agreed to the following resolutions:

The full IRC log of that discussion <nigel> Topic: What fillLineGap does/ affects #254
<nigel> github: https://github.com/w3c/imsc/issues/254
<nigel> -> http://w3c.github.io/imsc/imsc1/spec/ttml-ww-profiles.html#itts-fillLineGap IMSC1.0.1 fillLineGap
<nigel> pal: There are more examples of this in the IMSC spec now, compared to when the issue
<nigel> .. was raised.
<nigel> glenn: This might depend on if the line area includes leading or not. In our model it does
<nigel> .. include the leading.
<nigel> .. We assume that line areas abut each other.
<nigel> pal: That's how CSS works, it stacks the line areas with no gaps between them.
<nigel> glenn: The issue raiser's model may differ, so it may be worth clarifying.
<nigel> nigel: I think the main concern is that it could cause parts of letters or symbols to become
<nigel> .. effectively invisible.
<nigel> r12a: I was looking at that too - need to think about ascenders and descenders, which in
<nigel> .. some languages like arabic can be quite long.
<nigel> .. I think the question is if the background definitely extends to cover those.
<nigel> pal: That goes back to XSL and CSS - this section doesn't change that at all.
<nigel> pal: It sounds like the concern does not relate to fillLineGap specifically, but to the application
<nigel> .. of background on span.
<nigel> glenn: There's a valid point, which is can the author avoid doing something stupid or is it
<nigel> .. an instruction to implementers. It sounds like his concern is we could force the processor
<nigel> .. to do something that makes the author do something to address visibility of glyphs.
<nigel> .. In fact there's no constraint in any of the specs that the outline of the glyph be inside the
<nigel> .. em square. This is the case where the author needs to be aware of that.
<nigel> pal: fillLineGap does not make this worse because it does not apply new background, it
<nigel> .. only extends existing background, so it can't make anything worse, only better.
<nigel> .. Example: white glyphs, black background, which is extended to cover parts of glyphs that
<nigel> .. overlap non-background.
<nigel> pal: The line stacking strategy means the line height must be greater than or equal to the computed lineHeight.
<nigel> r12a: In CSS you can set lineHeight to 0.5 and the glyphs may overlap each other.
<nigel> atai: In the line stacking strategy in TTML that is prohibited.
<nigel> pal: On this issue I propose to clarify that fillLineGap does not add background but extends
<nigel> .. existing background.
<nigel> nigel: I think the point to clarify is that the line area before edge and after edge can never
<nigel> .. be within the content rectangle, so there can never be a case where setting the background
<nigel> .. to the before and after edges of the line areas makes the background get smaller
<nigel> .. than it would be without fillLineGap.
<nigel> atai: I propose to add a note to the spec section to say that the application of fillLineGap
<nigel> .. does not result in hiding any characters that would be visible without fillLineGap.
<nigel> nigel: I propose to add a note that the line stacking strategy for TTML means that the
<nigel> .. application of fillLineGap can never make the background smaller than if it were not applied.
<nigel> r12a: Another way to say it is that the background that is applied will cover all of the glyphs.
<nigel> atai: Yes, to say after application of fillLineGap all parts of all glyphs with a background
<nigel> .. colour behind them continue to have that background colour applied.
<nigel> pal: I'll propose text.
<cyril> what about ruby?
<nigel> pal: this is IMSC 1.0.1
<nigel> glenn: I'm not sure I've defined that very carefully for presentation semantics of TTML2,
<nigel> .. but I have the assumption that ruby glyphs are contained within the line area.
<nigel> RESOLUTION: Add a note to say: Note: The application of fillLineGap does not result in hiding any character glyphs that would be visible without fillLineGap. Therefore after application of fillLineGap all parts of all character glyphs with a background colour behind them continue to have that background colour applied.
<r12a> s/applied will cover all of the glyphs/applied will cover all parts of all the glyphs/
nigelmegitt commented 7 years ago

Reading that resolution again, it doesn't quite say what we meant. Consider the example in https://www.w3.org/TR/ttml-imsc1.1/#itts-fillLineGap : if the <p> had a background colour (say red for the sake of contrast), and one of the glyphs in the word "lazy" extended partially beyond the yellow background, then on the left hand image those parts of the glyph beyond that yellow background would be drawn over a red background, but on the right hand image, they would be drawn over a yellow background.

Therefore after application of fillLineGap the parts of the character glyphs with a red background colour behind them would no longer have that background colour applied, hence the proposed note is false in that case.

The intent of what we agreed is correct, but the detail is wrong. I think the note needs to say:

Note: The application of fillLineGap does not result in hiding any character glyphs that would be visible without fillLineGap. After application of fillLineGap all parts of all character glyphs with the most locally applied background colour behind them continue to have that background colour applied; any parts of any character glyphs that extend beyond the background area when fillLineGap is set to false are instead drawn with the most locally applied background colour behind them when fillLineGap is set to true, within the constraints of the line area. Any parts of any character glyphs that extend beyond the line area may not have a background drawn behind them at all, regardless of the value of fillLineGap.

Observation: this is quite complicated.

palemieux commented 7 years ago

@nigelmegitt The case you described is one where the glyph extends beyond the area where the span background is applied, right? Isn't this an edge case, i.e. won't the author try to avoid the scenario?

Observation: this is quite complicated.

What about simply noting that fillLineGap extends the background of the content area, which always appears behind the glyphs?

nigelmegitt commented 7 years ago

@palemieux Right, yes. It may be an edge case, but it is not one the author can avoid deterministically, since the content rectangle is undefined.

Are you suggesting exact wording of "extends the background of the content area"? I think the content area is defined not to have a background - rather there's a background area and a content area and a padding area and the background is traditionally painted in a rectangle the same size and position as the padding area.

I'd be very happy if someone could suggest alternate wording though!

palemieux commented 7 years ago

Are you suggesting exact wording of "extends the background of the content area"?

Using the XSL nomenclature, it would probably need to say: "fillLineGap extends the bakground color applied to the padding-rectangle, which appears behind the glyphs."

[ed.: on a related topic, it is probably not a good idea to allow borders on span if fillLineGap is used.]

skynavga commented 7 years ago

I think this is possible wrong, but need to double check the language in XSL-FO regarding line stacking. In my mental model, the correct language is "extends to the before and after edge of the line area.

On Mon, Nov 20, 2017 at 10:48 AM, Pierre-Anthony Lemieux < notifications@github.com> wrote:

Are you suggesting exact wording of "extends the background of the content area"?

Using the XSL nomenclature, it would probably need to say: "fillLineGap extends the bakground color applied to the padding-rectangle, which appears behind the glyphs."

[ed.: on a related topic, it is probably not a good idea to allow borders on span if fillLineGap is used.]

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/imsc/issues/254#issuecomment-345773631, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb_Jl7WM-gfiEwNv0zPQTmELhPiyEks5s4btrgaJpZM4PZI9g .

palemieux commented 7 years ago

@skynavga "extends to the before and after edge of the line area", yes. The commenter wanted to make sure that the background that was being extended was already the one behind the glyphs. What is this background called?

skynavga commented 7 years ago

The current language found under TTML2 10.2.17 is exactly correct:

If a background color applies to an inline area child of a line area, then if the value of this attribute is true, that background area is, for rendering purposes, extended in the block progression dimension so as to be coincident with the before and after edges of the line area; otherwise, if the value of this attribute is false, then that background area is not extended, but remains bounded by the inline area's border rectangle.

Note:

In other words, when this attribute's value is true, background colors rendered on inline areas of adjacent lines abut one another rather than leaving a visible gap in the block progression dimension, i.e., they fill any line gap (also known as leading).

If a computed value of the property associated with this attribute is not supported, then a presentation processor must use the value false.

On Mon, Nov 20, 2017 at 9:56 PM, Pierre-Anthony Lemieux < notifications@github.com> wrote:

@skynavga https://github.com/skynavga "extends to the before and after edge of the line area", yes. The commenter wanted to make sure that the background that was being extended was already the one behind the glyphs. What is this background called?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/imsc/issues/254#issuecomment-345916860, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb4Ks6v97O_cwAYNxBNOnYwCgiV-6ks5s4lfggaJpZM4PZI9g .

skynavga commented 7 years ago

See TTML2 10.2.17

If a background color applies to an inline area child of a line area, then if the value of this attribute is true, that background area is, for rendering purposes, extended in the block progression dimension so as to be coincident with the before and after edges of the line area; otherwise, if the value of this attribute is false, then that background area is not extended, but remains bounded by the inline area's border rectangle.

Note:

In other words, when this attribute's value is true, background colors rendered on inline areas of adjacent lines abut one another rather than leaving a visible gap in the block progression dimension, i.e., they fill any line gap (also known as leading).

If a computed value of the property associated with this attribute is not supported, then a presentation processor https://w3c.github.io/ttml2/spec/ttml2.html#terms-presentation-processormust use the value false.

On Mon, Nov 20, 2017 at 10:59 PM, Glenn Adams glenn@skynav.com wrote:

The current language found under TTML2

On Mon, Nov 20, 2017 at 9:56 PM, Pierre-Anthony Lemieux < notifications@github.com> wrote:

@skynavga https://github.com/skynavga "extends to the before and after edge of the line area", yes. The commenter wanted to make sure that the background that was being extended was already the one behind the glyphs. What is this background called?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/imsc/issues/254#issuecomment-345916860, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb4Ks6v97O_cwAYNxBNOnYwCgiV-6ks5s4lfggaJpZM4PZI9g .

nigelmegitt commented 7 years ago

Is the word "extended" applicable only because the line stacking strategy means it is impossible for either the line area before or after edge to be within the content rectangle? I think we need to just say that the background painting area's before and after edges are set to be coincident with the line area's before and after edges, and not use the word "extend".

palemieux commented 7 years ago

See also https://github.com/w3c/csswg-drafts/issues/1974

palemieux commented 7 years ago

As a data point, imscJS currently emulates fillLineGap by extending (if needed) the padding rectangle such that its before and after edges are coincident with those of the containing line area.

andreastai commented 7 years ago

@nigelmegitt The scenario you describe is a) as commented an edge case, b) it is also a scenario that is actually out out of scope of the requirements scenario and c) it represents in it-self more an error condition than a common use case.

a)

Can you give an example where you experience this behaviour? That would be very useful. Even if we find a case: does this really matter given the purpose of fill-linegap?

b)

Requirements scenario of fill line gap: background color is applied to either span or p but not to both.

c)

The behaviour that a glyph extends the content rectangle, so that the "content rectangle background color" does not apply, is an undesired behaviour. It is debatable if this is more a problem of the font or the styling model (XSL-FO/CSS).

Because of a+b+c I would like to not deal with this use case in the informative note. Any attempt to deal with it will confuse more than it helps.

nigelmegitt commented 7 years ago

Thanks for the comment @tairt . I believe this scenario is not such an edge case, or at least it is easy to construct. You just need a <p tts:backgroundColor="red"> with a descendant <span> with a different background colour, and character content that, in the chosen font, generates glyphs that go above or below the font table's ascender and descender values.

The specification does not describe the requirements; they are effectively opaque to a reader of the specification document, so even though you're right that fillLineGap originated from those requirements, there are no constraints to prevent the scenario I describe above from happening. Therefore handling this permutation has now fallen within the set of requirements we have to consider. (unless we prohibit the possibility by adding a specification constraint)

I do not believe that glyphs extending outside the content rectangle is a problem either of the font or the styling model, rather that it is a known and permitted possibility, albeit one whose use is relatively rare, especially in latin script layout.

I will object to adding wording, even informatively, that we know is in some situations incorrect, even if those situations are edge cases. We need to find a way to phrase it so that this doesn't happen, for example by removing those edge cases from the scope of the informative text, or by rewording to be more precise.

palemieux commented 7 years ago

@nigelmegitt Please provide an actual test case, otherwise it is not clear what you are even objecting to.

nigelmegitt commented 6 years ago

As agreed on yesterday's call, I've requested further information, at https://github.com/w3c/i18n-activity/issues/399#issuecomment-352059650 - by the way, there's extra context in there that helps explain the origins, but which we didn't spot in this issue here.

css-meeting-bot commented 6 years ago

The Working Group just discussed What fillLineGap does/ affects imsc#254, and agreed to the following resolutions:

The full IRC log of that discussion <nigel> Topic: What fillLineGap does/ affects imsc#254
<nigel> github: https://github.com/w3c/imsc/issues/254
<nigel> Nigel: We've not heard from @klensin on the related i18n issue so I propose to close this
<nigel> .. and add a note to the i18n tracking issue explaining why, and saying that if more
<nigel> .. explanation is forthcoming then we would be happy to reopen.
<nigel> SUMMARY: Closing due to lack of information
css-meeting-bot commented 6 years ago

The Working Group just discussed What fillLineGap does/ affects #254.

The full IRC log of that discussion <nigel> Topic: What fillLineGap does/ affects #254
<nigel> github: https://github.com/w3c/imsc/issues/254
<nigel> Pierre: This one is marked commenter no response already.
<nigel> Thierry: It's okay to close this and I'll pick it up via the labels.