Follow-up Comment #10, bug #57556 (group groff):

[comment #6 comment #6:]
> Design question: since a minimum hyphenation mode can be
> computed based upon this characteristic of the pattern
> files, should reading such a pattern file effectively set .hy?

I want to revise my comment #7 answer to this by zooming out.

From a design standpoint, a weakness of the current .hy mechanism is that it's
attempting to control two different things:
1. What hyphenation limitations are encoded into the active hyphenation
patterns
2. What hyphenation restrictions the document author wants
This tension is especially observable in a multilingual document: the values
of both 1 and 2 above might change over the course of the document, and not
necessarily in tandem.

A ground-up redesign would ideally address this by decoupling this .hy
overload.
1. Loading a new set of hyphenation patterns would automatically and invisibly
update the pattern-dependent hyphenation minimums that groff uses.  The
document author could discover but not alter these minimums.
2. A user-level request would let document authors specify their preferred
hyphenation restrictions.  Depending on the automatic setting of point 1,
groff might actually use more restrictive settings than this.  But hyphenation
could never be more lax than what the user specifies.

This would allow item 1 (pattern-based restrictions) to change over the course
of a multilingual document, but item 2 (author preference) to remain constant
throughout the document without additional author intervention.  It would
losslessly retain the user's preference, which would not necessarily be the
case if reading a new patterns file altered the user-preference register
directly.

So, in comment #7, when I answered yes to your design question, I was thinking
within the current hyphenation framework, where .hy is the only mechanism for
controlling hyphenation minimums.  But on further reflection, when reading a
hyphenation pattern file, groff should automatically enforce that file's
requirements independently of the user-settable .hy mechanism.


    _______________________________________________________

Reply to this item at:

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

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

Attachment: signature.asc
Description: PGP signature

Reply via email to