Asciidoctor images

[argent0]

Addresses #6538 by implementing jgm's proposed solution.

I had to change writer.asciidoctor to pass the tests.

Concretely:

Given the file: my-test.markdown

Inline-style: ![alt text](media/rId25.jpg)

Block image:


![alt text 2](media/rId26.jpg "image title")

The end.

This patch generates, after running:

$ stack run pandoc -- -f markdown test/my-test.markdown -t asciidoctor -o -

The following file:

Inline-style: image:media/rId25.jpg[alt text]

Block image:

image::media/rId26.jpg[alt text 2,title="image title"]

The end.

I think the current basic test doesn't distinguish between inline and block figures. Should the distinction be added to the basic test?

As mentioned in #3177, this fix is brittle for the time being.

I have only just seen kukimik's comment.

[argent0]

I see the asciidoc tests failing. According to https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#images
this is valid asciidoc syntax. So I will update the asciidoc test too.

[tarleb]

Thank you for your contribution, the result of this looks good. Below I list are a few things that came to mind, in no particular order.

Maybe checkout the type classe IsString, of which Doc Text is an instance. It allows to write a value as if it was a string. (E.g. Text 3 "foo" can be shortened to just "foo").

Pattern matching on the specific Doc constructors is clever, as it produces very compact code. But it is also fragile and would break if the return value changed, e.g. by changing the order in which values are concatenated. It would be more robust to construct the result directly. One option could be to construct a new image helper function which both blockToAsciiDoc and inlineToAsciiDoc can use.

[argent0]

I implemented @tarleb 's proposed refactoring of the common image code into a helper function that is called by blockToAsciiDoc & inlineToAsciiDoc.

I've run into some trouble though. The command

$ stack run pandoc -- -f markdown test/my-test.markdown -t asciidoctor -o -

generates:

Inline-style: image:media/rId25.jpg[alt text]                                                      
                                                                                                   
Block image:                                                                                       
                                                                                                   
image::media/rId26.jpg[alt text 2,title="image title"]Another paragraph.                           
                                                                                                   
The end.  

Notice the: "Another paragraph" at the the end of the block image.

Yet, the native output seems fine:

$ stack run pandoc -- -f markdown test/my-test.markdown -t native -o -

[Para [Str "Inline-style:",Space,Image ("",[],[]) [Str "alt",Space,Str "text"] ("media/rId25.jpg","
")]                                                                                                
,Para [Str "Block",Space,Str "image:"]                                                             
,Para [Image ("",[],[]) [Str "alt",Space,Str "text",Space,Str "2"] ("media/rId26.jpg","fig:image ti
tle")]                                                                                             
,Para [Str "Another",Space,Str "paragraph."]                                                       
,Para [Str "The",Space,Str "end."]]  

As the "Another paragraph" is in its own Para. 🤔

This is the input file my-test.markdown:

Inline-style: ![alt text](media/rId25.jpg)

Block image:


![alt text 2](media/rId26.jpg "image title")


Another paragraph.

The end.

Any idea, 1) if this is an issue; 2) where is the code to solve it?

Regards

[tarleb]

Great, looking good! I believe it should be enough to append a blankline to the result in the block. Similar to what happens in the last line of blockToAsciiDoc for Para elements.

[tarleb]

Almost ready to merge, just one tiny nitpick remaining: would you break the long lines 144 and 559 such that they have 80 chars or less? We try to keep all source lines below that limit. (I'm aware that 559 was overlong before, so it may as well stay that way. But since we are fixing things anyway...)

I think it could also be clearer to use Attr instead of (Text, [Text], [(Text, Text)]) in the type signature.

[tarleb]

Thanks, this looks good to me!

Leaving it to @jgm to double-check and merge.

[argent0]

Thank you for all the help @tarleb.

[jgm]

Looks good, thanks for the PR!