LyX ⇒ compilation fails, outputs anyway, "%" width for floats

[ExecutorElassus]

I have a document containing about a dozen child documents, totaling about 350 pages. It's a rather complex file, but I'm running into a weird error in compilation that I can't nail down. It works like this.

I get the following error:

Code: Select all

! Missing number, treated as zero.
<to be read again> 
                   \scr@dte@pagenumberwidth 
\scr@tso@figure@pagenumberbox ...@pagenumberwidth}
                                                  {\hfil #1}
<argument> ...scr@tso@figure@pagenumberformat}{9}}
                                                  }\@par 
\scr@tso@figure@entryformat #1->#1
                                  
\scr@dte@tocline ...pagenumberformat}{#3}}}\@par }
                                                  }}\tocbasic@SetPenaltyByTO...

\l@figure ...ure}\scr@dte@tocline {figure}{#1}{#2}
                                                  \TOC@EntryEndHook {figure}
\contentsline ...L \endR \fi }\hyper@linkend }{#3}
                                                  \or \csname l@#1\endcsname...
l.65 ...el of narrative rhetoric.}}{9}{figure.2.1}
                                                  %
A number should have been here; I inserted `0'.
(If you can't figure out why I needed to see a number,
look up `weird error' in the index to The TeXbook.)

! Illegal unit of measure (pt inserted).

This isn't terribly helpful, but that statement on l.64 is a figure float, with its width specified in "Column width %" through LyX. This message repeats for every figure in the document.

The weird part is, whether it gives me the option to "show output anyway" it does complete compilation, and the output pdf seems fine.

Also weird, and annoying, is that if I isolate any single child document (using the document settings from the master document), they all compile on their own fine without any error messages.

This started happening after updating my system texlive, which has been on a 2019 version for almost a year.

What's going on here? Any advice on how I can track it down? I seem completely unable to pare it down to an MWE. Is there something newly changed about how texlive handles figure-wrap floats?

Cheers,

EE

[Ijon Tichy]

The error message is in the *.lof file. It seems it is because of a wrong setting of pagenumberwidth for figure entries. This can also be a wrong setting of \@pnumwidth. But without minimal working example this is very speculative.

[ExecutorElassus]

Hi Ijon,

thanks for the reply. Where would I find the settings for pagenumberwidth and \@penumwidth? I haven't specified them in my document settings, as far as I know.

Cheers,

EE

[Ijon Tichy]

Class, package, preamble code, some strange LyX special code, …

In LaTeX you can change a setting until it is used, so it can be everywhere before \listoffigures. Once again: Without minimal working example I cannot say anything more.

BTW: I do not use LyX, because I do not like to add LyX issues to LaTeX issues.

[ExecutorElassus]

OK, I've isolated the issue. I'm attaching what LyX exports to TeX with my current setup, as well as the source file.

In this document, if I have a "List of Figures" object, the bidi package loaded (for bidirectional text), and specify a figure wrap float's width in percent, it throws the error. Remove any one of those three and it compiles without error. You can replace the image there with whatever image you prefer.

I'm not sure why the LyX is putting a % sign at that position. Any suggestions?

Thanks for the help,

EE

[Ijon Tichy]

Please send bug reports to the LyX maintainers. First of all it is not recommended to set \parindent and \parskip directly. With the standard classes this should always be combined with usage of package parskip. With KOMA-Script \setparsizes (or option parskip) should be used. Additionally combination of a KOMA-Script class with fancyhdr is not recommended. It is recommended to use scrlayer-scrpage instead of fancyhdr. And \centering is a command not an environment. Mis-using it as an environment doesn't make any sense at the shown place.

As I do not know, whether or not you have candleshape.def, dropshapte.def, TeXshape.ded, triangleshapes.def, the code is not really reproducible.

Why are you using package bidi? Do you really use right-to-left typesetting in your real document. If not, you should not load it.

Are you using XeLaTeX or LuaLaTeX? With XeLaTeX I have the problem, that Linux Libertine O and Linux Biolinum O are not found. With LuaLaTeX I have the problem, that the bidi needs XeLaTeX. I've done my tests without loading these fonts. Recommended for loading Linux Libertine and Linux Biolinum would be to use package libertine, because this works with XeLaTeX, LuaLaTeX and even PDFLaTeX.

You are using an external image. For a minimal working example you should always use a dummy image (see package mwe) or a placeholder like a rule.

And you should report a bidi bug: The problem seems to be bidi's redefinition of \scr@dte@tocline. The original code does define \scr@dte@pagenumberwidth before it is used. But the bidi definition of \scr@dte@tocline does not. So this is a bug in bidi. There are other problems with bidi and up-to-date KOMA-Script, because it uses deprecated commands. This should be fixed to.

As a workaround you could try

Code: Select all

\makeatletter
\newcommand*{\scr@dte@pagenumberwidth}{\@pnumwidth}% DON'T USE THIS UGLY HACK!
\makeatother

at the end of your document preamble. But this not a real fix of the problem but only a ugly hack that could result in other problems. And nobody would give support for documents with such ugly hacks. So I would never recommend to use it.

And once more: The % is not the problem. % starts comments in TeX and comments are even used to deactivate line endings, which are white spaces otherwise.