Play nice with bm

[wspr]

The bm package is totally unsupported but I should think about aliasing \bm to \mathbf, probably.

[wspr]

Definitely not! But it's still unclear what to do here.

[davidcarlisle]

until more math fonts are available in two weights it's probably not worth doing a lot. The original intention was to be able to do \bm{\sum} or whatever although probably in practice it has been mostly used to get math bold italic \bm{a} so could make an option to make it an alias for \symwhatever to get \bm{a} and \bm{\alpha} to work. It may be better to do that in bm.sty though?

[callegar]

I may be missing something, but the problem that bm tries to solve does not appear easly solvable with the current unicode-math commands alone.

In some scientific fields you may have multi-letter quantity identifiers or identifiers with text-like subscripts, in some occasions with hats or accents (e.g. $\hat{\alpha_{\mathit{in}}}$). Furthermore, you may need both the regular identifier and its bold version. The ideal solution would be to store the basic symbol in a macro and have a command to embolden it as needed (so as to avoid defining things twice, also in order to avoid errors and inconsistencies). Doing the emboldening with bm is just a matter of doing $\bm{...}$ on that macro. With unicode-math, neither wrapping the macro in \symbf nor \mathbf achieves the same result. Either you break the letter spacing in the subscript (typeseting it as a product), or you do not get the hat in bold (not even a poor man bold), etc...

Even with a math font available in two weights (e.g., XITS, Lucida), you have issues, because the font cannot be switched inside math mode and you need to issue the \boldmath in an \mbox to escape to regular mode. However, this breaks the spacing of surrounding elements (e.g., the spacing of superscripts).

In my opinion, this is what makes the incompatibility with bm a big issue. Simple solutions like aliasing \bm to something that is currently provided in unicode-math does not seem to solve it... The best approaches would probably be either providing a fully inline way of switching to the bold companion of the math font (that is working while inside math mode) or having bm fixed to deal with unicode-math.

The main problem with bm seems to be related to things like $\bm{\alpha}$ that result in an Improper alphabetic constant.` error.

[davidcarlisle]

I did spend some time getting bm not to error with the extended mathchar settings, there are some experiments at

https://github.com/davidcarlisle/dpctex/tree/master/bm

But fundamentally the problem isn't solvable within TeX as the font support isn't there.

the basic mechanism for bm assumes that each math font has a matching bold font with the same encoding so bm just has to switch fonts while preserving the math class, and everything more or less works.

But I'm not aware of an opentype math font that comes with a matching bold. the OpenType math model is basically that you have a single font which has a (limited) set of bold characters in the math alphabet range. \symbf access the bold within the font, and the fact that it's more limited than \bm isn't really a problem with the macro but a reflection of the underlying font availability.

[callegar]

I think that both xits math and lucida math now have the bold variant.

I'll try with pleasure your experimental bm branch, I was not aware of its being also on github, thanks for the pointer.

[callegar]

On a side note, I wonder if in unicode-math it could be possible to make \symbf also work on prime signs and hats such as \hat, \tilde, etc. since these are part of the symbol on which they are applied and it looks strange to have a bold symbol with a non emboldened hat.

[davidcarlisle]

I think that both xits math and lucida math now have the bold variant.

It seems like its over a year since I looked at that I should try with xits..

On Sun, 16 Dec 2018 at 12:46, Sergio Callegari notifications@github.com wrote:

On a side note, I wonder if in unicode-math it could be possible to make \symbf also work on prime signs and hats such as \hat, \tilde, etc. since these are part of the symbol on which they are applied and it looks strange to have a bold symbol with a non emboldened hat.

bm could do that (if it worked) but really symbr can not, it is not a font change it just changes the character code to map to the fixed set of bold characters in the same font, and that has no accented characters, see the block here:

https://w3c.github.io/xml-entities/#alphabets

David

—

You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wspr/unicode-math/issues/108#issuecomment-447640599, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNcAizCOeUtKDNFJmu-wnFV8wleVkhzks5u5kCdgaJpZM4Fi4H4 .

[callegar]

I think I am making small steps in understanding. Sorry for my being slow, but my knowledge of how unicode math works is close to zero...

If I get it correctly, one of the two following things happens when I use unicode-math:

1) When I say \hat A, either an A-with-hat char is printed or an hat character is overlapped onto the A character

2) If I try to make it bold, unicode-math looks into the font to find the bold version of the characters. Unfortunately, it cannot find the bold hat or the bold A-with-hat chars. Hence, at best, I can end up with a bold A and a regular hat on top of it...

In other words, even if I do not use a math font with a bold companion font, still the math font contains bold versions of many of its chars, but not all of them (and specifically no bold accents, hats, prime signs, etc.). Is this the case?

However, If I have a font with a bold font companion, such as xits, unicode-math is said to be able to automatically find and load the bold companion, Thus, what I stll miss is why in this case, unicode-math does not provide a command (or alter \symbf) to automatically switch to that font.

If I get it correctly, because such command is missing, the only option to use the bold math font is to get out of math mode, escaping it temporarily with an \mbox, switch to that font with a \boldmath, re-enter math mode with a $ have the stuff that is to be typeset in bold, re-exit math mode with $, restore the regular math font with an \unboldmath, re-enter the math mode by closing the mbox, which has the unfortunate side effect of breaking all the spacing with the stuff surrounding he item in bold because of the mbox boundaries. This effect is exactly what bm works hard to fix...

Is this the case?

[callegar]

@davidcarlisle I have tried bmx.sty at your link, but it does not seem to work on my system. It does not error out in any way, but simply the bold math symbols do not get printed at all. For instance, bmu2.tex does not work for case 5: the bold \alpha is not printed at all.

[davidcarlisle]

more or less right except that for symbbf it doesn't really need to look in to the font, that mapping os specified by Unicode so for a math font the bold (and fraktur and double struck) etc characters are specified by unicode the range of characters in each math alphabet in unicode is fairly arbitrary, some don't have digits, some don't have Greek etc, however it is what it is.

If you have a second font that is bold then bm would work once it is extended to understand the Umathchardef that's what the bmx was doing but I never really finished it as at the time I didn't have a bold opentype math font and Will was adding the \symbf mechanism to unicode math.

I should look again at the current state, But anyway it's really a bm issue (so you could raise it there) rather than unicode-math (I think)

David

On Sun, 16 Dec 2018 at 13:36, Sergio Callegari notifications@github.com wrote:

I think I am making small steps in understanding. Sorry for my being slow, but my knowledge of how unicode math works is close to zero...

If I get it correctly, one of the two following things happens when I use unicode-math:

1.

When I say \hat A, either an A-with-hat char is printed or an hat character is overlapped onto the A character 2.

If I try to make it bold, unicode-math looks into the font to find the bold version of the characters. Unfortunately, it cannot find the bold hat or the bold A-with-hat chars. Hence, at best, I can end up with a bold A and a regular hat on top of it...

In other words, even if I do not use a math font with a bold companion font, still the math font contains bold versions of many of its chars, but not all of them (and specifically no bold accents, hats, prime signs, etc.). Is this the case?

However, If I have a font with a bold font companion, such as xits, unicode-math is said to be able to automatically find and load the bold companion, Thus, what I stll miss is why in this case, unicode-math does not provide a command (or alter \symbf) to automatically switch to that font.

If I get it correctly, because such command is missing, the only option to use the bold math font is to get out of math mode, escaping it temporarily with an \mbox, switch to that font with a \boldmath, re-enter math mode with a $ have the stuff that is to be typeset in bold, re-exit math mode with $, restore the regular math font with an \unboldmath, re-enter the math mode by closing the mbox, which has the unfortunate side effect of breaking all the spacing with the stuff surrounding he item in bold because of the mbox boundaries. This effect is exactly what bm works hard to fix...

Is this the case?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/wspr/unicode-math/issues/108#issuecomment-447644011, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNcAk407NQUoD94I9J-YU07Y9fTed3sks5u5kxkgaJpZM4Fi4H4 .

[callegar]

Thanks for the latest explanations.

I am now trying to split my reports properly between the unicode-math and the bm tracker.

The fact that the bmu2.tex example does not work seems to be a bmx problem, so I'm posting it there.

I am keeping here as new reports some issues with the \mathxx and \symxx commands that appear to me either as inconsistencies or as behaviors that make their usage harder than one would expect.