bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61734] [man] localize like other packages


From: G. Branden Robinson
Subject: [bug #61734] [man] localize like other packages
Date: Sat, 5 Feb 2022 12:30:30 -0500 (EST)

Follow-up Comment #5, bug #61734 (project groff):

I had noticed that the Swedish hyphenation mode was sticking to
our English pages after groff_mmse(7) in groff-man-pages.pdf.

This is proving to be quite the devil to deal with, thanks to
the large number of constraints imposed by batch rendering of
multiple pages (which may be in different languages), the
wrapping of the macro package itself by andoc.tmac (because man
pages can be written with different *roff macro packages),
the user-customizability of the hyphenation mode, and that
damned bit in the hyphenation mode that has ****-all to do with
the hyphenation patterns but instead is a knob for suppressing
hyphenation when a page location trap is about to spring.

I'm including a diff of me trying to solve the problem within
all of these constraints, and it works for our use case, but I
am not happy at all with the level of complexity it demands.

I propose instead to revise the semantics of the man(7) `HY`
macro and make it a Boolean.  Hyphenation on or off--if on, you
get what our macro files decide for you.  Does any user really
want to decide the details of the hyphenation mode themselves?

I have a pretty strong suspicion that all people use `HY` for in
the first place is mashing a big "SHUT HYPHENATION OFF" button
anyway (and that's what man-db _man_(1)'s --nh option already
does for the 99% who use `man` instead of `groff -man`).

(Or _mandoc_(1), but it doesn't affect the decision here because
as I understand it, it doesn't support automatic hyphenation and
Ingo doesn't plan to ever add it.)

If someone really wants to seize control of the hyphenation
mode, they're free to redefine the `hy` request in man.local.

I invite them to keep all the pieces.

Next steps:

I need to write a regression test to catch the case I observed
(the hyphenation in question was a ghastly "g-lyph").

Then implement `HY` boolification, and see how much less complex
that route really is.

The heart of this is probably, in `TH`, turning


.  hy \\n[HY]


into


.  if \\n[HY] .hy \\n[an*hyphenation-mode]


or maybe


.  ie \\n[HY] .hy \\n[an*hyphenation-mode]
.  el         .hy 0


To support recovery from rogue pages that sneakily turned it on.

Note for anyone reading hastily: the attached commit is *not*
pushed as of this writing.

(file #52808)
    _______________________________________________________

Additional Item Attachment:

File name: 61734-dubious.diff             Size:14 KB
    <https://file.savannah.gnu.org/file/61734-dubious.diff?file_id=52808>



    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]