bugGNU roff - Bugs: bug #53837, Feature request: mechanism to...


bug #53837: Feature request: mechanism to control .hw/.hy interaction

Submitter:  Dave <barx>
Submitted:  Fri 04 May 2018 07:44:27 PM UTC
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Wed 15 Jan 2020 09:32:32 PM UTC, comment #1: 

Bug #55070 is another request for more advanced control over hyphenation.  The issues are not strongly related, but both involve an overhaul in fundamental ways hyphenation is controlled, so perhaps should be considered in tandem.

Dave <barx>
Group Member
Fri 04 May 2018 07:44:27 PM UTC, original submission:  

In bug #53196 comment #1, Werner illustrates a case where it makes sense for hyphenation points that the user defines with .hw to override the global hyphenation value set with .hy.

I believe there are equally valid cases where the opposite should hold.  (See rationale below.)

Thus I am requesting a groff enhancement whereby the user can control whether a document's .hy setting affects hyphenation points defined with .hw.  This could be implemented via a new request, new values for .hy (which so far uses only 6 of its available 32 bits), or some other means.

Or for more flexibility than a new global flag, the .hw request could accept two different hyphenation markers in its words (- and +, say) to differentiate hyphenation points that should be subject to .hy from those that should not.


Typically, one varies the hyphenation freedom (via the .hy request) based on the column width.  In a document that alternates between wide and narrow columns multiple times, one might adjust the value of .hy at each of these alternation points.

As it stands, to get the full benefit of these changes, at each of these points the user must also redefine words defined with .hw.  This becomes cumbersome in documents with many such words.

While the .hw variations can be wrapped in macros, this is still more effort than just having a mechanism to control how .hw words are interpreted by .hy, and also requires that the user maintain (at least) two versions of the .hw list.  Requiring redundancy in source code is how inconsistencies crop up.  This is the sort of task perfectly suited for an algorithm, and should not need manual intervention.

Dave <barx>
Group Member


(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 barx (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-04 barx Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code