bug-texinfo
[Top][All Lists]
Advanced

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

Re: in printed output, @deffn arguments should use a typewriter font lik


From: Gavin Smith
Subject: Re: in printed output, @deffn arguments should use a typewriter font like with @deftypefn
Date: Sat, 3 Sep 2022 21:53:31 +0100

On Sat, Sep 03, 2022 at 08:25:17PM +0200, Vincent Lefevre wrote:
> On 2022-09-02 17:42:33 +0100, Gavin Smith wrote:
> > On Fri, Sep 02, 2022 at 05:49:26PM +0200, Vincent Lefevre wrote:
> > > With texinfo.tex 2022-09-01.06, consider
> > > 
> > > @deffn Command name-min arg-min
> > > @end deffn
> > > 
> > > @deffn Command name-min @var{arg-min}
> > > @end deffn
> > > 
> > > In printed output (PDF), name-min is printed in typewriter font
> > > as expected, but arg-min is printed in slanted font instead of
> > > slanted typewriter font (whether @var is used or not).
> > 
> > There is nothing new here regarding the font style of the @deffn arguments -
> > they have always been in slanted variable-width roman style.  When @var is
> > used this used to switch to slanted typewriter in this context but this
> > made no sense - there's no reason why the two use cases should have
> > different formatting.
> 
> OK, I thought that @var was always using a slanted typewriter font.
> But then, this yields another inconsistency!

This is not the case.  In fact, @var has always used a slanted non-typewriter
font when not in a typewriter context, e.g. inside regular paragraph text.
In the future we plan to change @var to have this style everywhere.

You can get this early by specifying

@clear txicodevaristt

in your document.  This will give consistency between @deffn and
@deftypefn.

> 
> > > I think that this is incorrect, and slanted typewriter font should
> > > be used, as already done with @deftypefn.
> > 
> > It is not incorrect but a valid stylistic choice that is at least 40 years
> > old.  When in the past it was changed to slanted typewriter this led
> > to complaints that the slanted typewriter was not distinctive enough,
> > so it was changd back.
> > 
> > https://lists.gnu.org/archive/html/bug-texinfo/2003-11/msg00058.html
> 
> So, for consistency, why isn't this done for @deftypefn, then?

This has recently been discussed extensively on this list.

> > Which manual this is causing a problem for?
> 
> GNU MPFR.

I see that you use both @deffn and @deftypefn-like commands.  The changes
should be an improvement.  For example, in a definition like

size_t mpfr_get_str_ndigits (int b, mpfr_prec_t p) 

in the PDF currently on your website, the int and mpfr_prec_t types are
slanted, for no good reason.  With the new output, the types will be
in upright typewriter.  With

@clear txicodevaristt

you will additionally get consistent formatting for this and the definitions
without types like MPFR_DECL_INIT (name, prec).



reply via email to

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