Sender: |
|
Date: |
Mon, 22 Mar 2021 18:27:53 +0100 |
Reply-To: |
|
Message-ID: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=utf-8; format=flowed |
From: |
|
Parts/Attachments: |
|
|
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
|
|
|