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.robin...@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! >
