bugGNU troff - Bugs: bug #42503, Illogical precedence of .hw over...


bug #42503: Illogical precedence of .hw over .hy

Submitted by:  Dave <barx>
Submitted on:  Wed 04 Jun 2014 12:33:36 AM UTC  
Category:  None Severity:  2 - Minor
Item Group:  Incorrect behaviour Status:  Duplicate
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Wed 21 Feb 2018 05:00:55 AM UTC, comment #4: 

Because this bug's description is spread over multiple comments, its title is obsolete, and this bug tracker seemingly lacks the ability to edit a bug title, I have consolidated the various comments here and placed them under a more accurate bug title in bug #53196.  The present bug can thus be closed (which the submitter is seemingly unable to do).

Dave <barx>
Tue 11 Apr 2017 11:43:30 PM UTC, comment #3: 

Additionally, a user asking groff not to split words by leaving only two characters on a line might reasonably expect this to include words already containing hyphens.  However, groff does not honor this restriction, either:

.\" don't hyphenate the first and last two characters of a word
.hy 12
.ll 1i
He's been my go-to guy for math questions.

Dave <barx>
Wed 16 Dec 2015 12:48:14 AM UTC, comment #2: 

(I don't seem to have the ability to change the title of this bug, but the present title is inaccurate, since the bug doesn't depend on the user using .hw at all.)

Dave <barx>
Wed 16 Dec 2015 12:40:40 AM UTC, comment #1: 

Groff also does not obey the .hy value for any words in /usr/share/groff/current/tmac/hyphenex.us.  An example to illustrate:

    .ll 1i
    Visit yonder arboretum.
    Visit yonder archipelago.


    .hy 8  \"should prevent breaking after only two characters
    Visit yonder arboretum.
    Visit yonder archipelago.

This is a more severe issue than the one originally reported: a user should not be expected to redefine the hyphenation of the over 1000 words in this file.  The average user, for that matter, would have no way of even knowing this file was the source of the trouble.

Dave <barx>
Wed 04 Jun 2014 12:33:36 AM UTC, original submission:  

This may not technically be a bug, but it is undocumented that it works this way, and, I believe, not the ideal way to handle this case.

Consider this example:

$ groff -a << EOF

> .hw in-sa-lub-rious
> .hy 8
> insalubrious insalubrious insalubrious insalubrious insalubrious insalubrious
> insalubrious insalubrious i i i i i i i i insalubrious

<beginning of page>
insalubrious insalubrious insalubrious insalubrious insalubrious insalubrious insalubrious insalubrious i i i i i i i i in<hy>

The hyphenation provided in the .hw example says this is a valid hyphenation point.  However, .hy mode 8 should tell groff not to hyphenate after only two characters.

I believe it makes more sense to have the .hy mode take precedence over a possible two-character hyphenation given in .hw, for the following reasons:

1) If you want to change hyphenation behavior, you should only have to change the number given to .hy.  As it stands now, to change hyphenation behavior across the board, one must change both the .hy value and all the words passed to .hw that contain a syllable break after two characters.

2) If .hy mode 2 is active, it applies regardless of any .hw settings.  The precedence rules should be consistent across all interactions between .hw and .hy.

If the behavior is left as is, it should be documented in the .hw command.

(Also posted to bug-groff: http://lists.gnu.org/archive/html/bug-groff/2013-10/msg00000.html)

Dave <barx>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by schwarze (Updated the item)
  • -email is unavailable- added by barx (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-21 schwarze Severity1 - Wish => 2 - Minor
        Item GroupNew feature => Incorrect behaviour
        StatusNone => Duplicate
        Open/ClosedOpen => Closed
    2018-02-16 schwarze Severity3 - Normal => 1 - Wish
        Item GroupNone => New feature

    Back to the top

    Powered by Savane 3.5