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


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

Submitted by:  Dave <barx>
Submitted on:  Fri 04 May 2018 07:44:27 PM UTC  
Category:  Core Severity:  3 - Normal
Item Group:  New feature Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open 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 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>
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>


(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)

    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.




    No changes have been made to this item

    Back to the top

    Powered by Savane 3.5