-
Notifications
You must be signed in to change notification settings - Fork 87
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
Replaced 'break' with 'beginning' for page|line|column|gathering in Guidelines and Specs #2634
base: dev
Are you sure you want to change the base?
Conversation
@sydb Might as well have a look at this while you're at it? |
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.
The majority of my suggestions for change, here, are underpinned by my strong distaste for using the noun “beginning” unless it is being used to gloss an element itself or very specifically about the beginning of a feature. Others may disagree.
@@ -426,7 +426,7 @@ dates, and predefined value lists.</note></p></div> | |||
individual characters, the overall typesetting process also | |||
follows specific rules of how to calculate the distance between | |||
characters, how much whitespace occurs between words, at which | |||
points line breaks might occur and so forth. </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.
This use of the term has nothing to do with our <lb>
element, and perhaps should just be left as “break”.
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.
How would you feel about rewriting the above without "break" and to avoid repetition of "occurs" and "occur":
"... at which points new lines might begin and so forth"
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.
Ooh, I like that; but I think I would like a more complete re-write better:
It might nevertheless be helpful to put some of the terminology used for the rendering process in the context of the discussion of this chapter. As was mentioned above, Unicode encodes abstract characters, not specific glyphs. For any process that makes characters visible, however, concrete, specifically designed glyph shapes have to be used. For a printing process, for example, these shapes describe exactly at which point ink has to be put on the paper and which areas have to be left blank. If we want to print a character from the Latin script, besides the selection of the overall glyph shape, this process also requires that a specific weight and size of the font has been selected, and to what degree the shape should be slanted. Beyond individual characters, the overall typesetting process also needs to follow specific rules for calculating the distance between characters, for determining how much whitespace occurs between any two words, and how long each line should be (and thus at which points a new line begins), and so forth.
(Feel free to ignore, use, or tweak.)
@@ -329,7 +329,7 @@ problem for text encoders. Suppose, for example, that we wish to | |||
investigate a diachronic English corpus for occurrences of | |||
<mentioned>tea-pot</mentioned> and <mentioned>teapot</mentioned>, to | |||
find evidence for the point at which this compound becomes | |||
lexicalized. Any case where the word is hyphenated across a linebreak, |
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 use of the term has nothing to do with our <lb>
element, and perhaps should just be left as “line break”. (Note the space — 18 of the 25 occurences of "line.?break" in the Guidelines have a space. (One has a hyphen, and six have the single word version.)
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.
Further down on line 353, "line division" is used. For consistency, I've rewritten line 332 using "division" instead of "beginning" and "break". Hopefully, this substitution is acceptable?
"Any case where the word is hyphenated across a linebreak..."
Thank you very much, too, for spotting the different renderings of the term throughout the Guidelines.
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.
Seems fine. But with respect to the different renderings of the term, no pat on the back for just finding them; I have not gone out and fixed them, yet. 😄
@trishaoconnor Just letting you know I've just cherry-picked a single-character commit fix from dev into this branch just to make sure it didn't cause any issues. It was a typo in the boustrophedon section of WD-NonStandardCharacters.xml which just needed an added s, found by @sydb. Doesn't affect any of the other stuff in your branch. |
Thank you very much @sydb for your thorough review and thank you too @martindholmes for fixing that typo and merging it to the PR. I appreciate your point @sydb and thank you very much for highlighting the passages where "beginning" isn't an appropriate substitution for "break". I confess that I still have a preference for using "beginning" instead of "break" and would be in favour of rewriting these passages along similar lines to the example that you supplied above:
Of course, if the general consensus is to revert to "break" instead, I'll happily do so. |
Replaced 'break' with 'beginning' for page|line|column|gathering in the following files from the Guidelines and Specs:
There were no mentions of 'break' in the prose of
<gb>
but I deleted an superfluous space in the proseThe requested changes to
<lb>
are addressed in PR #2633.