On Tue, Aug 6, 2024 at 1:34 PM G. Branden Robinson <g.branden.robin...@gmail.com> wrote: > At 2024-08-06T12:08:29-0500, Dave Kemper wrote: > > This is the only line in your test file output before any .hcode > > requests were run, so this shows the default hyphenation for the > > system. > > Well, kind of. The hyphenation language (`.hla`) and hyphenation mode > (`.hy`) are the same for these two scenarios.
Yes, sloppy wording on my part. By "default hyphenation" I meant no aspect of it was changed by the input file. Command-line switches of course had an effect. > Therefore these characters did not acquire nonzero hyphenation codes, > and therefore were not valid hyphenation breakpoints. > > Does this make sense? Yes. It makes me wonder about the wisdom of commit 0629380a9's move of the .hcode blocks. That is, I understand the reasoning for it you and Werner put forth, that the underlying groff design didn't contemplate a single run needing different languages' hyphenation support. But tying an initial hyphenation scheme to a language seems to at least tie it to the right thing at the outset, whereas tying it to an encoding perhaps doesn't. > If so, what I will do is make "en.tmac" `.mso latin1.tmac`. That will solve the problem for English. Are there other language files that will need it? Will some language files need other tmac/latin*.tmac sourced? Those are questions beyond my monolingual knowledge.