bug-texinfo
[Top][All Lists]
Advanced

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

Re: rethinking @def*


From: Patrice Dumas
Subject: Re: rethinking @def*
Date: Wed, 10 Aug 2022 10:37:41 +0200

On Tue, Aug 09, 2022 at 11:24:44PM +0100, Gavin Smith wrote:
> On Wed, Aug 10, 2022 at 12:03:17AM +0200, Patrice Dumas wrote:
> > Hello,
> > 
> > With the changes to TeX output, assuming it is more or less final, I
> > checked the differences between LaTeX and TeX, the differences are
> > mainly attributable to the combinations or not of fonts (combination in
> > LaTeX, not in TeX).  In many cases, we do not really care, we simply
> > need to document that @r{@___{}} should be used.
> > 
> > There are two cases that are of interest, though, as they are likely to
> > be important in practice:
> > 
> > @var in @deftype* is slanted typewriter in LaTeX but slanted roman in
> > TeX.
> > 
> > @code (and @t) in @defn* is slanted typewriter in LaTeX but upright 
> > typewriter
> > in TeX.
> > 
> > What you we do for those two cases?  Try to change one or the other
> > formatting?  Document that the formatting can be different?
> 
> I think it would make sense to change LaTeX output to be like TeX output
> for these two points.  We could change @var from \textsl{...} to something
> like \textrm{\textsl{...}} or {\sl ...}.

Using \textrm doesn't work for code in @defn*, it does not make the font
upright, I guess, only roman.  The solution that matches better with TeX
is to use \textnormal{\textsl{...}} for @var + remove the code style to
get ligatures back, and \textnormal{\texttt{...}} for @code to remove
combination of fonts for those commands (or some similar constructs).  

Should be do that, which means never have combinations?  If we do that
for those commands, it would be logical to do it for other specific
indicatric @-commands, such as @option, @file, @env...?  Combinations
would only be possible within those commands, and for font commands such
as @slanted and similar.  That means that something like @var{@code{}}
or @code{@var{}} will always only apply the internal @-command
formatting.

> It's possible that there could be some inconsistency between the
> formatting of @var and @def* between output formats, as long as
> there is consistency within each format.

That's already the case, there is already consistency within each
format, the issue here is really consistency across formats.

-- 
Pat



reply via email to

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