[bug #66054] [troff] permit special characters as source hyphenation codes

[Dave]

Follow-up Comment #18, bug #66054 (group groff):

[comment #14 comment #14:]
> [comment #12 comment #12:]
> > Oh, I see.  I thought the 3rd résumé wouldn't hyphenate, but it did.
> 
> I'm not sure whether anything here needs to be fixed, because
> I don't know if this is expected behavior.

Branden's comment #12 showed this was not behavior _he_ expected.

To recap, the "3rd résumé" comes from this input:

.ll 1n
r\['e]sum\['e]
.hcode é e       \" sets up a mapping
r\['e]sum\['e]
.hcode é é       \" undoes that mapping, maybe?
r\['e]sum\['e]   \" ... what happens now?

What made the behavior unexpected to _me_ is that you can get this break point
by trimming this example down:

.ll 1n
r\['e]sum\['e]
.hcode é é       \" sets an hcode but maps it to no existing ones
r\['e]sum\['e]   \" ... what happens now?

which has long (going back to at least groff 1.19.2) produced:

résumé
ré-
sumé

The reason this surprised me is that the English patterns and exceptions list
contain only ASCII characters.  So a nonzero hcode for é, not mapped to
anything in ASCII, shouldn't be able to change any break points.

The light bulb finally clicked on when I (re)read Werner's explanation in the
info manual (also dating back to at least groff 1.19.2, and substantially
unchanged today; quoted in full in comment #10) about how hyphenation for the
word "Kindergärten" worked without and without the additional .hcodes in that
example.

I think that resolves the last remaining mystery in my head about this bug.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66054>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature