Whenever I load the packages breqn and icomma into the same document, the document fails to compile. The order of the packages makes no difference. MWE:

Look mama, no hands!

raises the following cryptic error:

This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2017-04-15>
Babel <3.18> and hyphenation patterns for 84 language(s) loaded.
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
.      [lines omitted for brevity]
(/usr/share/texlive/texmf-dist/tex/latex/was/icomma.sty) (./test.aux)
! Bad mathchar (32768).
<to be read again> 
l.4 \begin{document}


but compiles if either of the packages are commented out.

I could not find anyone else with this problem. Does anyone know of a workaround, or if not, who should this bug be reported to (I've never reported a bug to a package manager before)?

  • 1
    There are three very basic rules about breqn: (1) Don't use it. (2) Don't use it. (3) Don't use it. ;-)
    – user121799
    Apr 8 '19 at 18:30
  • As you might have guessed, I was using icomma before I tried using breqn, and after removing icomma for this specific document, I found that breqn also requires restructuring every single occurence of a_\text{x} in that document – so I probably won't be using it after all, easier to manually set line breaks... Apr 8 '19 at 18:37
  • 1
    It is best to change a_\text{x} in any case. the fact that the braces can be omitted is an accident of the implementation and is not documented markup, also it should usually be \mathrm not \text, so a_{\mathrm{x}} Apr 8 '19 at 19:11
  • 1
    I wasn't aware that the omission of braces was bad practice, I guess I need to break that habit. It just looks clearer and less cluttered to me, that's how I got there in the first place. Concerning text vs. mathrm: That actually is intentional, since mathrm looks wrong if the remainder of the document is in sans-serif font, e.g. in beamer. text also seems to be semantically correct for subscripts such as "mixed" or "radial" or whatever it might be, no? Apr 9 '19 at 14:10

Basically, breqn makes many characters math active, in order to achieve its goals. Also icomma wants to make the comma math active, assigning it a different definition and this obviously can't work, at least in environments governed by breqn.

You may make the icomma version useable in standard math environments, but I see no real way to sneak it inside dmath or similar environments, where you have to resort to the standard {,} trick.



  \ifx\@let@token\@sptoken \else
  \ifx\@let@token\space \else
    \mathord\fi\fi \breqn@comma}


Look mama, no hands!

$(a, b)=1,2$



enter image description here

The same output with siunitx and \num.




Look mama, no hands!




But follow marmot's advice: don't use breqn if you don't have huge and unreadable formulas generated by some external piece of software that you have no time to break manually.

  • siunitx seems to be the semantically most correct way of doing things. But as mentioned in a previous comment, I've already dropped breqn from this document again, as all of you have suggested. Apr 9 '19 at 14:15

It isn't really a bug. breqn by design has to re-implement almost every aspect of math processing and as documented is thus incompatible with more or less any other math mode definitions that are not explicitly written to work with breqn.

Really breqn is an unfinished experiment and sadly its original author died some years ago, and so it is probably not really recommended for use in a production document unless you have very tight control over the input and know it works well on that input, some large but regular output from symbolic computer algebra systems fall in this category.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.