-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Unexpected behaviour of \fontseries #444
Comments
Workaround (for now) would be to swap |
Try this (not guaranteed to be right):
|
@FrankMittelbach I just noticed that By the way: the current version of |
I guess you are "technically" right, although chances that it actually fails are rather slim compared to the series situation as the available fontshapes are fairly uniform. But yes, that merging should be delayed in exactly the same way. Thanks for noticing. |
true, this is due to us starting to use l3doc for the sources, but a lot of the documented code is in old ltxdoc style. So we end up with that warning whenever there is no |
@FrankMittelbach I'd noticed something similar when preparing my PR: I think we should agree on an approach to whether to use |
@aminophen do you see a dependency to your code there? |
@josephwright I opened a separate issue for the documentation woes (#445) |
@FrankMittelbach Yes I will adjust platex code after yours is settled. |
@FrankMittelbach And, you will have to report to everysel package author, as it redefines \selectfont |
good point, but that is unmaintained bascially, ok that then would need to be handeled by firstaid for the moment |
@FrankMittelbach Hmm CJK package also does ... |
looks like the hook provided by everysel should be offered by the kernel and then used by tracefnt, CJK and everysel changed to just use the hook instead of installing it and changing the other packages. |
@FrankMittelbach if everysel should be changed there should be no need to use firstaid, we can either take it or arrange that someone makes an update. |
@u-fischer if we don't delay the fix to the next release there is a need for firstaid for at least CJK and so we can then do it for everysel as well and it can then be updated later (which makes things much simpler). But I'm guess it is probably better to just schedule the change for the spring release. The problem is not so severe that one couldn't justify delaying the fix especially as a work around is available. |
@FrankMittelbach Agreed, it would be great if the kernel incorporates everysel functionality. FYI, platex redefines \selectfont broadly, to enable changing all of Japanese-yoko, Japanese-tate and Latin fonts at the same time. Note that https://github.com/texjporg/platex/blob/master/plcore.ltx#L584-L638 https://github.com/texjporg/platex/blob/master/ptrace.sty#L22-L78 |
Am 02.12.20 um 13:31 schrieb Hironobu Yamashita:
FYI, platex refines \selectfont broadly, to enable changing all of
Japanese-yoko, Japanese-tate and Latin fonts at the same time. Note that
***@***.***| should be at /last/, because we need to adjust base line
shift amount between Japanese and Latin fonts here /after/ font size is
updated.
Currently everysel installs its hook after \font@name and before. From a
quick look at your redefinition that is probably not enough to allow you
to adjust things without replacing the command.
So where else would you need a hook? At the start of the command?
|
@FrankMittelbach I just noticed the following: There is a command |
I don't think hook mechanism is useful here; there is no way to remove the existing |
I think it is correct. The high-level font command |
@FrankMittelbach One also has to keep in mind that series and shape are interdependent. If both the series handling and the shape handling are delayed one has to make sure that they are somehow evaluated together. If e. g. the series is always handled first and the combination "requested series"/"current shape" does not exist (but "requested series"/"requested shape" does) you get an unwanted substitution. |
The proposed changes work fine in themselves, but some commands which use (For the following examples, I have collected the changes in a file called
) Issue 1
"Lorem ipsum" is Issue 2
Without the delayed font selection handling, all four "Lorem ipsum" are cmr/m/n. Issue 3
In the example, Noto Sans is set as sans serif (
fails, because the "forced" state applies to
works, because It is probably possible to cause a similar problem with Remark
Can that be done more systematically? For (I'm sorry, this comment has become very long.) |
Perhaps too many commands assume that Hence another proposal... The idea is the following: It is not necessary to delay the
This proposal should fix some, but not all, problems. The following scenario will not work well: If the series is changed directly via So, issues 1 and 2 I mentioned in my previous comment are partly fixed (substitutions maybe not ideal). To fully fix them, Issue 3 is kind of a separate problem and not fixed by this proposal. |
Is there any reason, why package |
got it |
Hi stale-bot :-) Is there any news on this issue? The implementation currently used in latex-dev still seems to have some problems (see this comment and this comment above). I'm not sure if it's a good idea to use this implementation in the final release. |
@user227621 Don't worry about the bot: it just nudges on issues that didn't have recent activity. It doesn't mean that the issue is forgotten (on the contrary). Frank already labelled this as a bug and set a milestone to fix this for the May release, so if things go according to plan it will be fixed by then. |
I consider this a non-issue. I think it is acceptable that
That is indeed plain wrong:
again a mistake, I agree. the force should always be reset by but in your examples you switch to "sb" and then claim that this is recognized as being a bold context. It isn't and never was unless you change the Noto font to have a bfdefault of sb. What is recognized is the bfdefault of the current meta family and the overall bfdefault in other words "bx" or "b" |
I'm a bit reluctant to make a change like that, that means you sometimes get delays and sometimes not and that even on the documentlevel commands such as \fontseries or \fontseriesforced etc, so my plan is to just fix issues 2 and 3 above (as they are clearly bugs but otherwise leave the implementation as it is now. |
Yes, I agree.
But in my example, I did just that:
When On this occasion I discovered another inconsistency in the 2020/10/01 implementation that has now been fixed by delaying the series handling: If there is a Consider the following example (compile with LaTeX 2020/10/01):
The second "Lorem ipsum" is |
so you did. Not sure why I didn't copied that over when I made my own example file with all three issues. |
* add support for row headers * Declare variable * update testfiles (braces) * handle negative row header values * add testfiles * extend documentation * add multirow code * remove stray plug * guard variant, update testfiles * multirow testfile * handle missing fields for multirow * issue #432 * add changes, update date * update luatex testfiles * handle issue #444 * correct test, default structure * version update and changes entry for lttagging * provide sockets if they do not exist * start ltnews entry * corrections from review * s + commas
Brief outline of the bug
Since LaTeX 2020-02-02 the
\fontseries
command does not work properly in specific situations when called before\fontfamily
.Consider the following example:
You get:
"Lorem ipsum" should be light, but you get the regular weight. Apparently, a substitution mechanism starts before
\selectfont
is called: LaTeX tries OT1/cmr/l/n (which doesn't exist), substitutes OT1/cmr/m/n, and finally you get OT1/NotoSans-TLF/m/n.With LaTeX 2019-10-01 (
\RequirePackage[2019/10/01]{latexrelease}
) everything works as expected.The problem seems to affect only font series values for which a pre-defined
\DeclareFontSeriesChangeRule
exists (see this answer on StackExchange): If you ask for\fontseries{c}
or\fontseries{sb}
, you getm
orb
. If you ask forul
,el
orub
, you get the requested font series.The same problem occurs with other fonts.
(First reported on StackExchange. In that discussion, the problem was not really identified as a bug but I thought it might be worth reporting it here because the problem affects compatibility.)
Minimal example showing the bug
Log file (required) and possibly PDF file
The text was updated successfully, but these errors were encountered: