Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add numerous \DeclareFontSeriesChangeRule entries #1396

Open
wants to merge 29 commits into
base: develop
Choose a base branch
from

Conversation

user227621
Copy link
Contributor

@user227621 user227621 commented Jul 1, 2024

LaTeX is currently missing some \DeclareFontSeriesChangeRule entries. Consider the following example:

\documentclass{article}

\begin{document}

\fontfamily{NotoSans-TLF}\selectfont

\fontseries{lsc}\selectfont This is light semicondensed.

\fontseries{b}\selectfont This should be bold semicondensed. %but you get bold regular

\end{document}

Furthermore, it is documented that not all widths are yet supported:

%    Also: while I did set up all nine standard weight values from
%    \texttt{ul} to \texttt{ub} I only bothered to provide entries for
%    \texttt{ec},  \texttt{sc}, \texttt{c} and \texttt{x}, because other levels of
%    compression/expansion are not in any real fonts that I know.
%
%    Could and perhaps should be eventually extended to cover the
%    whole set.

This PR adds rules so that the full range of weights (from ul to ub) and widths (from uc to ux) is covered. The entries are sorted first by weight (from ul to ub) and then by width (from uc to ux). (Perhaps this gives a little structure to the long list of entries.)

Internal housekeeping

Status of pull request

  • Ready to merge
  • rollback needed?
  • test files needed?

Checklist of required changes before merge will be approved

  • Test file(s) added
  • Version and date string updated in changed source files
  • Relevant \changes entries in source included
  • Relevant changes.txt updated
  • Rollback provided (if necessary)?
  • ltnewsX.tex (and/or latexchanges.tex) updated

The rules are now sorted by weight (from 'ul' to 'ub') and width (from 'uc' to 'ux')
The rules are now sorted by weight (from 'ul' to 'ub') and width (from 'uc' to 'ux')
The rules are now sorted in the same way as the 'm?'/'?m' rules
Rules are unnecessary because requested series and target series are identical
…f weights (from 'ul' to 'ub') and widths (from 'uc' to 'ux') is covered
…imilar rules also have an alternative target series)
These 'l' rules seem reasonable and are similar to the 'b' rules
Requested series and target series are identical. If this series does not exist, the normal substitution mechanism will substitute \seriesdeafult, which is usually m (and if it's not m, then it was probably changed for a good reason). So no need for these rules.
similar to previous commit
@FrankMittelbach
Copy link
Member

I'm going to look at this once you say it is ready, but not before returning from Prague, ie not before August. Fixing the conflict is probably not sensible right now as it will conflict again during the next weeks.

@FrankMittelbach
Copy link
Member

And it should get a (draft) entry in ltnews40, at least a placeholder so that it is not forgotten, thanks.

% in the end (324 entries) but on the other hand it doesn't change and
% With 9 weight values (from \texttt{ul} to \texttt{ub}) and 9 width values
% (from \texttt{uc} to \texttt{ux}), this table is getting a bit large in
% the end (1345 entries), but on the other hand it doesn't change and
% accessing speed and it is fast this way.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An incomplete sentence: "but on the other hand it doesn't change and accessing speed and it is fast this way." What was that originally supposed to mean?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@user227621

I assume the intended meaning is along the lines of this, which might be clearer?

this table is now rather large (1345 entries), but on the other hand, the table doesn't change and accessing rules is fast using a table implemented in this way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have rephrased the sentence accordingly.

@@ -35,7 +35,7 @@
%
%
\ProvidesFile{ltfssaxes.dtx}
[2024/02/08 v1.0i LaTeX Kernel (NFSS Axes handing)]
[2024/07/01 v1.0j LaTeX Kernel (NFSS Axes handing)]
% \iffalse
\documentclass{ltxdoc}
\begin{document}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another incomplete sentence (a few lines further down, seems I can't comment there): "This file contains the implementation for handling extra axes splitting the series and the values into sub-categories. selection commands." What was that originally supposed to mean?

\DeclareFontSeriesChangeRule {l}{ex}{lex} {l} % ? %<-----
\DeclareFontSeriesChangeRule {l}{ux}{lux} {l} % ? %<-----
\DeclareFontSeriesChangeRule {l}{sb}{sb} {b} % ? %<-----
\DeclareFontSeriesChangeRule {l}{b}{b} {bx} %<-----
\DeclareFontSeriesChangeRule {l}{bx}{bx} {b} %<-----
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a number of entries of the form \DeclareFontSeriesChangeRule{...}{...}{bx}{b}. I suspect that they exist because for the Computer Modern fonts 'bold' is bx and not b, so that you have a reasonable substitution when bx is applied to another font. Wouldn't it be better if this was handled in a general way, e.g., in \merge@font@series@, instead of handling this case (incompletely) via random \DeclareFontSeriesChangeRule entries?

@user227621
Copy link
Contributor Author

@FrankMittelbach I've added an entry in ltnews40. Minor open questions in the comments above, otherwise this PR is ready for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants