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

Clarify percentage units in padding specification #281

Merged
merged 6 commits into from Jan 4, 2018

Conversation

Projects
None yet
5 participants
@palemieux
Copy link
Contributor

commented Dec 12, 2017

Close #205

@palemieux palemieux added this to the 3rd Ed milestone Dec 12, 2017

@palemieux palemieux self-assigned this Dec 12, 2017

@nigelmegitt
Copy link
Contributor

left a comment

Approving, though it could possibly be improved further - see comment.

@@ -5059,6 +5059,9 @@ before edge, the second applies to the start and end edges, and the third applie
to the after edge.
If four <loc href="#style-value-length">&lt;length&gt;</loc> specifications are provided, then they apply to before, end,
after, and start edges, respectively.</p>
<note role="clarification">
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region then percentage values that apply to either of the two edges are relative to the height of the region.</p>

This comment has been minimized.

Copy link
@nigelmegitt

nigelmegitt Dec 12, 2017

Contributor

Looks good, even if I did have to read it three times. Would it be helpful to mention writing mode dependency explicitly to put the reader's mind in the right place for understanding that before and after are not always top and bottom?

@xchange11
Copy link

left a comment

(mistakenly posted)

@tairt
Copy link
Contributor

left a comment

I agree with @nigelmegitt that it would be good to give some more hints about the relevant aspects. It would be helpful to give examples for two different wirting directions e.g. in the text below:

"For example for a Latin script text with left-to-right-top-to-bottom writing mode the before and after edges correspond to the top and bottom edges of the region. In this case the percentage values that apply to before and after edges are relative to the height of the region. On the other hand for an Asian Script Text with a top-to-bottom-right-to-left writing mode the before and after edges correspond to the right and left edges of the region. In this case the percentage values that apply to before and after edges are relative to the width of the region."

palemieux added some commits Dec 26, 2017

@@ -5071,7 +5071,7 @@ to the after edge.
If four <loc href="#style-value-length">&lt;length&gt;</loc> specifications are provided, then they apply to before, end,
after, and start edges, respectively.</p>
<note role="clarification">
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region then percentage values that apply to either of the two edges are relative to the height of the region.</p>
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region, as is the case for Latin text where <att>tts:writingMode</att> is equal to <code>"lrtb"</code>, then percentage values that apply to either of the two edges are relative to the height of the region. Conversly, if the before and after edges correspond to the right and left edges of the region, as is the case for Japanese text where <att>tts:writingMode</att> is equal to <code>"tbrl"</code>, then percentage values that apply to either of the two edges are relative to the width of the region.</p>

This comment has been minimized.

Copy link
@skynavga

skynavga Dec 26, 2017

Contributor

I do not agree with this change, as it is now attempting to explain (and paraphrase) the relevant XSL-FO semantics of what is meant by writing mode.

This comment has been minimized.

Copy link
@palemieux

palemieux Dec 26, 2017

Author Contributor

@skynavga The proposed modification merely adds a second example. Were you not happy with the original text, which had a single example?

This comment has been minimized.

Copy link
@skynavga

skynavga Dec 26, 2017

Contributor

I already accepted the original text (of line 5074 above shown in red). I do not accept the newest change that further elaborates the example.

This comment has been minimized.

Copy link
@nigelmegitt

nigelmegitt Dec 26, 2017

Contributor

@skynavga is there an error in the newer change with the further elaborated example? It's certainly easier to grasp, and since it is in a clarifying note, that seems like a good thing.

This comment has been minimized.

Copy link
@skynavga

skynavga Dec 26, 2017

Contributor

It now leaves the impression that it applies only to latin and japanese text. There is no need to explain writing mode in this context, and it produces clutter. Too much text is a bad thing and this example has now crossed the line.

This comment has been minimized.

Copy link
@nigelmegitt

nigelmegitt Dec 26, 2017

Contributor

OK in general over-explaining is unhelpful. I don't agree that it leaves the impression that it only applies to latin and japanese text though. Could you please propose something that elaborates better than what was before but does not cross the line @skynavga ?

This comment has been minimized.

Copy link
@tairt

tairt Jan 2, 2018

Contributor

Thanks for the clarifying text, @palemieux. This will help the user to understand the issue.

I agree with @nigelmegitt that the text does not give the impression to be exclusive for Latin or Japanese text. To address @skynavga concern the following could be added:

as is the case for Latin text (or other left-to-right scripts) ...as is the case for Japanese text (or other right-to-left scripts)

I do not think that the commit is "over-explaining" or that it adds "clutter". On the contrary: it provides the necessary examples for users and TTML experts. That this question needed to be discussed in the TTWG and that the issue was possibly overseen is an indication that also the later group could make good use of it.

@nigelmegitt
Copy link
Contributor

left a comment

Additional examples look good to me, and make it easier to understand the point being made.

@palemieux palemieux added the agenda label Jan 1, 2018

@tairt

tairt approved these changes Jan 2, 2018

@@ -5071,7 +5071,7 @@ to the after edge.
If four <loc href="#style-value-length">&lt;length&gt;</loc> specifications are provided, then they apply to before, end,
after, and start edges, respectively.</p>
<note role="clarification">
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region then percentage values that apply to either of the two edges are relative to the height of the region.</p>
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region, as is the case for Latin text where <att>tts:writingMode</att> is equal to <code>"lrtb"</code>, then percentage values that apply to either of the two edges are relative to the height of the region. Conversly, if the before and after edges correspond to the right and left edges of the region, as is the case for Japanese text where <att>tts:writingMode</att> is equal to <code>"tbrl"</code>, then percentage values that apply to either of the two edges are relative to the width of the region.</p>

This comment has been minimized.

Copy link
@tairt

tairt Jan 2, 2018

Contributor

Thanks for the clarifying text, @palemieux. This will help the user to understand the issue.

I agree with @nigelmegitt that the text does not give the impression to be exclusive for Latin or Japanese text. To address @skynavga concern the following could be added:

as is the case for Latin text (or other left-to-right scripts) ...as is the case for Japanese text (or other right-to-left scripts)

I do not think that the commit is "over-explaining" or that it adds "clutter". On the contrary: it provides the necessary examples for users and TTML experts. That this question needed to be discussed in the TTWG and that the issue was possibly overseen is an indication that also the later group could make good use of it.

@skynavga

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2018

I would note that @palemieux, @nigelmegitt, and myself all approved the original PR commit at 2235c34.

And that it was the introduction of new changes to address #281 (review) that we now have a disagreement.

@@ -5070,6 +5070,9 @@ before edge, the second applies to the start and end edges, and the third applie
to the after edge.
If four <loc href="#style-value-length">&lt;length&gt;</loc> specifications are provided, then they apply to before, end,
after, and start edges, respectively.</p>
<note role="clarification">
<p>Pecentage values are relative to the dimension of the region to which they apply. For example, if the before and after edges correspond to the top and bottom edges of the region, as is the case for Latin text where <att>tts:writingMode</att> is equal to <code>"lrtb"</code>, then percentage values that apply to either of the two edges are relative to the height of the region. Conversly, if the before and after edges correspond to the right and left edges of the region, as is the case for Japanese text where <att>tts:writingMode</att> is equal to <code>"tbrl"</code>, then percentage values that apply to either of the two edges are relative to the width of the region.</p>

This comment has been minimized.

Copy link
@nigelmegitt

nigelmegitt Jan 4, 2018

Contributor

just spotted a typo on re-reading: "conversly" -> "conversely".

@nigelmegitt

This comment has been minimized.

Copy link
Contributor

commented Jan 4, 2018

@skynavga the disagreement here is about how detailed and useful we make a clarifying note. The text is not normative, and at least I and @tairt feel it is better in this case to include more explanatory text. @tairt made a proposal to address your concern in #281 (comment) - perhaps you could respond to that?

@skynavga
Copy link
Contributor

left a comment

Think this is too cluttered, and could be more succinct, but will approve in the interest of moving forward.

palemieux added some commits Jan 4, 2018

@palemieux palemieux merged commit 9f4adae into master Jan 4, 2018

3 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
ipr PR deemed acceptable.
Details

@palemieux palemieux removed the agenda label Jan 4, 2018

@skynavga skynavga deleted the issue-205-clarify-padding-percentage branch Mar 11, 2018

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.