xetex build tests fail due to fontspec v2.6 defining ``\strong`` #3428

Closed
jfbu opened this Issue Feb 17, 2017 · 2 comments

Comments

Projects
None yet
2 participants
Contributor

jfbu commented Feb 17, 2017

latest update to fontspec defines \strong. This causes build failure for PDF output when latex_engine= 'xelatex'

! LaTeX Error: Command \strong already defined.
               Or name \end... illegal, see p.192 of the manual.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              

fortunately, Sphinx anticipated this some time ago ;-)

** (sphinx) defining (legacy) text style macros without \sphinx prefix
** if clashes with packages, set latex_keep_old_macro_names=False in conf.py

Hence, default configuration for xelatex should do this latex_keep_old_macro_names=False. The problem will also arise with lualatex if it uses fontspec. Currently default setting of Sphinx with lualatex does not yet do it because it needed to pass tests with Ubuntu Precise which has TeXLive 2009 whose fontspec did not yet have good support for lualatex (see #3070 (comment))

Problem

  • LaTeX PDF build fails

Procedure to reproduce the problem

  • set latex_engine = 'xelatex' in conf.py and run (with Sphinx default font configuration for xelatex) with fully updated TeXLive 2016 install.

Error logs / results

as above

Expected results

latexpdf compiles

Reproducible project / your project

any project using xelatex

Environment info

  • fully updated TeXLive 2016 (February 17, 2016)
  • Sphinx version: 1.5.2
Contributor

jfbu commented Feb 17, 2017

fontspec link: wspr/fontspec@f3f4132

@tk0miya tk0miya added the latex label Feb 17, 2017

@tk0miya tk0miya added this to the 1.6 milestone Feb 17, 2017

jfbu added a commit that referenced this issue Feb 18, 2017

Merge pull request #3430 from jfbu/fixfontspecxetexclash
add deprecation helper to LaTeX style file (and fixes #3428)
Contributor

jfbu commented Feb 18, 2017

the immediate problem is fixed at b0a5ec1 for 1.5.3 release. Discussion on future policy continues at #3429.

@jfbu jfbu closed this in 3c77408 Feb 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment