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

Closed
wants to merge 31 commits into 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?

Copy link
Member

Choose a reason for hiding this comment

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

It would not, I think, because the rules are adaptable, so if oyu have a special job that needs changes in that respect you can overwrite the rule. If it would be done internally your hand is forced.

But in the opposite direction this means that there is no point in adding such alternatives in situations where the extended shapes play no role, e.g., if ultra light is an existing series then we have a font like noto and then falling back to bx or b doesn't make much sense

Copy link
Contributor Author

@user227621 user227621 Dec 13, 2024

Choose a reason for hiding this comment

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

So you think it would be better to delete the entries of the form \DeclareFontSeriesChangeRule{...}{...}{bx}{b} (and \DeclareFontSeriesChangeRule{...}{...}{b}{bx}) altogether?

Copy link
Member

Choose a reason for hiding this comment

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

I have mixed feelings about the b / bx. I think it is probably helpful to have the rules that ask for bx fall back to b because the bxmight just come from a wrong \bfseriesdefault. Similar, if CM or LM fonts + some others are used, then the setting might have changed to band so fails with CM or LM. Thus, I think keeping those makes some sense. The situation is different if we are already in some series that is clearly outside the main ones, then they are much less useful, though they don't hurt.

@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.

@cfr42
Copy link
Contributor

cfr42 commented Oct 18, 2024

Ignore this comment. It's only here because I can't figure out how to watch a PR. (If this gets merged, I can probably remove some code from nfssext-cfr-nnfss.sty.)

@user227621
Copy link
Contributor Author

user227621 commented Oct 18, 2024

@cfr42 There is this button in the right-hand sidebar ;-):

temp

(If you're opening GitHub on a mobile device, it's at the bottom of the page.)

@cfr42
Copy link
Contributor

cfr42 commented Oct 18, 2024

@cfr42 There is this button in the right-hand sidebar ;-):

temp

Thanks! For some reason, I did not make that terminological connection, despite seeing the button. (I tried various other things, but not that one.)

@FrankMittelbach
Copy link
Member

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

sorry that got somewhat burried and it seems simpler by now if I'm marging manually myself rather than you trying to get the PR in shape, e.g., it would need to go to ltnews41 now and some other changes makes this not work cleanly (so this is what I'm currently doing).

However I have a couple of questions on your choices, some of which I don't understand. For example,

\DeclareFontSeriesChangeRule {l}{uc} {luc} {l}          %<-----
\DeclareFontSeriesChangeRule {l}{ec} {lec} {l}          %<-----
\DeclareFontSeriesChangeRule {l}{c}  {lc}  {l}            %<-----
\DeclareFontSeriesChangeRule {l}{sc} {lsc} {l}          %<-----
\DeclareFontSeriesChangeRule {l}{sx} {lsx} {l}          %<-----
\DeclareFontSeriesChangeRule {l}{x} {lx}   {l}           %<-----
\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}           %<-----

Why the fallback to l or b here? That is not done for any other weight (or if then only for a few). What is the rationale for not just leaving it {}?

I can see some sense in saying that some weights and widths are more likely to be implemented so if you come across something that isn't available then fall back to a more likely neighbor, but that would then need to be more generally done, not just for a single weight.

@user227621
Copy link
Contributor Author

These seven rules were already there before I changed anything (some of them marked with a question mark):

\DeclareFontSeriesChangeRule {l}{sb}{sb}  {b}   % ?         %<-----
\DeclareFontSeriesChangeRule {l}{b}{b}  {bx}                %<-----
\DeclareFontSeriesChangeRule {l}{ec}{lec}  {l}   % ?        %<-----
\DeclareFontSeriesChangeRule {l}{c}{lc}  {l}   % ?          %<-----
\DeclareFontSeriesChangeRule {l}{sc}{lsc}  {l}   % ?        %<-----
\DeclareFontSeriesChangeRule {l}{x}{lx}  {l}   % ?          %<-----
\DeclareFontSeriesChangeRule {l}{bx}{bx}  {b}               %<-----

So I thought that someone thought that this would be useful and I just added analogous rules for the other weights. I don't find these fallbacks useful either, so I will delete them.

@FrankMittelbach
Copy link
Member

So I thought that someone thought that this would be useful and I just added analogous rules for the other weights. I don't find these fallbacks useful either, so I will delete them.

I ust realized that they are partly in the old sources, so must have been my doing ...

But regardless of that, please do not spend further time on this PR (but leave it open). As I said I'm going to do the merging myself and have already moved most of it in a new branch at my end. Once that is done I'll ask you to review.

@user227621
Copy link
Contributor Author

Ok (just pushed two commits before I read your comment)

FrankMittelbach added a commit that referenced this pull request Dec 13, 2024
Copy link
Member

@FrankMittelbach FrankMittelbach left a comment

Choose a reason for hiding this comment

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

There are a few (minor) things that I would do differently, but due to the fact that we left the PR too long alone, it would be hard to merge now, as the corrections to make it work are numerous due to some changes in ltfssaxes.

I therefore decided to start a new branch essentially takingg the work here rather than trying to rebase.

This is #1583 and it is ready for checking.

FrankMittelbach added a commit that referenced this pull request Dec 17, 2024
* typo

* rollback tests and documentation for #1581

* correct docs after review

* ltfssaxes from #1396

* ltnews41 and changes

* align series change rule arguments

* more rule cleanup and start of rollback support

* Full support

* wording

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* more suggestions from review

* otf files do not end in .ttf :-)

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* WIP

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* more minor changes

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* Update base/ltfssaxes.dtx

Co-authored-by: user227621 <[email protected]>

* that fix got lost during merge

* Update base/ltfssaxes.dtx

Co-authored-by: user227621 <[email protected]>

* Update base/ltfssaxes.dtx

Co-authored-by: user227621 <[email protected]>

* corrections by Chris

* re-add a rule

* grumble

* and, of course, my typical typo

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

* some further minor changes

* regen and cleanup of the rollback data (we don't need to roll back anything that hasn't changed between 2024 and 2020)

* Apply suggestions from code review

Co-authored-by: user227621 <[email protected]>

---------

Co-authored-by: user227621 <[email protected]>
@user227621 user227621 deleted the declarefscr branch December 17, 2024 19:14
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.

4 participants