bug-groff
[Top][All Lists]
Advanced

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

[bug #64155] specifying -fZD on command line generates warnings


From: G. Branden Robinson
Subject: [bug #64155] specifying -fZD on command line generates warnings
Date: Thu, 2 May 2024 18:17:05 -0400 (EDT)

Follow-up Comment #27, bug #64155 (group groff):

Hi Peter,

[comment #26 comment #26:]
> I guess I wasn't clear enough when I advised not implementing .fam checking
as proposed by Branden,

Please be reassured that this wasn't a matter of proceeding over your protest
(5 March 2024); the commit had already been in place on the master branch
since 10 July 2023.
 
> as I have just discovered the change has been committed, with the expected
consequence: partial families in my library that have only R and I fonts choke
on .fam.
> 
>   printf ".fam Technical\n.ft R" | groff -z 
>   troff:<standard input>:1: error: 'Technical' is not a valid font family
> 
> This is a regression.

This example invalidates one of the premises I put forward in comment #22
("given that mom has her own system of managing fonts, and part of her
contract with the user, as I understand it, is that [the] user will not go
behind her back and start invoking *roff requests") and regarding which I
solicited your input.

It may also invalidate some language I put into our Texinfo manual.


   The default family used with abstract styles is initially 'T'.
Typically, abstract styles are arranged in the first four mounting
positions in the order shown above.  The default mounting position, and
therefore style, is always '1' ('R').  By issuing appropriate formatter
instructions, you can override these defaults before your document
writes its first glyph.


...namely, the final sentence.

Please confirm my understanding of the foregoing and I will proceed with the
reversion right away.

> Please revert the commit that introduced it,
> 39ffa368dc6a1de4c11cf3f4f5b8594d3c974173.  I don't see any need for .fam
checking in the first place, but that discussion should be left for after the
commit is reverted.

Well, when you're prepared to discuss it, it would be good to know if/how
Dave's original report in comment #0 was invalid.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64155>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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