4

If you don't care why I'm asking, skip the first section ....


Problem:

  1. No small-caps italic shape was defined in LaTeX 2e.
  2. \textsc{\textit{small-caps italic}} did not produce small-caps italic even if a small-caps italic shape was defined.

Earlier solution: different packages used different shape codes for small-caps italic and/or small-caps oblique. Variations included (at least) si, scit and scsl. Some support packages also supported layered changes of shape so that \textsc{\textit{small-caps italic} small-caps} \textit{italic \textsc{small-caps}} behaved as hoped.

To make this easier, some font-support-package-support packages offered the authors of font-support packages general frameworks which defined the shapes and hacked LaTeX's commands so layered shape changes worked.font-axes, nfssext and nfssext-cfr are examples.

Newer solution: LaTeX defines scit and supports layering of italic, small-caps and oblique shapes.

Problem: If you maintain (in some degenerate sense of 'maintain') a font-support package which used si and scsl, say, either shape changes for your supported fonts will break or shape changes for fonts supported by the default configuration will break.

Solution: Redo the .fd files to use scit and drop package-specific support, relying on the standard framework.

Problem: If you maintain (in some even more degenerate sense of 'maintain') a font-support-package-support package offering a general framework for font-support packages which supports si and scsl, say, and you drop the code supporting those shapes, then you may break font-support packages over which you have no control and whose existence you may be oblivious to. If you don't drop the code, you will break support for fonts which rely on the new standard framework, which may coexist in documents with fonts which require the old one.

Ideal solution: Using your time machine, go back and use scit for italic small-caps. Then you can point to your documentation and claim you always told people to use scit and it isn't your fault si and/or scsl don't work.

Problem: Funding for time machine not available.

Less ideal solution: Adapt your font-support-package-support package to support si, scit and scsl.


In revising nfssext-cfr, I would like to test for four target shapes when dealing with layered small-caps/italic/oblique changes of shape. I suspect the only way to do this is going to look similar to what nfssext did originally, but I'm not sure how to make sure that plays nicely with the current LaTeX framework.

For example, the most straightforward way to implement the support for small-caps italic (si) and oblique (scsl) would be

\DeclareFontShapeChangeRule {it}{sc}{si}{scsl}
\DeclareFontShapeChangeRule{sl}{sc}{scsl}{si}
\DeclareFontShapeChangeRule {sc}{it} {si} {scsl}
\DeclareFontShapeChangeRule {sc}{sl} {scsl} {si}

But if I do that, I will break shape changes for fonts which use scit rather than si and/or scsl.

So, in the absence of a time machine, I'd ideally have something like

\DeclareFontShapeChangeRule {it}{sc}{si}{scsl}{scit}
\DeclareFontShapeChangeRule{sl}{sc}{scsl}{si}{scit}
\DeclareFontShapeChangeRule {sc}{it} {si} {scsl}{scit}
\DeclareFontShapeChangeRule {sc}{sl} {scsl} {si}{scit}

but, unfortunately, such a command does not exist. \DeclareFontShapeChangeRule can test for three shape targets, but four are beyond its power.

I have tried the time-honoured method of ignoring the problem for a few years, letting the partially-revised code ferment and hoping I'd have a bright idea, but my brain has so far failed to catch even a dimly lit one.

Here's an MNWE (with translated comments!):

\documentclass{article}
\usepackage[T1]{fontenc}
\makeatletter
\renewcommand \rmdefault {clm}
\renewcommand \sfdefault {cmr}
\newcommand*{\sidefault}{si}% anniffiniedig
% better to test si & then scit but I don't know how to do that with the new stuff ...
\DeclareRobustCommand{\sishape}{%
  \not@math@alphabet\sishape\relax
  \fontshape\sidefault\selectfont}
% it would be better to try si, scit and scsl, but that doesn't seem possible
% the need for overwriting could be avoided by changing the .fd files, but that would break code I don't know about ...
\DeclareFontShapeChangeRule {it}{sc}{si}{scsl}% current; request (& third); first choice; second choice
\DeclareFontShapeChangeRule{sl}{sc}{scsl}{si}
\DeclareFontShapeChangeRule {sc}{it} {si} {scsl}
\DeclareFontShapeChangeRule {sc}{sl} {scsl} {si}
% the following are unproblematic because they don't interfere with anything
\DeclareFontShapeChangeRule {si}{it} {si} {}
\DeclareFontShapeChangeRule {si}{sl} {scsl} {si}
\DeclareFontShapeChangeRule {scsl}{sl} {scsl} {}
\DeclareFontShapeChangeRule {scsl}{it} {si} {scsl}
\DeclareFontShapeChangeRule {si}{sc} {si} {}
\DeclareFontShapeChangeRule {si}{ulc} {it} {}
\DeclareFontShapeChangeRule {si}{up} {sc} {}
% avoid spurious warnings for the example
\DeclareFontShapeChangeRule {n}{up}{n}{}
\DeclareFontShapeChangeRule {sc}{up}{n}{}
\DeclareFontShapeChangeRule {it}{up}{n}{}
% \def\DeclareFontShapeChangeRule #1#2#3#4{% latex.ltx
%   \@namedef{shape@#1@#2}{{#3}{#4}}}
% \DeclareFontShapeChangeRule abcd % \shape@a@b -> {c}{d}
\makeatother
\begin{document}
\texttt{clm}:

\rmfamily\sishape Italic Small-Caps 

\upshape Small-Caps 

\itshape Italic Small-Caps 

\normalfont Upright standard 

\itshape\scshape Italic Small-Caps 

\normalfont \slshape\scshape Slanted Small-Caps -> Italic 

\texttt{cmr}:

\sffamily\sishape Italic Small-Caps 

\upshape Small-Caps 

\itshape Italic Small-Caps 

\normalfont Upright standard 

\itshape\scshape Italic Small-Caps 

\normalfont \slshape\scshape Slanted Small-Caps -> Italic 
\end{document}

11
  • Well LaTeX contains a rule \DeclareFontShapeChangeRule {it}{sc} {scit} {scsl} and I don't think that a package author should change that: you would affect all other font packages too. I would try to get rid of si. Generally when we change code that can affect packages we grep over tex in texlive and try to check how the code is used and if a change really affects packages and if yes contact authors. Apr 23 at 9:00
  • can't you set up using the new standard names and then use a traditional substitution declaration so that shape si gets substritued by scit ? Apr 23 at 9:22
  • it's 2e or in fact latex-base Not latex3 Apr 23 at 9:22
  • @DavidCarlisle For fonts I maintain, yes. At least, I think so. But for anybody else using the code, I'll break it. The problem isn't really for fonts I maintain. If that were the problem, I'd have done something already. The problem is nfssext-cfr was not documented as font-specific. If was designed to work for any fonts which use Karl's naming scheme. The small-caps stuff isn't even mine: it's there in nfssext already to get e.g. \itshape\scshape working. I don't think there are other packages in TL, but I think people are (were) using nfssext-cfr for non-CTAN fonts.
    – cfr
    Apr 23 at 14:27
  • @UlrikeFischer I'm trying to break less, but, yes, I realise that breaks other fonts.
    – cfr
    Apr 23 at 14:34

2 Answers 2

3

What's wrong with changing the .fd file of the font in question (if you maintain it) and add the scit shape and then aliasing the si shape to that shape (just like many fonts alias bxto b). After that old document that explicitly use si should continue to work as before but new documents could just write \textsc{\itshape ...} and it would work too.

Mixing both conventions wouldn't necessarily work and produce substitutions, but I think that is acceptable.

I would not produce change rules because as Ulrike pointed out that would mean that your document breaks other font packages in strange ways. The change rules are only for preamble if you need to adjust a specific document or for general setup which normally only happens as part of the kernel.

4
  • For fonts I maintain, sure. But I don't know who else might be relying on the generic package. And \textsc{\itshape ...} worked already with nfssext. Whatever I do at this point is going to be non-ideal. I thought using the change rules would be cleaner and a bit more transparent, but if I'm not meant to use those at all I'll try to think of something else. If the previous set up had required users to use \textsi{} rather than supporting \scshape\itshape etc., it would be different. But breaking that now for any font which used si ... that I really don't want to do.
    – cfr
    Apr 23 at 14:18
  • @cfr isn't supporting \scshape\itshape the easy part now (as it works by default) the harder part is supporting people explicitly using the si font shape, which needs some kind of substitution set up. Apr 23 at 14:54
  • @DavidCarlisle OK. Now I see what you meant. Sorry, I'm very slow. I wasn't thinking of people doing that but only e.g. \sishape. Yes, a substitution would be good there, though I'm a bit less concerned about breaking something non-documented. But as I understand Frank, I'm not meant to set Rules at all - only the kernel or the user is meant to do that. But then I have to redefine \scshape etc. to get things to work, just as nfssext did. (I also have the m and sw problems, but the former is currently so broken I at least can't make things worse.)
    – cfr
    Apr 24 at 1:43
  • What's the scope of the no-Rules guidance? @DavidCarlisle suggested pinging you here or opening an issue, but it's not a bug. It isn't a feature request either. How should I handle merging non-standard shapes etc.? I basically have frameworks for merging (1) shapes, (2) weights, (3) widths and (4) families. The kernel now has a framework for at (1), (2) and (3) - but hopefully not (4). If I can't use the kernel's, I don't know how to make them play nicely.
    – cfr
    Apr 24 at 8:38
2

Can't you update the fd files to use the new standardised shape names, then

do

\documentclass{article}


\usepackage[T1]{fontenc}
\DeclareFontShapeChangeRule {n}{si} {scit}      {scsl}
\begin{document}

{\scshape Abc \textit{Abc}} {\fontshape{si}\selectfont Abc}

\end{document}

enter image description here

so any document accessing composites such as \scshape\textit{Abc} will access the italic small caps via the new mechanism. The added ShapeChange rule will only affect code that is explicitly requesting the si shape so will not affect any documents not previously using that.

You will need a few more rules for handling the case where the existing shape isn't n but....

12
  • Do I need this? For the font packages I maintain, I'm setting up either scit or scsl. And I handle the si substitution in the .fds. Won't that work? So I can avoid the Rules I'm not meant to use. But then I still have to redefine \scshape and \itshape to handle cases where the kernel doesn't provide any rules. I hoped to get rid of that stuff from nfssext.
    – cfr
    Apr 24 at 1:32
  • @cfr that would work yes I posted this alternative as you said you wanted something that worked for all fonts not just fd files you control. I think adding rules for a shape only used by your packages is OK and better than the suggestion in the question of adding rules for the standard shapes Apr 24 at 6:35
  • @cfr if there are reasonable rules for standard shapes missing from the format, you could make a feature request issue to add them Apr 24 at 6:37
  • But they're obviously not for standard shapes or the format would already have rules for them. I'm not trying to be difficult, but it's hard to see how to merge things like ui, ri and ol with sc without misusing the new framework. And, yes, of course, nfssext always broke the old rules, too, since I guess you weren't 'supposed' to redefine \itshape or \scshape etc. But maybe that's better?
    – cfr
    Apr 24 at 7:23
  • 1
    @cfr ah ok so there's two separate issues, one is the name for italic small caps changed from si to scit and the other is you just have more shapes. As I say I think adding rules for "your" shapes is OK (and doesn't have the issues associated for changing the rules of standard shapes, but itd Frank's code don't trust me, ping him under his question and ask for comments (or open an issue at github) Apr 24 at 7:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .