Re: an observation and proposal about hyphenation codes

[Sigfrid Lundberg]

Dear Branden and all others,

I have strong feelings when it comes to multilinguality. A background: I
have a pre-retirement background in giving support to research in arts and
humanities. Occasionally I have had the opportunity to use groff for that.
The PDF catalogue of St Laurentius Digital Manuscript library is an example
of that. See

https://github.com/siglun/laurentius/blob/main/catalogue/catalogue.pdf

It is written in English, but contains implicits, explicits, rubrics etc in
perhaps a half dozen languages (.hy), each of which could benefit from its
own hyphenation mode (.hla). The Greek in this catalogue is medieval, not
modern

https://github.com/siglun/laurentius/blob/main/catalogue/Mh_54.pdf

which on its own was exercise. I'm not sure but I believe I used English
hyphenation throughout the  text, which is mostly in English, Latin and
Danish.

To me, Scientific type-setting and multilinguality is the raison d'etre for
groff and its competitors.

Yours,

Sigfrid

PS

I'm a groff user (groff@gnu.org subscriber) since 1989 when I failed to
install TeX on my workstation.




On Tue, 6 Aug 2024 at 22:28, Dave Kemper  wrote:

> On Tue, Aug 6, 2024 at 1:34 PM G. Branden Robinson
>  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.
>
>

-- 
Sigfrid Lundberg, Ph.D., System developer
Lund, Sweden
https://sigfrid-lundberg.se/ 

magazine style end marks

[lkh]

Hi all,

here's a problem I hope someone can help me with:

For a small fanzine project I want to typeset magazine
style end marks [1]. Particularly I want to include the
authors handle or name in the end mark, like seen for 
instance in some articles like in this issue of the
Space Gamer Magazine [2].

So in any case the end mark should be flush right. 
Either on the last line of the article, or - if that
line is to long to accomodate the end mark - on the 
following line.

In LaTeX I think I could get away with an \hfill, but 
from what I understand, flexible horizontal filling 
doesn't seem to be a concept in roff land (I might be
utterly wrong about this).

I've tried this:

.de Au
.ta \n((LLuR
.ad l
\[em] \fI\\$1\f
.ad b
..

It works, well, sometimes. When the authors name (given
as parameter $1) is to long, it seems to collide with
the right margin, so a newline is introduced. Also 
this construct fails in two column mode and of course
always moves the mark to the following line.

What would be a proper solution?

Thanks in advance!

lkh

[1]: 
https://rwt.io/typography-tips/marks-ends-and-middles-end-marks-sections-and-dead-ends

[2]: https://archive.org/details/SpaceGamer1981-12/page/n33/mode/2up