-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
feat: Support bold Fraktur #3777
Conversation
The second commit makes this PR more general in addressing the complaint of issue #3776. The results of function |
Codecov Report
@@ Coverage Diff @@
## main #3777 +/- ##
=======================================
Coverage 92.98% 92.99%
=======================================
Files 91 91
Lines 6773 6779 +6
Branches 1575 1576 +1
=======================================
+ Hits 6298 6304 +6
Misses 437 437
Partials 38 38
Continue to review full report in Codecov by Sentry.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the long delay in review here. Slowly getting back into things...
Overall, this seems like a good fix to bold Fraktur, so this PR should be probably be merged. However, I noticed one thing more generally about Fraktur support:
I just tested and \text{𝔄-ℨ}
generates an error, because \u212D
(Z), \u210C
(H), and \u2128
(Z) are macro'd in src/macros.js
to use \mathfrak
but sometimes we want \textfrak
. (Not sure why this doesn't generate an error when building the documentation. Perhaps it does and it's being silently ignored.)
Perhaps this is legacy code and can simply be removed?
Lines 256 to 258 in 5dd9bc4
defineMacro("\u212D", "\\mathfrak{C}"); // Fraktur | |
defineMacro("\u210C", "\\mathfrak{H}"); | |
defineMacro("\u2128", "\\mathfrak{Z}"); |
P.S. I also looked into generating actual metrics for the bold Fraktur font. (Part of the delay.) My attempts failed, though, so I think this should go as is; we can consider adding them later if I figure out how metrics get built. |
const [wideFontName, wideFontClass] = text.charCodeAt(0) !== 0xD835 | ||
? ["", ""] | ||
: wideCharacterFont(text, mode); | ||
if (wideFontName.length > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to avoid the array creation in the negative case. How about this:
let wideFontName, wideFontClass;
if (text.charCodeAt(0) === 0xD835) {
[wideFontName, wideFontClass] = wideCharacterFont(text, mode);
}
if (wideFontName) {
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it.
@ronkok Do you agree with this assessment? If so, I can remove the code and make the other requested change. |
I don't think that is correct. Most Fractur characters are outside the Unicode Basic Multilingual Plane (BMP). They are addressed by the wide character function modified in this PR. But a few Fractur characters are in the BMP. KaTeX defines them in these macros. Lines 247 to 258 in ad03d1e
I suppose I could have instead defined them in I think a Lines 815 to 817 in ad03d1e
Then the BMP definitions would overwrite the first definition. |
## [0.16.9](v0.16.8...v0.16.9) (2023-10-02) ### Features * Support bold Fraktur ([#3777](#3777)) ([240d5ae](240d5ae))
🎉 This PR is included in version 0.16.9 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Support bold Fraktur. Resolves #3776.
Note: KaTeX has a font for bold Fraktur, but no font metrics. That is why I left bold Fraktur out of the original PR for wide-character Unicode support. In this PR, I evade the lack of metrics by using the font metrics for regular Fraktur, not bold Fraktur.