Re: A new ignoramus question about user-installed fonts

[John Gardner]

Hi Oliver,


> message by GhostScript: Can't embed the complete font DFSongStd as it is
> too large, embedding a subset
>

PostScript provides a dedicated resource-type for exactly this: a CID-keyed
font (PLRM § 5.11
<https://web.archive.org/web/20190125033754id_/https://www.adobe.com/content/dam/acom/en/devnet/actionscript/articles/PLRM.pdf#G10.1513844>).
The specifics of it are beyond this discussion, but it stands to reason
that a CID-font should be used for subsetting a CJK font. This might be
beyond gropdf(1)'s current capabilities, though.


> монгол үлгэр.


Now do *real* Mongolian[1]

$ groff > /tmp/timur.pdf -Tpdf <<EOF
> ᠮᠣᠩᠭᠣᠯ ᠪᠢᠴᠢᠭ
>
EOF


On Sun, 23 Apr 2023 at 07:28, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> 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 (multitest.ms
> > --- 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".
>
> https://savannah.gnu.org/bugs/?62264
> https://savannah.gnu.org/bugs/?62787
> https://savannah.gnu.org/bugs/?63074
>
> 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
> compatibility.)
>
> > 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 <https://savannah.gnu.org/bugs/?60422>.
>
> Long story short, one of Deri's documents brought a feature gap to my
> attention!
>
> > 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
> stunts.
>
> --snip--
> Like,
> 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.
> .fam
> .
> 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.
>
> https://savannah.gnu.org/bugs/?63635
>
> 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,
> Branden
>
> [1]
>
> This is left-aligned text.
> .br
> .ad c
> This is centered text.
> .br
> .ad
> Now we're back to left-aligned.\|.\|.hey, wait!
>