Re: UAX #14: Allowing breaks before en dashes

--000000000000b3043c064e4e7d33
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dear Le=CC=81ane,

Interestingly, rule LB12a and the Line_Break class of EN DASH have changed
recently, although not in a way that affects the behaviour you describe: EN
DASH used to be lb=3DBA, and LB12a did not mention HH (because this class d=
id
not exist). See L2/24-224
<https://www.unicode.org/L2/L2024/24224-utc181-properties-recs.pdf> Section
6.1 and UTC decision 181-C35
<https://www.unicode.org/L2/L2024/24221.htm#181-C53>.

Indeed, the changes were made in such a way to not alter the effect of rule
LB12a. However, a look at the rationale for LB12a, namely

> Allowing a break after BA <https://www.unicode.org/reports/tr14/#BA> or H=
Y
> <https://www.unicode.org/reports/tr14/#HY> matches widespread
> implementation practice and supports a common way of handling special lin=
e
> breaking of explicit hyphens, such as in Polish and Portuguese.

shows two things:

   1. I forgot to update this sentence to mention HH;
   2. now that hyphens have moved to HH, there is no reason for BA to be in
   this rule.

Now, removing BA from LB12a would not fix the problem on its own; but we
could then move EN DASH back from HH to BA, and this should do the trick.

I will bring a proposal for that to the Properties & Algorithms Group
<https://www.unicode.org/consortium/props-algorithms.html>.

Best regards,

Robin Leroy

Le lun. 30 mars 2026 =C3=A0 21:03, L=C3=A9ane GRASSER via Unicode <
[email protected]> a =C3=A9crit :

> Hi,
>
> Recently, while setting up typographic conventions for the French
> newspaper I contribute to, I noticed an issue that affected en dashes
> (U+2013), but not em dashes (U+2014).
>
> We collectively decided to use en dashes for parentheticals rather than e=
m
> dashes, because of their limited size, improved readability over
> hyphen-minus, and Unicode "compliance". We also put a non-breaking space
> (U+00A0) inside the parenthetical and a regular space (U+0020) outside.
>
> Example, with "--" as an en dash: Nous mangions des pommes[SP]--[NBSP]les
> plus rouges au monde[NBSP]--[SP]sous les arbres.
>
> However, since en dashes are considered unambiguous hyphens (HH) in UAX
> #14, the tailorable line breaking rule LB12a means that there *can* be a
> line break after en dashes, even with a non-breaking space. LB21 also
> specifies that there shouldn't be a line break before HHs.
>
> This is a problem in our case, as we, like many other major French
> publications, use en dashes for parentheticals and therefore can't join t=
he
> opening dash and the word after with a simple NBSP. This results in the
> opening dash being placed at the end of the line, which is undesirable. E=
m
> dashes are unaffected due to being categorized as B2 rather than HH.
>
> We eventually decided to resort to the WORD JOINER + NBSP combo, rather
> than falling back to em dashes--but it feels quite hacky.
>
> Therefore, I would like to suggest allowing breaks before the en dash
> character (U+2013), perhaps by moving the character from HH to B2 along
> with em dash.
>
> Regards,
> L=C3=A9ane Grasser
>
>
> PS. I tried to search this mailing list's archive up to 2014 and couldn't
> find a discussion regarding this very topic. Sorry in advance if it's
> already been discussed.
>
>

--000000000000b3043c064e4e7d33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear Le=CC=81ane,<div><br></div><div>Interestingly, rule L=
B12a and the Line_Break class of EN DASH have changed recently, although no=
t in a way that affects the behaviour you describe: EN DASH used to be lb=
=3DBA, and LB12a did not mention HH (because this class did not exist). See=
 <a href=3D"https://www.unicode.org/L2/L2024/24224-utc181-properties-recs.p=
df" target=3D"_blank">L2/24-224</a>=C2=A0Section 6.1 and UTC decision <a hr=
ef=3D"https://www.unicode.org/L2/L2024/24221.htm#181-C53" target=3D"_blank"=
>181-C35</a>.</div><div><br></div><div>Indeed, the changes were made in suc=
h a way to not alter the effect of rule LB12a. However, a look at the ratio=
nale for LB12a, namely</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><span style=3D"color:rgb(0,0,0);font-family:Arial,Geneva,sans-serif;font=
-size:medium">Allowing a break after=C2=A0</span><a href=3D"https://www.uni=
code.org/reports/tr14/#BA" style=3D"color:rgb(128,128,128);text-decoration-=
line:none;font-weight:bold;font-family:Arial,Geneva,sans-serif;font-size:me=
dium" target=3D"_blank">BA</a><span style=3D"color:rgb(0,0,0);font-family:A=
rial,Geneva,sans-serif;font-size:medium">=C2=A0or=C2=A0</span><a href=3D"ht=
tps://www.unicode.org/reports/tr14/#HY" style=3D"color:rgb(128,128,128);tex=
t-decoration-line:none;font-weight:bold;font-family:Arial,Geneva,sans-serif=
;font-size:medium" target=3D"_blank">HY</a><span style=3D"color:rgb(0,0,0);=
font-family:Arial,Geneva,sans-serif;font-size:medium">=C2=A0matches widespr=
ead implementation practice and supports a common way of handling special l=
ine breaking of explicit hyphens, such as in Polish and Portuguese.</span><=
/blockquote><div>shows two things:</div><div><ol><li>I forgot to update thi=
s sentence to mention HH;</li><li>now that hyphens have moved to HH, there =
is no reason for BA to be in this rule.</li></ol><div>Now, removing BA from=
 LB12a would not fix the problem on its own; but we could then move EN DASH=
 back from HH to BA, and this should do the trick.</div></div><div><br></di=
v><div>I will bring a proposal for that to the <a href=3D"https://www.unico=
de.org/consortium/props-algorithms.html">Properties &amp; Algorithms Group<=
/a>.</div><div><br></div><div>Best regards,</div><div><br></div><div>Robin =
Leroy</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">Le=C2=A0lun. 30 mars 2026 =C3=A0=C2=A021:03, L=C3=A9ane GRASSER =
via Unicode &lt;<a href=3D"mailto:[email protected]" target=3D"_blan=
k">[email protected]</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Recently, while setting up typographic conventions for the French newspaper=
 I contribute to, I noticed an issue that affected en dashes (U+2013), but =
not em dashes (U+2014).<br>
<br>
We collectively decided to use en dashes for parentheticals rather than em =
dashes, because of their limited size, improved readability over hyphen-min=
us, and Unicode &quot;compliance&quot;. We also put a non-breaking space (U=
+00A0) inside the parenthetical and a regular space (U+0020) outside.<br>
<br>
Example, with &quot;--&quot; as an en dash: Nous mangions des pommes[SP]--[=
NBSP]les plus rouges au monde[NBSP]--[SP]sous les arbres.<br>
<br>
However, since en dashes are considered unambiguous hyphens (HH) in UAX #14=
, the tailorable line breaking rule LB12a means that there *can* be a line =
break after en dashes, even with a non-breaking space. LB21 also specifies =
that there shouldn&#39;t be a line break before HHs.<br>
<br>
This is a problem in our case, as we, like many other major French publicat=
ions, use en dashes for parentheticals and therefore can&#39;t join the ope=
ning dash and the word after with a simple NBSP. This results in the openin=
g dash being placed at the end of the line, which is undesirable. Em dashes=
 are unaffected due to being categorized as B2 rather than HH.<br>
<br>
We eventually decided to resort to the WORD JOINER + NBSP combo, rather tha=
n falling back to em dashes--but it feels quite hacky.<br>
<br>
Therefore, I would like to suggest allowing breaks before the en dash chara=
cter (U+2013), perhaps by moving the character from HH to B2 along with em =
dash.<br>
<br>
Regards,<br>
L=C3=A9ane Grasser<br>
<br>
<br>
PS. I tried to search this mailing list&#39;s archive up to 2014 and couldn=
&#39;t find a discussion regarding this very topic. Sorry in advance if it&=
#39;s already been discussed.<br>
<br>
</blockquote></div>

--000000000000b3043c064e4e7d33--