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
Clarify that tts:fillLineGap does not hide characters #283
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good! Works for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR does what we agreed, but I now think that what we agreed is wrong, unfortunately.
@@ -995,6 +995,10 @@ <h4>itts:fillLineGap</h4> | |||
<code>p</code> element SHALL extend to the <em>before-edge</em> and <em>after-edge</em> of its containing line area | |||
(<em>before-edge</em> and <em>after-edge</em> are defined at Section 4.2.3 of [[XSL11]]).</p> | |||
|
|||
<p class='note'>The application of <code>itts:fillLineGap="true"</code> does not result in hiding any character glyphs that | |||
would be visible without such application. Therefore after such application all parts of all character glyphs with a | |||
background color behind them continue to have that background color applied.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #254 (comment) - I think there are cases when this wording is not correct, unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my view the text should stay as is, because it makes very clear what the effect is. Wordings that tries to deal with the edge case would confuse more than help. Therefore this edge case should not be part of the informative note.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry @TairT I don't agree, we need to make a change so that the known "edge case" is either clearly excluded or is dealt with in the text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem, @nigelmegitt.
Please provide a font and a character code point where you can see the behaviour of this edge case. Then we could make an example with images that demonstrates the behaviour.
We could also change the text as follows:
Therefore after such application all parts of all characters continue to have the background color that is applied to their span or anonymous span parent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK I'll look for an example. I can not see how the proposed text at #283 (comment) addresses the problem though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can not see how the proposed text at #283 (comment) addresses the problem though.
Ok. The background color value of a glyph is the background color that a character gets from a span parent or the "anonymous span". This color (and not the potential color of a block container), is applied to the gyph.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nigelmegitt If this did not help, can you be specific what part you do not understand?
OK I'll look for an example.
Did you find a font and a character?
Close #254