docbook writer->reader loses link href

[arcnmx]

Explain the problem.

Using some example input:

[![alt](https://img.shields.io/badge/License-Apache%202.0-blue.svg "title")](http://www.apache.org/licenses/LICENSE-2.0)

... we get:

<para>
  <link xlink:href="http://www.apache.org/licenses/LICENSE-2.0"><inlinemediaobject>
    <imageobject>
      <objectinfo>
        <title>
          title
        </title>
      </objectinfo>
      <imagedata fileref="https://img.shields.io/badge/License-Apache%202.0-blue.svg" />
    </imageobject>
  </inlinemediaobject></link>
</para>

(we already lost the "alt" text btw 😞)

if we feed this back into pandoc, we end up with a lot less than we started with:

[![](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](#)

So the reader has lost:

• url href (apparently replacing it with #)
• the title
• the alt text (well the writer actually lost this first)

An alternate universe

Let's see what happens if we enlist the help of the asciidoc writer instead:

http://www.apache.org/licenses/LICENSE-2.0[image:https://img.shields.io/badge/License-Apache%202.0-blue.svg[alt,title="title"]]

curious that it escapes commas as &#44? my local pandoc 2.17.1.1 does not do this, so I'm not sure if this is just a try pandoc bug or an actual pandoc bug, but it doesn't work, so fix it before continuing:

asciidoctor -b docbook - <<EOF
http://www.apache.org/licenses/LICENSE-2.0[image:https://img.shields.io/badge/License-Apache%202.0-blue.svg[alt,title="title"]]
EOF

now we get new and exciting output:

<?xml version="1.0" encoding="UTF-8"?>
<?asciidoc-toc?>
<?asciidoc-numbered?>
<article xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<info>
<title>Untitled</title>
<date>1980-01-01</date>
</info>
<simpara><link xl:href="http://www.apache.org/licenses/LICENSE-2.0"><inlinemediaobject>
<imageobject>
<imagedata fileref="https://img.shields.io/badge/License-Apache%202.0-blue.svg"/>
</imageobject>
<textobject><phrase>alt</phrase></textobject>
</inlinemediaobject></link></simpara>
</article>

Which pandoc obviously likes a lot better:

[![alt](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](http://www.apache.org/licenses/LICENSE-2.0)

That's almost entirely where we started! I think the summary here is roughly:

• the writer produces fragments rather than full documents by default, while the reader can't deal with fragments properly
  (it doesn't know what an xlink:href is without xmlns telling it first, presumably)
  • additional fun: asciidoctor produces xl:href rather than xlink: to work around its use of a hacky macro parser, so you can't even bet on the namespace actually being called xlink? .-.
• the reader can't read image titles that the writer produces
• the reader can read alt text but the writer can't produce it
• the asciidoc writer gained a bug somewhere between 2.17.1.1 and 2.19.2 related to that comma?

I gather that feature parity between a format's reader and writer isn't necessarily a given, but one would hope that basic inputs containing only some links and inline images wouldn't be too lossy right out of the gate - and that's not really the story here :<

Pandoc version?

https://pandoc.org/try/ pandoc version 2.19.2 because nixpkgs doesn't seem to care about keeping it up to date

[tarleb]

Thanks for this thorough report. Related issues are #8070 and #3177.