LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 22 Mar 2021 18:27:53 +0100
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Message-ID:
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
8bit
In-Reply-To:
Content-Type:
text/plain; charset=utf-8; format=flowed
From:
Frank Mittelbach <[log in to unmask]>
Parts/Attachments:
text/plain (54 lines)
Hi Don,

long time no see

> fontdef.dtx defines the various series, family and style defaults
> using \newcommand, e.g.
> 
> \newcommand\itdefault{it} \newcommand\sldefault{sl} 
> \newcommand\scdefault{sc} \newcommand\updefault{up}
> 
> This gives defines them as \long However, the commands \fontfamily,
> \fontseries and \fontshape define \f@family, \f@series and \f@shape
> using \edef which maked the resulting values not \long

a bit inconsistent I agree, but as Joseph said "like this forever" and 
also like this in other places, so even if fontdef would change you 
couldn't rely on it not being made long
> 
> This means that code that would do something like, e.g.,
> \ifx\f@shape\itdefaultā€¦\fi will not work as expected.

yes, but that is not a reliable test anyway.

\def\familydefault{cmr}
\def\familydefault{\rmdefault}

point to the same family as a default but your test would pick them up 
as different regardless.

The only reliable test is something like

\edef\next{\itdefault}
\ifx\f@shape\next ...

and that is how NFSS always treats them internally.

> The simplest fix would be to use the starred form of \newcommand for
> setting the various \XXdefault values. I would imagine that this
> should not break anything

I'm sure from experience that your imagination is faulty :-) it will 
break something as any change does, but beside that it will not resolve 
the problem. There are many classes and packages which use \renewcommand 
on them and so may the user in the preamble, so even if we would change 
(after 30 years) it isn't really going to help, you need to expand the 
value prior to testing it against \f@...  (which are ensured to be *not* 
long).

So I agree with Joseph (albeit for a slightly different reason), a 
feature not a bug.

cheers
frank

ATOM RSS1 RSS2