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

document the recommended way to do bold math with opentype fonts? #974

Open
kberry opened this issue Dec 23, 2022 · 2 comments
Open

document the recommended way to do bold math with opentype fonts? #974

kberry opened this issue Dec 23, 2022 · 2 comments
Assignees
Labels
long-term issues (or enhancements) that will not be resolved any time soon but should be considered eventually

Comments

@kberry
Copy link

kberry commented Dec 23, 2022

What is the recommended way to do bold math with opentype fonts?
Apparently it is not the bm package, since it results in "Extended mathchar used as mathchar" with pretty much any input, so far as I can tell.
(E.g., $e^{i \pi} + 1 = 0$)

But, since bm is pervasively said to be the "preferred" way to get bold math, I suggest adding a note at the top of its documentation saying 1) bm s not the answer for opentype math, and 2) referring to wherever the answer actually is.

Which I suppose is unicode-math, but looking at its documentation (and lots of tex.sx questions), I am hard-pressed to discern how to simply get normal math expressions typeset in bold. The best I can guess is:

\usepackage[mathrm=sym,mathbf=sym]{unicode-math}

although what it actually means to have "\mathbf behave as if it were \symbf en masse" (page 10 of unicode-math.pdf) is far from clear to me. I.e., what results in bold and what doesn't after doing this.

And what is the relationship to \boldmath and \boldsymbol? Apparently \boldmath, at least, still works with both TeX and OpenType math (I think), and is thus apparently the most portable-across-engines way to say "typeset my math in bold", even though it is not recommended. So maybe it should not be not-recommended.

(This is all for the Lucida documentation, BTW.) --thanks, karl.

@davidcarlisle
Copy link
Member

There is some code on github towards making bm work with luatex, but not released as there are some issues...

In general (even for classic tex) if you want the whole expression bold, it's better to use \boldmath outside the math. However most OpenType math fonts don't have a bold font (and a functional \boldmath is a pre-requisite for bm). If you are happy with using font-level fake bold (FakeBold=1 in fontspec ) then a bold math version can be set up, and \boldmath (and \bm) can work pretty much as in classic TeX.

However for most uses it is probably better to use \symbf or \symbfit which is not a font change but rather a character shift to the unicode math alphabets. The downside is these only work for the characters specified by Unicode, so for bold math italic, that is Latin and Greek letters, but not digit or symbols, see https://w3c.github.io/xml-entities/bold-italic.html

We have some (as yet unimplemented) plans for some higher level "just do the right thing" command that would work in pdflatex and lua/xelatex, but the arbitrary nature of the Unicode math alphabets, and the general unavailability of bold math fonts, make deciding what a sensible documentable interface should do something of a challenge...

@kberry
Copy link
Author

kberry commented Dec 23, 2022

Thanks David. I totally understand the challenge :).

My only practical(?) suggestions are 1) to put a note at the top of the bm package documentation saying "don't use this with opentype math", and 2) don't describe \boldmath as deprecated, legacy, or other such terms, since, I gather, for opentype it remains the thing to use if a true bold math fontexists , or fake bold is satisfactory. (Lucida is one of the few that has a separate bold math font.)

Thanks for your human-comprehensible explanation of \symbf and \symbfit. It deserves to be in the unicode-math documentation. What's there now is so hedged with qualifiers, special cases, maybe this/maybe that, that I could not figure out what they actually did.

BTW, this is another topic, but I (strongly) suggest that it is time for "the LaTeX team" to take over fontspec and unicode-math. CTAN lists Will and Khaled as maintainers, but in practice, so far as I know, neither of them has time to actively maintain them any more. The issues pile up ...

Thanks again.

@davidcarlisle davidcarlisle self-assigned this Apr 2, 2023
@davidcarlisle davidcarlisle added the long-term issues (or enhancements) that will not be resolved any time soon but should be considered eventually label Apr 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long-term issues (or enhancements) that will not be resolved any time soon but should be considered eventually
Projects
None yet
Development

No branches or pull requests

2 participants