1

I'm having trouble building a document using tex4ht with makecell.

Consider the following M(n)WE:

\documentclass{article}

\usepackage[T1]{fontenc}
\usepackage{booktabs}
\usepackage{lipsum}
\usepackage{makecell}

\begin{document}

\lipsum

\begin{tabular}{cccc}
\toprule
 & {\thead{production \\ (kt)}}
 & {\thead{imports \\ (kt)}}
 & {\thead{import. coef. \\ (\%)}} \\
\midrule
1924 & 55138 & 2100 & 3,7 \\
1925 & 62901 & 2200 & 3,4 \\
1926 & 68708 & 2600 & 3,6 \\
1927 & 62732 & 2600 & 4,0 \\
1928 & 63195 & 2500 & 3,8 \\
1929 & 74200 & 3100 & 4,0 \\
1930 & 59346 & 2800 & 4,5 \\
\addlinespace
1935 & 31030 & 1516 & 4,7 \\
1936 & 49398 & 2268 & 4,4 \\
1937 & 72808 & 2481 & 3,3 \\
\bottomrule
\end{tabular}

\lipsum

\end{document}

When processed with:

htlatex document.tex "xhtml,ooffice" " -cmozhtf" " -coo"

it outputs a document. But the place where the table lies turns into a "box" in the .odt output, and the file ends there.

As a matter of fact, the .odt is corrupt. LibreOffice opens it and doesn't complain, but unpacking the .odt the contents.xml is invalid and ends somewhere along the table.

It is enough to load makecell to reproduce the problem (even without using its macros, as long as there is a table).

Any thoughts on this? Better leave makecell? Or is there a way to work this out?

7
  • 1
    I guess that makecell redefines internal LaTeX macros for table handling, which breaks tex4ht table support. I will look at this issue later.
    – michal.h21
    Jun 4, 2018 at 6:07
  • @michal.h21 That's what I suppose too. I have been trying other similar constructs, and e.g. egreg's answer nesting tabulars, which doesn't break the final result, but also doesn't show up in it.
    – gusbrs
    Jun 4, 2018 at 10:16
  • 1
    There are several problems. First is that makecell really breaks something with tex4ht, the second is that there was wrong detection of tables nested inside other tables in tex4ht, the third is that LibreOffice doesn't seem to like nested tables. I need to investigate it moe.
    – michal.h21
    Jun 5, 2018 at 13:16
  • @michal.h21 I thank you very much if you do so. From my point of view, there is no real need to "fix" the relation of makecell and tex4ht (though that might be useful from a general point of view). If there's something reasonable that substitutes its function, I'd be already very glad. What I'm trying to do at the moment is to devise a LaTeX workflow that also leaves me with an .odt when needed. So I'm mapping what of the usual features I employ in LaTeX actually work with tex4ht (This means I may come up with more stuff this week).
    – gusbrs
    Jun 5, 2018 at 14:12
  • I've found that Makecell really breaks tex4ht, but it should be possible just normal nested tabulars, it is only necessary to edit the XML file, using make4ht script
    – michal.h21
    Jun 5, 2018 at 15:37

1 Answer 1

2

There are two problems. First one is a wrong configuration for the array package, which is required by makecell. It somehow breaks the default configuration for tabular in the ooffice output. The offending code is a following snippet:

\ifTag{vis-\TableNo-\HRow}%                                                                                                                                                                                  
      {\special{t4ht@[}\gdef\end:box{\special{t4ht@]}}}%                                                                                                                                                     
      {\global\let\end:box\empty}% 

The \ifTag command checks a existence of cross-reference defined in the .xref file - tex4ht keeps stuff like hyperlinks and other information needed between compilations. The code

 {\special{t4ht@[}\gdef\end:box{\special{t4ht@]}}}%

is executed on the next and following compilations after the table have been added to the document. It disables processing of characters and spaces using \special{t4ht@[}, their processing is enabled with \special{t4ht@]}, which is executed in \end:box macro. The problem is that the instruction \special{t4ht@]} is inserted one more time somewhere in the process. This causes tex4ht to immediately stop the output, so the XML file stops inside the table and rest of the document is omitted. The XML file is of course invalid. It all happens only at second and subsequent compilations, not on the first one, which makes it even harder to trace source of this issue.

I don't really know why this whole thing is used anyway, I cannot see a difference when it is omitted. I hope it is safe to delete it. Because ooffice.4ht is huge, I will post only needed patch here:

--- /usr/local/texlive/2018/texmf-dist/tex/generic/tex4ht/ooffice.4ht   2018-06-08 00:41:40.000000000 +0200
+++ makecell/ooffice.4ht    2018-06-15 14:24:09.787127871 +0200
@@ -1794,8 +1794,9 @@
 %
    }
    {\HCode{</table:table>}}
-   {\ifTag{vis-\TableNo-\HRow}%
-      {\special{t4ht@[}\gdef\end:box{\special{t4ht@]}}}%
+   {
+%\ifTag{vis-\TableNo-\HRow}%
+      %{\special{t4ht@[}\gdef\end:box{\special{t4ht@]}}}%
       {\global\let\end:box\empty}%
 %
     \HCode{<table:table-row \Hnewline

The second issue is that the subtables inserted by makecell are places inside paragraphs, which is not supported by the ODT format. It is hard to fix that using just macros, it is better to use a make4ht filter.

File mybuild.mk4:

local domfilter = require "make4ht-domfilter"

local process = domfilter {
  function(dom)
    -- process all tables which are child nodes of text:p element, which is forbidden
    for _, table in ipairs(dom:query_selector("text|p table|table")) do
      print "*******************************************"
      -- replace the text:p with table:table
      local parent = table:get_parent()
      parent:replace_node(table)
      print(parent:get_parent():serialize())
    end
    return dom
  end
}

Make:match("4oo", process)

Note that the development version of make4ht, not the version on CTAN is needed. Compile using:

make4ht -e mybuild.mk4 -f odt filename.tex

This is the result:

enter image description here

2
  • Wow!! Impressive! That was a tricky one, eh! :) Thank you very, very much!
    – gusbrs
    Jun 16, 2018 at 19:57
  • thanks, it was indeed mysterious issue and hard to identify
    – michal.h21
    Jun 17, 2018 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .