unoconvert --convert-to txt output also has, for example, | colspan="13" |. This is indeed an output of some table, only that it wasn’t there with unoconv acting on pre 26 versions of LibreOfiice. I am aware to comparing unoconvert output to unoconv output. Is it by design?
With unoconvert communicating with
Version: 26.2.0.3 (X86_64)
Build ID: 620(Build:3)
CPU threads: 2; OS: Linux 6.18; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
26.2.0-4
Calc: threaded
Before trying to bibisect, I have restored the unohelper.py module of 26.2.0.3 as suggested in an answer from Feb 6, 2026 7:57 pm. With the restored module, unoconv, not unoconvert but unoconv, doesn’t output the | colspan="13" | terms when working with 26.2.0.3. Does that point to a bug in unoconvert? There are also other differences between the output of unoconv and unoconvert. For example, unoconvert seems to squeeze consecutive white space characters into a single white space character. While unoconv doesn’t do that. Perhaps the | colspan="13" | terms are by design?
Is there any point to bibisect, since I don’t have a good commit at hand?
Reexamining the output of unoconv, unoconvert and the original file, I have came to the conclusion that the colspan terms must be by design. And are a unoconvert issue. I guess the coders of unoconvert, who tried to improve unoconv as far as I can tell, decided their newer output is better.