Hi Andreas,
The internal macro \@xmultirow is called by \mutirow and is never called
directly. That's why you dont see any \@xmultirow call in dblatex. This
macro has been transformed into a \long macro because it fails in some
cases.
So, for now it is best to apply your quick fix (which is the actual fix).
I know it is not really good to patch a package like this, but I prefer
using the current implementation with its improvements and just patching
it, than providing my own macro.
This said, I will try to retrieve the case that made \@xmultirow fail;
maybe that the current implementation is now robust to this case. Then the
\long patching could be removed.
Regards,
BG
On Mon, 10 Oct 2016 11:41:02 +0200, Andreas Hoenen
<andr...@hoenen-terstappen.de> wrote:
Andreas Hoenen <andr...@hoenen-terstappen.de> wrote:
Andreas Hoenen <andr...@hoenen-terstappen.de> wrote:
> Anders Kaseorg <ande...@mit.edu> wrote:
>
> > Package: dblatex
> > Version: 0.3.8-1
> > Severity: grave
> >
> > dblatex in sid fails on every document as follows:
>
> Hi Benoît,
>
> I want to notify you about Debian BTS report #840189 [1], indicating
> that dblatex doesn't work together with the new version of
multirow.sty
> [2]:
Hi Benoît,
the attached hotfix [1] seems to resolve the incompatibility between
dblatex and the new multirow.sty version.
However avoiding to call the \@xmultirow macro if it an internal one
would be a cleaner solution.
Hi Benoît,
is the problematic paragraph labeled "% Make \@xmultirow long" in
dbk_table.sty *needed at all* within current dblatex? I can't find any
calls of the \@xmultirow macro within dblatex, and after commenting out
the paragraph a DocBook example with a table containing multirows still
is transformed to PDF without errors and looks as expected.
Eliminating this paragraph from dbk_table.sty seems to be cleaner, more
robust and future-proof than my previous hotfix candidate.
What do you think?
Regards, Andreas
