[bug #59814] [PATCH] improve internationalization at startup

[Dave]

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

[comment #4 comment #4:]
> This, I'm dubious about.  It would make it impossible to switch languages
> mid-document and get appropriate hyphenation for the other language(s).

A fair point.  This code was really just a stopgap anyway until the root of
bug #57556 (reading the relevant lefthyphenmin and righthyphenmin from the
pattern files) can be addressed.

___

Reply to this item at:

  

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

[bug #59814] [PATCH] improve internationalization at startup

[G. Branden Robinson]

Follow-up Comment #4, bug #59814 (project groff):


[comment #2 comment #2:]
> As suggested in _bug #53413 comment #13
_, the new tmac/en.tmac could
also call ".hy 4", as the English patterns require.

I've done this.

> tmac/en.tmac could go one step further and incorporate the patch attached to
bug #57556.  (The patch as submitted adds the code to tmac/troffrc, but that's
no longer the right place under the current bug's new framework.)  The code in
this patch sets an initial .hy value and then redefines the .hy request to
prevent the user from later calling it with a value incompatible with the
English patterns.

This, I'm dubious about.  It would make it impossible to switch languages
mid-document and get appropriate hyphenation for the other language(s).

___

Reply to this item at:

  

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

[bug #59814] [PATCH] improve internationalization at startup

[G. Branden Robinson]

Follow-up Comment #3, bug #59814 (project groff):

Updated version.


commit db993c17e02b3924eca88d112c3f0342f1ce7a5d (HEAD -> language-en)
Author: G. Branden Robinson 
Date:   Fri Jan 15 03:38:11 2021 +1100

[docs]: Update hyphenation and localization stuff.

commit ea58825c604ab677c55fab4476bc6f0b8abfc777
Author: G. Branden Robinson 
Date:   Fri Jan 15 03:27:15 2021 +1100

tmac/en.tmac: Set hyphenation mode to 4.

commit a704c76b9b909b832f37a47933dae664c5f2e76a
Author: G. Branden Robinson 
Date:   Mon Jan 4 17:53:05 2021 +1100

tmac/troffrc: Derive groff locale from system.

Determine the groff locale (default input language) using the system
locale.  Use the environment if possible.  Try LC_ALL first, then LANG.
"C" means English (en).  Otherwise, only the first two characters of the
locale name are used.

Unrecognized locales (those without a supporting xx.tmac file) are
ignored, and groff falls back to English.

Those who want groff's default locale to differ from LC_ALL/LANG should
edit this troffrc to source the appropriate groff locale macro file
(cs.tmac, de.tmac, den.tmac, fr.tmac, ja.tmac, sv.tmac, zh.tmac).

commit 55af800b24976861e76cd1f7bee640d50f790ebd
Author: G. Branden Robinson 
Date:   Mon Jan 4 17:44:57 2021 +1100

tmac/en.tmac: Add English localization file.

commit ad9f00c55d122a8fe44c576798f1aa0abb17e545
Author: G. Branden Robinson 
Date:   Mon Jan 4 17:10:20 2021 +1100

[troffrc]: Change hyphenation language us to en.

The first-order determinant of hyphenation points is language, not
territory.  Use ISO 639 2-letter language codes for hyphenation and
exception patterns instead of ISO 3166 2-letter territory codes.

commit 7e4a5de02eebc36fb1b590b9d24aaf5d5d8eecaf
Author: G. Branden Robinson 
Date:   Mon Jan 4 16:59:03 2021 +1100

tmac: Rename *.us to *.en.

The first-order determinant of hyphenation points is language, not
territory.  Use ISO 639 2-letter language codes for hyphenation and
exception patterns instead of ISO 3166 2-letter territory codes.


(file #50722)
___

Additional Item Attachment:

File name: groff-i18n-2.diff  Size:13 KB




___

Reply to this item at:

  

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

[bug #59608] sample_docs.mom: error: an argument has a 'p' unit attached

[Peter Schaffter]

Follow-up Comment #2, bug #59608 (project groff):

> .DOC_COVER_TITLE_STYLE \
>   SIZE +8 \
>   SMALLCAPS \
>   UNDERLINE 1 3p  < line 86

This is correct.  The first arg (weight) should not have a unit of measure
attached; the second (distance from baseline) should.

Using the latest om.tmac from the repo and my most recent groff build
(1.22.4.7-72b4), there is no error.  What's more, the error clearly refers to
the second arg, but RULE_WEIGHT only takes one arg.  Whatever the problem is,
I can't see how it's coming from om.tmac.

Altering the RULE_WEIGHT error msg to say the it comes from RULE_WEIGHT might
be useful for developer debugging, but would be useless to a user, who needs
only know the name and location of the calling macro since that is where any
invalid argument would have been entered.

___

Reply to this item at:

  

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

[bug #57594] sync groff hyphenation-pattern files with upstream TeX versions

[G. Branden Robinson]

Update of bug #57594 (project groff):

Severity:  3 - Normal => 5 - Blocker

___

Follow-up Comment #3:

If this should go into the release checklist then we should add it there, in
FOR-RELEASE.

We should also write script(s) to verify the groff-cleanliness of the
hyphenation files.  This can easily take the form of one or more regression
tests like the 48 others we have.  The most obvious thing I can think of to do
is to have one test file for each supported groff locale which then calls .hla
(or uses my in-development internationalization patch, bug #59814).  If my
understanding is correct, an otherwise empty groff document will suffice to
provoke diagnostics from .hla if the hyphenation or exception files contain
unsupported constructs.  See src/roff/troff/env.cpp:hyphen_trie::hpf_getc and
src/roff/troff/env.cpp:hyphen_trie::read_patterns_file.

Once both of these are done, this ticket can be resolved.

In the meantime, it's a blocker.

___

Reply to this item at:

  

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

[bug #59382] [PATCH] various documentation files, cosmetic cleanup

[G. Branden Robinson]

Update of bug #59382 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #1:


commit 005406f0d15e763c0d325c2779bc6b455c14e78b
Author: Dave Kemper 
Date:   Fri Oct 30 00:45:32 2020 +

[docs]: Make cosmetic cleanups.

* NEWS:
* contrib/groff_filenames/groff_filenames.5.man:
* src/devices/grops/grops.1.man:
* src/preproc/preconv/preconv.1.man
* tmac/groff_man.7.man.in: Update with mostly trivial punctuation fixes,
  tightening of the wording, and standardizing of idioms.

Fixes .


___

Reply to this item at:

  

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

[bug #59835] [PATCH] add support for strsignal

[G. Branden Robinson]

Update of bug #59835 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #1:


commit e59589a4cb7c2b5fafad36ddecf12dda92cc5b33
Author: G. Branden Robinson 
Date:   Sun Jan 10 19:18:25 2021 +1100

src/roff/groff/pipeline.c: Use strsignal().

POSIX.1-2008 added strsignal() to the C library and recommended its use
over sys_siglist[], but groff's pipeline management hadn't been updated
in that respect since that time.

* configure.ac: Check for strsignal().
* src/roff/groff/pipeline.c (xstrsignal): Use return value of
  strsignal() if it is available.

Thanks to an anonymous contributor for the report and the patch.

Fixes .


___

Reply to this item at:

  

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

[bug #59381] [PATCH] tmac/groff_me.7.man: stale URL

[G. Branden Robinson]

Update of bug #59381 (project groff):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #1:


commit 6b016ce6f5a58933ab0acb31af86047712c4a8dc
Author: Dave Kemper 
Date:   Fri Oct 30 00:08:41 2020 +

groff_me(7): Fix bad URL in comment.

Two years ago, commit ef25e6a7 added a quote to tmac/groff_me.7.man
sourced to the URL
https://minnie.tuhs.org//pipermail/tuhs/2018-November/015412.html.  Even
with the extraneous / removed, this URL today returns a 404; the correct
URL now is
https://minnie.tuhs.org/pipermail/tuhs/2018-November/017033.html.

This could mean one of two things:

The URL was mispasted into the groff_me.7.man source
The URL has changed since 2018

The former seems far less likely, but is also the preferable
explanation, because the latter tells us that URLs to that archive are
not guaranteed to be stable (ironic, for a site archiving discussion
about preserving electronic history), and the interface does not appear
to offer a permalink.

Fixes .


___

Reply to this item at:

  

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

[bug #59608] sample_docs.mom: error: an argument has a 'p' unit attached

[Dave]

Update of bug #59608 (project groff):

 Summary: sample_docs.mom: new error: an argument has a 'p'
unit attached => sample_docs.mom: error: an argument has a 'p' unit attached

___

Follow-up Comment #1:

[comment #0 original submission:]
> .DOC_COVER_TITLE_STYLE \
>   SIZE +8 \
>   SMALLCAPS \
>   UNDERLINE 1 3p  < line 86

My reading of http://www.schaffter.ca/mom/momdoc/docelement.html#underline is
that UNDERLINE's first (numeric) parameter ("weight") should have no unit, and
its second ("distance") must have one.  So the quoted syntax appears to be
correct.

>   First notice of this was 29th November.
> 
>   Last time without error was 24th November.

Hmm, nothing under contrib/mom changed during that time frame; in fact, the
last change anywhere in that tree was commit c05b538c
 on November
11.

So your compiler change during that time may be the root culprit.

>   Removing the 'p ' silences the warning.

Perhaps so, but that's unlikely to be the correct fix: the "p" has been there
since 2015 and only raised an error starting recently; and a unit should be
required there, per the docs.

___

Reply to this item at:

  

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

[bug #58897] [PATCH] ellipses need kerning too

[G. Branden Robinson]

Update of bug #58897 (project groff):

  Status:None => Fixed  
 Assigned to:None => gbranden   
 Open/Closed:Open => Closed 
 Planned Release:None => 1.23.0 

___

Follow-up Comment #3:


commit 81b4ffadc1ced740ecb4e1eceff7dd0f3423c176 (HEAD -> master,
origin/master, origin/HEAD)
Author: Dave Kemper 
Date:   Wed Aug 5 04:51:54 2020 +

font/devps/*: Kern horizontal ellipsis correctly.

Commit 87edb525, from 2003, added character U+2026 (HORIZONTAL ELLIPSIS)
to most base groff fonts, but there has been no kerning information for
this character.  To produce consistent typography, it should be kerned
the same way as the period, which is in 818 kern pairs across all the
devps fonts.

Apply the following shell command to the groff description files
of the PostScript fonts.

  for file in font/devps/*[A-Z]
do sed -Ei\~ 's/(.*)(^| )\. (.*)/&\n\1\2u2026 \3/' $file
  done

* font/devps/AB:
* font/devps/ABI:
* font/devps/AI:
* font/devps/AR:
* font/devps/BMB:
* font/devps/BMBI:
* font/devps/BMI:
* font/devps/BMR:
* font/devps/HB:
* font/devps/HBI:
* font/devps/HI:
* font/devps/HNB:
* font/devps/HNBI:
* font/devps/HNI:
* font/devps/HNR:
* font/devps/HR:
* font/devps/NB:
* font/devps/NBI:
* font/devps/NI:
* font/devps/NR:
* font/devps/PB:
* font/devps/PBI:
* font/devps/PI:
* font/devps/PR:
* font/devps/TB:
* font/devps/TBI:
* font/devps/TI:
* font/devps/TR:
* font/devps/ZCMI: Apply above script.

Fixes .  However, this will need
to be done again if afmtodit is used to regenerate the above files, or
afmtodit will need to be modified to add this kerning information
itself.


___

Reply to this item at:

  

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

[bug #57556] Enforce left and right minimums as required by hyphenation patterns

[Dave]

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

[comment #3 comment #3:]
> Of particular note is the observation that groff has several
language-specific setup files but lacks one for English

This disparity is addressed as part of the proposed change in bug #59814. 
Under the new 59814 framework, the code in the patch attached to comment #3
would more properly belong in the new tmac/en.tmac.

___

Reply to this item at:

  

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

[bug #59814] [PATCH] improve internationalization at startup

[Dave]

Follow-up Comment #2, bug #59814 (project groff):

As suggested in _bug #53413 comment #13
_, the new tmac/en.tmac could
also call ".hy 4", as the English patterns require.

tmac/en.tmac could go one step further and incorporate the patch attached to
bug #57556.  (The patch as submitted adds the code to tmac/troffrc, but that's
no longer the right place under the current bug's new framework.)  The code in
this patch sets an initial .hy value and then redefines the .hy request to
prevent the user from later calling it with a value incompatible with the
English patterns.

___

Reply to this item at:

  

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

[bug #59676] [PATCH] grog/subs.pl: Don't use "exists" on array values

[Dave]

Follow-up Comment #2, bug #59676 (project groff):

[comment #0 original submission:]
>   This is a correction of patch #59664, 3th item.

This presumably intends to refer to bug #59664, as the cited patch link is a
404.

___

Reply to this item at:

  

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

[bug #53413] [PATCH] Add hyphenation patterns to use with US and hy=48

[Dave]

Follow-up Comment #15, bug #53413 (project groff):

Is there anything further to be done for this bug?  There seems to be no
support for incorporating the patch in the initial submission, and all the
ancillary issues brought up have been spun off into their own reports.



[comment #13 comment #13:]
> I reckon I would add '.hy 4' to my proposed new en.tmac file in #59814.

That seems best given the design proposed in that bug.

> I think we should have English localization per se done in a separate
> file.  Its concerns are distinguishable from those in the rest of troffrc.

Eh, well, they are as of when the 59814 patch is applied.  Before that, one of
troffrc's concerns was loading English hyphenation patterns.

___

Reply to this item at:

  

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