[Top][All Lists]

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

Re: A new ignoramus question about user-installed fonts

From: G. Branden Robinson
Subject: Re: A new ignoramus question about user-installed fonts
Date: Sat, 22 Apr 2023 16:28:29 -0500

Hi Oliver,

At 2023-04-21T20:13:14+0200, Oliver Corff wrote:
> thank you very much for your encouraging feedback.

I try to moonlight occasionally from my normal gig of gripes and
laments.  ;-)

> Indeed I did neither mention nor note in the example file (
> --- I thought the .ms in the file name tells the story)

I managed to overlook your input file name in your original mail.
Perhaps the pale green contact lenses obscured my vision...

> that I use groff_ms(7) as it is really at a sweet spot between
> simplicity of use and aesthetics of produced document.

I also think it delivers a lot of value from a fairly simple interface.

We've complicated it a bit lately with an eye toward better PDF
support, but if I can get a new feature or two into the formatter, I
think we'll be able to take a couple of those extensions back out and do
things "magically".

If I'm _really_ lucky (and correct about GNU troff's internal design),
then implementing the ideas above will permit the removal of the
`asciify` and `unformat` requests from the formatter as well.  (We would
of course keep them around as macros someplace for backward

> I remember I had used the .fam request before, at the very beginning
> of a document, which always produced the desired result: the *entire*
> document is typeset in the selected family.

It's not too unusual to use a different font family for headers and
footers.  (I haven't ever seen a different face used for
_footnotes_--just a change to a smaller type size--but since those are
maintained in a separate environment in ms(7), it was easy enough to
support such a distinction.)

The driver behind the groff 1.23.0 change, which makes the FAM string
more flexible, can be found in <>.

Long story short, one of Deri's documents brought a feature gap to my

> However, since this time I used .fam for the first time somewhere
> within the document, I first failed to understand that, in this case,
> its scope is limited to the current paragraph. This is a tentative
> statement from my side, I should really test which of the .LP, .PP,
> .SH, .NH etc.  requests will end the effect of the .fam request.

All of them (indirectly) call the internal macro `par@reset` (via
`par*start` or `par*finish`), so all of them will, I think.  Again, I
suggest using the FAM string instead, except for small-scale typographic

we're gonna have most of this sentence set in Times,
.fam P
but switch to Palatino right here because we're wack like that.
And then go back and pretend like nothing happened.
--end snip--

You will note that the `\F` escape sequence could have been used just as
well to achieve the above.  It's never been incorrect to break through
the floor to the formatter in ms(7)--but doing so requires the user to
understand the formatter and, perhaps, internals of the macro package.
That would fly in the Murray Hill CSRC but not with the Unix Support
Group.  Lesk didn't quite rouse himself to prohibiting _anything_.  The
mm(7) and me(7) manuals were a bit more strident about refusing to
support the arbitrary use of formatter features.

> After reading your mail, I tried again to start the whole document with
> the .fam Libertine request, et voilĂ , the whole document is typeset in
> the chosen font family.

I'm glad it worked out!  I do think

.ds FAM Libertine

...would be more robust, though.  :)

> Thank you very much for the hint regarding .fam,

And I wanted to compliment you on your document.  It is _exactly_ the
sort of thing I had in mind when I went to the (surprisingly
troublesome) effort of refactoring localization support to make English
and its hyphenation patterns merely a default as opposed to something
bolted more firmly into the system.

I had visions of people switching between multiple languages smoothly,
with appropriate hyphenation patterns being loaded and unloaded, and the
document author never having to do more than source the requisite
localization macro file.

There is still a feature gap; I still want a `hydefault` register.

Lacking it isn't fatal--we've gotten along all these years without
it.  But for limited domains like man pages--where localized pages are a
thing, but switching natural languages within a document is practically
unheard of--people do, despite our warnings, reach down to the udder of
the formatter and start grasping at appendages like `hy`, it could
prevent some problems that would be frustrating to debug.

And, to be frank, there were flaws in Ossanna's troff.  There were
multiple aspects of formatter state that should have been visible but,
originally, weren't.  The current adjustment and hyphenation modes are
two examples.  The `.j` register didn't show up until Kernighan's
rewrite, and it took groff to expose `.hy`.  A further problem was the
non-orthogonality of state restoration across requests.  The `ft`, `ps`,
and `in` requests, among several others, went back to the previous state
if given no arguments.  But `ad` didn't,[1] and `hy` without an argument
always selected hyphenation mode "1".  (Alignment and adjustment were
also unhelpfully conflated.)

Iconoclastically yours,


This is left-aligned text.
.ad c
This is centered text.
Now we're back to left-aligned.\|.\|.hey, wait!

Attachment: signature.asc
Description: PGP signature

reply via email to

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