[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).