Discussion:
Hanging Punctuation Questions
David Hyatt
2016-03-04 22:39:49 UTC
Permalink
I have begun implementing hanging punctuation in WebKit. So far the “first” and “last” values are supported, and “allow-end/force-end” are coming soon. I had a few questions after implementing:

(1) Can you only hang one character? That’s what I did, but if there’s a run of characters all in the Ps category should I be hanging them all when hanging-punctuation is “first” or just a single one? (Similar question for “last”.) In my research of typography examples, I do see situations where - for example - a period and quote mark together both get hung.

(2) Normal quotation marks don’t belong to Ps/Pe/Pf/Pi. Not an issue necessarily but figured I’d bring that up in case it’s an oversight that those can’t be hung.

(3) allow-end/force-end doesn’t include hyphens. In my research of hanging punctuation, I found typographic examples of hanging punctuation where hyphens hang at the end of lines of justified text. I wonder if this should be an additional value to the property. It’s unclear to me if people want this capability or not, but I figured I’d mention it since I found examples of it.

(4) How to handle kerning, e.g., for hanging-punctuation:first, if I hang an opening quote mark, the next letter may also be offset to the left, since it pushes into the quotation mark. Should kerning simply be turned off when you hang punctuation between the hung punctuation and the following glyph?

(5) “Non-zero inline-axis borders or padding between a hangable mark and the edge of the line prevent the mark from hanging.” I would include margins also, i.e., any “spacer” introduced by inlines should turn off hanging.

(6) The WG resolved overflow is ink overflow. I think it should be scrollable overflow. I can elaborate on this if needed, but it’s a selectable character that has to be reachable when edited and cut/copied etc. Any designer is going to leave space for hanging punctuation if they turn it on, so fears of scrollbars are unfounded IMO. It’s also an annoying amount of additional work to treat that as ink overflow when the common sense implementation just moves the line box (and line boxes are scrollable overflow obviously). This is similar to text-indent, which creates layout overflow when negative, so it’s not clear to me why hanging punctuation can’t behave the same way.

Regardless of ink vs. layout, the designer has to leave space for hanging punctuation if they decide to use this feature, so I would prefer we go with the more common sense implementation choice.

Thanks!
dave
(***@apple.com)
John Hudson
2016-03-05 20:20:44 UTC
Permalink
Dear David,

Some general comments on hanging punctuation:

The practice of hanging punctuation is so neglected, that a lot of
people — including experienced digital typographers — do not favour it,
or wish it to be implemented in a discreet way that involves a kind of
compromise: punctuation extending a little into the margins, but not
fully hanging. That kind of 'optical' alignment of margins is best
accomplished, though, if it also takes into account letter shape
(Adobe's optical margins algorithm attempts this, fairly well for
European scripts and disastrously for many others). I consider this
something different from hanging punctuation in the traditional sense,
which is a practice in metal typography based, in turn, on manuscript
models.

Hanging punctuation is based on the observation that a small black
intrusion into the expanse of white margin is less disruptive of the
appearance of a block of text than the corresponding intrusion of white
space into the text would be. This is important to understand and to
see. I learned from letterpress printers to check margins by holding the
page at a shallow angle, looking up the line of the margin. I recommend
this, as it makes evident just how much more impact white space
intruding into the text has than punctuation intruding into the margin.


That said, some responses to your questions, and an attempt to define a
Post by David Hyatt
(1) Can you only hang one character? That’s what I did, but if there’s a run of characters all in the Ps category should I be hanging them all when hanging-punctuation is “first” or just a single one? (Similar question for “last”.) In my research of typography examples, I do see situations where - for example - a period and quote mark together both get hung.
Correct. Another case would be stacked quotes '", and that of course
implies e.g. ,'"

This is where things start extending too far into the margin: one or two
narrow punctuation marks in the margin are fine, but wider punctuation
(dashes, ellipsis) and multiple punctuation marks draw too much
attention to themselves and stick out too far.

My take on this is that there should be a maximum distance beyond which
punctuation should not extend.
Post by David Hyatt
(3) allow-end/force-end doesn’t include hyphens. In my research of hanging punctuation, I found typographic examples of hanging punctuation where hyphens hang at the end of lines of justified text. I wonder if this should be an additional value to the property. It’s unclear to me if people want this capability or not, but I figured I’d mention it since I found examples of it.
Hyphens should definitely hang if punctuation is hanging. Hyphens are
among the most obvious candidates for hanging because they carry so much
white space above and below them.

[By the same token, it should be obvious that punctuation such as ! and
? do not hang.]
Post by David Hyatt
(4) How to handle kerning, e.g., for hanging-punctuation:first, if I hang an opening quote mark, the next letter may also be offset to the left, since it pushes into the quotation mark. Should kerning simply be turned off when you hang punctuation between the hung punctuation and the following glyph?
The easiest way to think about this is in terms of the purpose of
hanging punctuation, i.e. to create a tidy block of text in which the
margins are characterised by the shapes of letters, rather than the
intrusion of white space around punctuation. Therefore, it follows that
hanging punctuation should take into account kerning to letters. So, for
example, if a line begins with a double quotation mark and an uppercase
A, I would expect kerning to be applied between two two, and that the
punctuation only extend so far into the margin as would align the A with
the same letter starting a line by itself above or below. In other
words, the hang of the quotation mark would be it's normal hang distance
minus it's kern to the A.


So:

1. Hang individual, narrow punctuation — including hyphen — full in the
margin.

2. Establish a maximum hang distance to allow multiple punctuation and
wider punctuation to extend into the margin (probably slightly wider
than the hyphen).

3. Adjust hang distance based on kerning to adjacent non-hanging letters
and other characters.


JH
--
John Hudson
Tiro Typeworks Ltd www.tiro.com
Salish Sea, BC ***@tiro.com

Getting Spiekermann to not like Helvetica is like training
a cat to stay out of water. But I'm impressed that people
know who to ask when they want to ask someone to not like
Helvetica. That's progress. -- David Berlow
fantasai
2016-03-08 05:02:06 UTC
Permalink
Post by John Hudson
Dear David,
The practice of hanging punctuation is so neglected, that a lot of people — including experienced digital typographers — do
not favour it, or wish it to be implemented in a discreet way that involves a kind of compromise: punctuation extending a
little into the margins, but not fully hanging. That kind of 'optical' alignment of margins is best accomplished, though, if
it also takes into account letter shape (Adobe's optical margins algorithm attempts this, fairly well for European scripts and
disastrously for many others). I consider this something different from hanging punctuation in the traditional sense, which is
a practice in metal typography based, in turn, on manuscript models.
Thanks, John, for the information. :) Just wanted to point out, that the
'end' and 'force-end' values of 'hanging-punctuation' at this level are
designed primarily for CJK typography, so the considerations are a bit
different--while the end result is still about a strong right edge,
there's more consideration to the character grid and thus optical kerning
isn't a good solution.

Handling Western requirements is definitely something we would like to add,
so definitely your comments are something to take into consideration. I've
been thinking we should use a different set of keywords for optical alignment,
though, so as not to mix up the behaviors.

~fantasai
Xidorn Quan
2016-03-06 01:27:17 UTC
Permalink
Post by David Hyatt
(6) The WG resolved overflow is ink overflow. I think it should be
scrollable overflow. I can elaborate on this if needed, but it’s a
selectable character that has to be reachable when edited and cut/copied
etc. Any designer is going to leave space for hanging punctuation if they
turn it on, so fears of scrollbars are unfounded IMO. It’s also an annoying
amount of additional work to treat that as ink overflow when the common
sense implementation just moves the line box (and line boxes are scrollable
overflow obviously). This is similar to text-indent, which creates layout
overflow when negative, so it’s not clear to me why hanging punctuation
can’t behave the same way.
Regardless of ink vs. layout, the designer has to leave space for hanging
punctuation if they decide to use this feature, so I would prefer we go
with the more common sense implementation choice.
The reason that we decided to make it an ink overflow is that, many
punctuations in CJK are full-width while their ink just takes less than
half of the space. It is especially true for Simplified Chinese and
Japanese, for stop and comma. It means that, it is completely fine to have
a space which is enough to show the ink but not enough from the metrics.
Making hanging punctuation scrollable overflow could confuse people in this
reasonable usecase.

- Xidorn
Takao Baba
2016-03-06 05:32:52 UTC
Permalink
Post by David Hyatt
(6) The WG resolved overflow is ink overflow. I think it should be scrollable overflow.
I can elaborate on this if needed, but it’s a selectable character that has to be reachable when edited and cut/copied etc.
As I posted last month, I also think the hang character should be
guaranteed visible, at least in editing mode.
https://lists.w3.org/Archives/Public/www-style/2016Feb/0006.html

(But the reason Xidorn mentioned is reasonable too. I don't have good
idea which satisfies both things right now.)
Post by David Hyatt
This is similar to text-indent, which creates layout overflow when negative,
so it’s not clear to me why hanging punctuation can’t behave the same way.
I understood that the negative text-indent creates an ink overflow,

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3851
because there are no scrollbars in this example (by [1]).

But CSS2 [2] seems saying that it creates an scrollable overflow, like you.
Post by David Hyatt
If the value of 'text-indent' is either negative or exceeds the width of the block, that first box, described above,
can overflow the block. The value of 'overflow' will affect whether such text that overflows the block is visible.
I couldn't find other clarification in css3-text and css3-overflow.

Is this a browser bug (or "implementation-specific limits"), or my
misunderstanding?

[1] http://logs.csswg.org/irc.w3.org/css/2016-01-31/#e645715
[2] https://www.w3.org/TR/CSS2/text.html#indentation-prop
----------------------------------------------------
Takao Baba (***@bpsinc.jp)
Beyond Perspective Solutions Co., Ltd.
Tel: 03-6279-4320 Fax: 03-6279-4450
http://www.bpsinc.jp
Post by David Hyatt
Post by David Hyatt
(6) The WG resolved overflow is ink overflow. I think it should be
scrollable overflow. I can elaborate on this if needed, but it’s a
selectable character that has to be reachable when edited and cut/copied
etc. Any designer is going to leave space for hanging punctuation if they
turn it on, so fears of scrollbars are unfounded IMO. It’s also an annoying
amount of additional work to treat that as ink overflow when the common
sense implementation just moves the line box (and line boxes are scrollable
overflow obviously). This is similar to text-indent, which creates layout
overflow when negative, so it’s not clear to me why hanging punctuation
can’t behave the same way.
Regardless of ink vs. layout, the designer has to leave space for hanging
punctuation if they decide to use this feature, so I would prefer we go with
the more common sense implementation choice.
The reason that we decided to make it an ink overflow is that, many
punctuations in CJK are full-width while their ink just takes less than half
of the space. It is especially true for Simplified Chinese and Japanese, for
stop and comma. It means that, it is completely fine to have a space which
is enough to show the ink but not enough from the metrics. Making hanging
punctuation scrollable overflow could confuse people in this reasonable
usecase.
- Xidorn
Florian Rivoal
2016-03-06 05:35:00 UTC
Permalink
Post by David Hyatt
(6) The WG resolved overflow is ink overflow. I think it should be scrollable overflow. I can elaborate on this if needed, but it’s a selectable character that has to be reachable when edited and cut/copied etc. Any designer is going to leave space for hanging punctuation if they turn it on, so fears of scrollbars are unfounded IMO. It’s also an annoying amount of additional work to treat that as ink overflow when the common sense implementation just moves the line box (and line boxes are scrollable overflow obviously). This is similar to text-indent, which creates layout overflow when negative, so it’s not clear to me why hanging punctuation can’t behave the same way.
Regardless of ink vs. layout, the designer has to leave space for hanging punctuation if they decide to use this feature, so I would prefer we go with the more common sense implementation choice.
The reason that we decided to make it an ink overflow is that, many punctuations in CJK are full-width while their ink just takes less than half of the space. It is especially true for Simplified Chinese and Japanese, for stop and comma. It means that, it is completely fine to have a space which is enough to show the ink but not enough from the metrics. Making hanging punctuation scrollable overflow could confuse people in this reasonable usecase.
What we also suggested in Sydney, but I think that was during a break, is that hanging punctuation should be ink overflow (for the reason said by Xidorn) in general, but that is should be turned into scrollable overflow when the text is editable.

But if that's too complicated, maybe there's another way to deal with this? Could we say that the ink of the hanging punctuation is scrollable overflow? As long as the empty right halves of "、" and "。" don't cause scrollbars, we're good. "Ink overflow, unless editable" does that, but maybe there's a better way.

- Florian
fantasai
2016-09-24 22:28:58 UTC
Permalink
Post by David Hyatt
I have begun implementing hanging punctuation in WebKit. So far the
“first” and “last” values are supported, and “allow-end/force-end”
(1) Can you only hang one character? That’s what I did, but if
there’s a run of characters all in the Ps category should I be
hanging them all when hanging-punctuation is “first” or just a
single one? (Similar question for “last”.) In my research of
typography examples, I do see situations where - for example -
a period and quote mark together both get hung.
The spec currently says
“At most one punctuation character may hang at each edge of the line.”
and for CJK typesetting this is a correct requirement.

Western typesetting is a bit more complicated because we sometimes
kern punctuation together, such as your quote-mark + period example,
which frequently results in a kerned pair.

So a question would be, if we hang the full unkerned advance width
of the hung punctuation, would that be sufficient to address this
case? Or does the full advance of both characters need to hang
regardless of kerning?
Post by David Hyatt
(2) Normal quotation marks don’t belong to Ps/Pe/Pf/Pi. Not an
issue necessarily but figured I’d bring that up in case it’s an
oversight that those can’t be hung.
Definitely an oversight. I'll add them to the list... surprised
they aren't in either Pf or Pi!
Post by David Hyatt
(3) allow-end/force-end doesn’t include hyphens. In my research
of hanging punctuation, I found typographic examples of hanging
punctuation where hyphens hang at the end of lines of justified
text. I wonder if this should be an additional value to the
property. It’s unclear to me if people want this capability or
not, but I figured I’d mention it since I found examples of it.
Yes, I figured hyphens might need to be added to handle Western
hanging punctuation. However since the all requirements of Western
hanging punctuation weren't clear enough to design a feature that
handled it well, and CJK hanging-punctuation was both more critical
and sufficiently well-defined I didn't quite tackle the Western
requirements in this level. (As far as I'm aware, CJK doesn't hang
hyphens.)

See also discussion at
http://www.w3.org/Mail/flatten/index?subject=Amending+hanging-punctuation+for+Western+typography&list=www-style
Post by David Hyatt
(4) How to handle kerning, e.g., for hanging-punctuation:first,
if I hang an opening quote mark, the next letter may also be offset
to the left, since it pushes into the quotation mark. Should kerning
simply be turned off when you hang punctuation between the hung
punctuation and the following glyph?
My guess is you subtract the amount of kerning from the amount of hang
so the character adjacent to the hanging one is aligned according to
its side bearing. However, we should probably check with people who
know better. :)
Post by David Hyatt
(5) “Non-zero inline-axis borders or padding between a hangable mark
and the edge of the line prevent the mark from hanging.” I would
include margins also, i.e., any “spacer” introduced by inlines should
turn off hanging.
This was discussed in
https://www.w3.org/mid/***@antenna.co.jp
and the conclusion was to only consider borders and padding.
Post by David Hyatt
(6) The WG resolved overflow is ink overflow. I think it should be
scrollable overflow. I can elaborate on this if needed, but it’s a
selectable character that has to be reachable when edited and
cut/copied etc. Any designer is going to leave space for hanging
punctuation if they turn it on, so fears of scrollbars are unfounded
IMO. It’s also an annoying amount of additional work to treat that
as ink overflow when the common sense implementation just moves the
line box (and line boxes are scrollable overflow obviously). This
is similar to text-indent, which creates layout overflow when
negative, so it’s not clear to me why hanging punctuation can’t
behave the same way.
Regardless of ink vs. layout, the designer has to leave space for
hanging punctuation if they decide to use this feature, so I would
prefer we go with the more common sense implementation choice.
Your logic makes sense to me. I will reraise the issue with the CSSWG
(along with the rest).

~fantasai
Florian Rivoal
2016-09-25 20:59:10 UTC
Permalink
<html><head></head><body class="ApplePlainTextBody" dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><blockquote type="cite">On Sep 25, 2016, at 00:28, fantasai &lt;***@inkedblade.net&gt; wrote:<br><br>On 03/04/2016 10:39 PM, David Hyatt wrote:<br><br><blockquote type="cite">(6) The WG resolved overflow is ink overflow. I think it should be<br>scrollable overflow. I can elaborate on this if needed, but it’s a<br>selectable character that has to be reachable when edited and<br>cut/copied etc. Any designer is going to leave space for hanging<br>punctuation if they turn it on, so fears of scrollbars are unfounded<br>IMO. It’s also an annoying amount of additional work to treat that<br>as ink overflow when the common sense implementation just moves the<br>line box (and line boxes are scrollable overflow obviously). This<br>is similar to text-indent, which creates layout overflow when<br>negative, so it’s not clear to me why hanging punctuation can’t<br>behave the same way.<br><br>Regardless of ink vs. layout, the designer has to leave space for<br>hanging punctuation if they decide to use this feature, so I would<br>prefer we go with the more common sense implementation choice.<br></blockquote><br>Your logic makes sense to me. I will reraise the issue with the CSSWG<br>(along with the rest).<br></blockquote><br>The problem with that is that "、" and "。", which you want to hang in CJK,<br>are wide characters whose right half is empty. A reasonable designer would definitely<br>leave enough padding for the visible part of the character to live in, but they may not<br>leave enough padding to include the blank part of the character as well.<br><br>Had we not had that problem, I would agree that scrollable overflow is fine, but we do.<br><br>Maybe we can special-case these somehow?<br><br> - Florian</body></html>
fantasai
2018-03-05 08:28:51 UTC
Permalink
Post by fantasai
Post by David Hyatt
I have begun implementing hanging punctuation in WebKit. So far the
“first” and “last” values are supported, and “allow-end/force-end”
(1) Can you only hang one character? That’s what I did, but if
there’s a run of characters all in the Ps category should I be
hanging them all when hanging-punctuation is “first” or just a
single one? (Similar question for “last”.) In my research of
typography examples, I do see situations where - for example -
a period and quote mark together both get hung.
The spec currently says
    “At most one punctuation character may hang at each edge of the line.”
and for CJK typesetting this is a correct requirement.
Western typesetting is a bit more complicated because we sometimes
kern punctuation together, such as your quote-mark + period example,
which frequently results in a kerned pair.
So a question would be, if we hang the full unkerned advance width
of the hung punctuation, would that be sufficient to address this
case? Or does the full advance of both characters need to hang
regardless of kerning?
...
Post by fantasai
Post by David Hyatt
(4) How to handle kerning, e.g., for hanging-punctuation:first,
if I hang an opening quote mark, the next letter may also be offset
to the left, since it pushes into the quotation mark. Should kerning
simply be turned off when you hang punctuation between the hung
punctuation and the following glyph?
My guess is you subtract the amount of kerning from the amount of hang
so the character adjacent to the hanging one is aligned according to
its side bearing. However, we should probably check with people who
know better. :)
FWIW, CSSWG discussed this in
https://lists.w3.org/Archives/Public/www-style/2016Oct/0115.html
and concluded that it didn't know for sure what to do, so the interaction
of kerning and hanging-punctuation is now marked as undefined.
https://drafts.csswg.org/css-text-3/#hanging-punctuation-property

If anyone has further insights on this, let us know, maybe we'll define
it in Level 4. :)

~fantasai
John Hudson
2018-03-05 18:54:00 UTC
Permalink
Post by fantasai
Post by fantasai
Post by David Hyatt
(4) How to handle kerning, e.g., for hanging-punctuation:first,
if I hang an opening quote mark, the next letter may also be offset
to the left, since it pushes into the quotation mark. Should kerning
simply be turned off when you hang punctuation between the hung
punctuation and the following glyph?
My guess is you subtract the amount of kerning from the amount of hang
so the character adjacent to the hanging one is aligned according to
its side bearing. However, we should probably check with people who
know better. :)
FWIW, CSSWG discussed this in
https://lists.w3.org/Archives/Public/www-style/2016Oct/0115.html
and concluded that it didn't know for sure what to do, so the interaction
of kerning and hanging-punctuation is now marked as undefined.
https://drafts.csswg.org/css-text-3/#hanging-punctuation-property
If anyone has further insights on this, let us know, maybe we'll define
it in Level 4. :)
Since the purpose of hanging punctuation is optical alignment of text
block edges — in which the intrusion of white space from the margin
around punctuation is has greater visual impact than the intrusion of
punctuation into the margin —, I would say David is right that the best
solution is to subtract the kern distance from the distance that the
punctuation hangs in the margin (or add, in the case of a positive kern
value). The goal is to get the preceding letter to align with the
letters above and below on the margin edge.

There are complications, of course. Sequences of multiple punctuation
signs — e.g. ," — or wider punctuation signs — e.g. 
— shouldn't
completely hang, because there comes a point at which intrusion into the
margin becomes more distracting. So hanging punctuation needs a maximum
distance, and to further complicate things this distance might not be
the same at all text sizes (as a general rule, the smaller the type, the
more generous the relative hang distance can be).

JH
--
John Hudson
Tiro Typeworks Ltd www.tiro.com
Salish Sea, BC ***@tiro.com

NOTE: In the interests of productivity, I am currently
dealing with email on only two days per week, usually
Monday and Thursday unless this schedule is disrupted
by travel. If you need to contact me urgently, please
use some other method of communication. Thank you.
Loading...