@Nasser -- Your example is not what breqn usually gets to look at, since it really has only two segments, and the only possible places to break are on the two sides of the equal sign. But it's been too many years since I looked at the details. Some others here are more up to date.
I think the problem is that CAS systems that generate these Latex results do not think about such issues. The above RHS could have be written in Latex as 1/B*(A) instead of A/B. the first form can be broken by breqn but not the second form.
@Nasser -- Your example is not what breqn usually gets to look at, since it really has only two segments, and the only possible places to break are on the two sides of the equal sign. But it's been too many years since I looked at the details. Some others here are more up to date.
@Nasser no it's user error, you can't expect the CAS system to do more if you ask for an expression that size. I would not use breqn, I'd just use inline math and define \frac to make a/b
The hardest part is getting rid of the spurious {} groups, without that you would just need simple inline definitions as in
Suggestion for automatic alignment of large equations
Use $\z ... \zstop $ not begin{equation}...\end{equation} otherwise the math is unchanged.
\documentclass[a4paper]...
If I load the unicode-math package, $\char"1D465$ prints an italic x, but $\char"1D499$ does not print an italic bold x (but just a bold upright one). Why is that? Same for $\char"1D639$ (prints sans upright) and $\char"1D66D$ (prints sans bold upright). (Compilation with LuaLaTeX.)
Outside math mode (and with a font selected that supports these glyphs) it works. It is probably not the intended way to select these letters anyways ...
@DavidCarlisle I think choosing normal font would be right if the glyph from the actual code point U+1D499 would be used, since this character isn't technically italic, or more like: it is always italic, regardless of the current style. But here, it seems, the normal x (U+0078) is used, which of course should then by styled italic. I don't know what glyph#1488 is exactly, but $^^^^^^01d431$ and $^^^^^^01d499$ use \TU/latinmodern-math.otf(1)/m/n/10 glyph#1488 which can't be right.
@DavidCarlisle Yes this was the output from XeLaTeX. Sorry, I switched to test this as well. LuaLaTeX says that it uses 𝐱 in both cases (and normal font:\TU/latinmodern-math.otf(1)/m/n/10 𝐱). Which should also be considered wrong.
So in short: When compiling your code, LuaLaTeX shows in the log \TU/latinmodern-math.otf(1)/m/n/10 𝒙 for the first and \TU/latinmodern-math.otf(1)/m/n/10 𝐱 for the other letters. XeLaTeX shows \TU/latinmodern-math.otf(1)/m/n/10 glyph#1673 for the first and \TU/latinmodern-math.otf(1)/m/n/10 glyph#1488 for the others. Expected output would be, that the first, third and fourth letter yield the same output.
@UlrikeFischer Oh, I see! So, this is actually a feature. I find it still strange that without this option it changes the glyph in this case as you state which glyph to use in the most explicit way. But ... okay. It's probably a good choice considering the different use cases.
@UlrikeFischer I can understand an option to change the mapping for the base characters so x goes to upright or italic x, but maping a bold italic math x to a bold upright math x is basically wrong, I'd say/
@DavidCarlisle this math-style questions comes up once in a while e.g. tex.stackexchange.com/a/659270/2388 and so I know that it affects letters but I never really tried to figure out if the default make sense, I simply change booleans until it fits ...
@DavidCarlisle yes it looks odd. But as you mention the documentation: there is also a bold-style option and it documents the behaviour \usepackage[bold-style=literal]{unicode-math} would keep it.
@UlrikeFischer The discussion you link to seems not to refer to glyphs from the Mathematical Alphanumeric Symbols block. I would say, it is fine that the package changes the shape/style of letters or digits that are not in this block. But since this block is somehow made for explicitly typing, say, an italic bold serif x, I think that the package should not interfere here. But this is just my opinion.
@UlrikeFischer I can't see any way of reading the doc to say it would make a bold italic x come out as bold upright, the discussion of the styles talks about the way an ascii x is mapped
Upright and italic bold mathematical letters input as direct Unicode characters
are normalised with the same rules. For example, with bold-style=TeX, a
literal bold italic latin character will be typeset upright.
@UlrikeFischer ug, I should have stuck with my first answer, I have no time to look today. Anyway it's wrong, documenting it doesn't really make it right.
Say you'd decide to stick to some style, but then you really need to input a sans bold upright E. Now, you chose, for example math-style=ISO, you can't just type in 𝖤 (U+1D5A4), because this would still result in an italic letter. Should I file an issue to GitHub? (But it is actually rather a choice than a bug ...)
@JasperHabicht looks like you have to use \symliteral{...} to stop it messing up the input: The \symliteral{⟨syms⟩} command can also be used, regardless of package setting, to force the style to match the literal input characters.
@DavidCarlisle Hm, yes the doc says this, but: \documentclass{article} \usepackage[math-style=ISO]{unicode-math} \begin{document} $\char"1D5A4 \symliteral{\char"1D5A4}$ \end{document} prints the same glyph twice. So, this is clearly wrong (or I am again not understanding the package ...)
I'll test more and also read the doc, but I still feel that things are not quite right here ...
@DavidCarlisle -- Maybe there's some lingering attention to the fact that \mathbf{x} is upright and one needs \mathbfit{x} to get both boldface and italic.
@DavidCarlisle -- Oh, it's definitely true that the Unicode assignments should be unambiguous. But there has been confusion in the past over the naming.
@barbarabeeton As far as I understand, the different code points in the block Mathematical Alphanumeric Symbols are also meant to be semantically different (because Unicode would not codify them separately otherwise). So, it is not only a matter of style. And obviously this "normalization" of the package replaces one code point with another.
@JasperHabicht -- I can vouch for the Unicode intention. And in fact there are some gaps in the math alphanumerics, for a few letters or digits that are cited in other standards documents for specific purposes. This fact has been called to the attention of the UTC, but I don't know where they are in doing something about it.
@barbarabeeton But these "missing" characters are mostly in the block "Letterlike Symbols", I think. And these are still meant to be "styled" because there meaning requires this. At least as far as I know ... What might pose problematic, however, is the fact that the code block "Mathematical Alphanumeric Symbols" does not contain upright serif non-bold letters. So, it would still need some way to switch to "regular uprigh" for certain styles. I totally understand this.
@JasperHabicht -- I think this is covered in the Unicode Tech Report #25 (but I don't have time to check right now). I'm pretty sure that there's an explicit statement that this should use the ordinary text font. (The Letterlike Symbols list isn't "complete".)
@yo' -- Actually, I prefer thin-crust pizza, and one of my favorites has just cheese, thin slices of fresh tomato, and a pesto wash. For that, I'll forgo anchovies.
@yo' -- Anchovies are truly a matter of personal preference. I grew up near water, and with that comes an exposure to fish, shellfish, and other creatures that dwell in oceans, rivers and bays. In that environment, it's not hard to learn to like those things, unless one is allergic. Fortunately, I'm not.
@barbarabeeton As my wife Veronika puts it, it seems I only like fish that don't smell like fish :)
In a Japanese-French fusion in Paris, we had seabass as the "main course", and other fish and seafood I think, and it all was marvelous. However, it was all super-fresh (I believe pulled only in the morning for the dinner. Other than that, from stuff that swims, I only enjoy basically salmon, but that in almost all its forms. And I love tuna, but I get it very very rarely given how problematic tuna fishing is.
@yo' -- Well, there are some such. I'll have to share my recipe for fish chowder; it uses white fish and gets much of its flavor from other seasonings. And it comes from an "illustrious" source -- the daughter of the skipper of the "Atlantis", the old research sailing vessel of the Woods Hole Oceanographic Institute (WHOI), and was one of the easy, tasty meals prepared onboard.
@yo' -- Oh, I could happily survive on sushi! But agreed -- it must be very fresh.
@FaheemMitha \def\foo{abc} then \foo is the macro and abc is its replacement text. then xyz \foo xyz works by replacing \foo inline by abc it is not a function call that stacks the environment, evaluates \foo and returns
@FaheemMitha yes but as I say it is not available and you should not expect it in a macro expansion. say it was called \name\def\foo{ab\name c} the replacement text is not evaluated on definition. so xyz \foo first thing that happens is \foo expands to its replacement xyz ab\name c then finally \name will be seen by tex, but \foo has long gone. it as if xyz ab\name c was at the top level
\ddanger Now that we have seen a number of examples, let's look at the
precise rules that govern \TeX\ macros. Definitions have the general form
\begindisplay
|\def|\<control sequence>\<parameter text>|{|\<replacement text>|}|
\enddisplay
Hi! I was wondering if there was an expl3 interface to public kernel functions like \IfClassLoadedTF. Something like \sys_if_class_loaded:nTF and the other conditional variations. I thought about writing is as a wrap around \IfClassLoadedTF but that seems ... backwards
@FaheemMitha I'll try to explain differently. Imagine you do \def\xyz{A\myname B} that should give AxyzB when expanded. Then do \let\abc=\xyz. Now you expect \abc` give AxyzB as it should be indistinguishable from \xyz, but you also expect it to give AabcB because that's what \myname does. This is impossible within the TeX paradigm.
@AlanMunn mine is a version (no onions) of a classical Sicilian one: rgtti.com/IHC/ihc05/msg00043.html (it's in Italian, but now we have ChatGPT... ;-P) (but mine is better, no previous boiling of cauliflower)
@Ulrike I'm writing a package which I intend to \use in several different classes. Its behavior will depend on the class. If I want to say "do this if the document class is article, report, or book, but not beamer", using \IfClassLoadedTF{}{}, that's a lot of braces and repeated code. So I thought I could do it better as a boolean expression
@DavidCarlisle I normally agree with you. I'm using the titlesec package to reformat section titles. So test for a control sequence \section, right? But beamer also has a \section command...