LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Don Hosek <[log in to unmask]>
Mon, 22 Mar 2021 13:43:54 -0500
text/plain (46 lines)
After some digging it looks like Frank’s approach is the only way to manage this (it would be nice if utility macros for this already existed but I guess that ship has sailed). I am surprised that nobody suggested \str_if_eq:eeTF which does just want I need (after a bit of a sad moment when it appeared not to work because I inadvertently used the nn form instead of the ee form).

-dh

> On 22 Mar 2021, at 12:27, Frank Mittelbach <[log in to unmask]> wrote:
> 
> 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