we ended up finding a weird problem in data-uri images. Some of them
weren't correctly displayed (not at all in gecko, and only part of them
in webkit). Looking at the html source, some characters were missing,
and doing a diff with the result of “python -uc "import base64,sys;
base64.encode(sys.stdin,sys.stdout" < img.png”, it seems that asciidoc
later stripped the “+++” characters which were present in the resulting
base64 encoded image.
I didn't yet investigated the problem, but I guess, as +++ means
something in asciidoc it gets filtered later in the process.
This is using asciidoc 8.4.4 on Debian sid. If you need more
information, please ask.
Ok and with another image, we had a line starting with // which appeared
blank in the final html :) So I guess there's definitely a problem with
the order, generated content shouldnt be parsed.
Could you please post an example AsciiDoc file and image and I'll try to
to figure it out.
You're right, the problem is in inline image macros (block macros should
be ok), the inline image data is generated by attribute substitution and
is begin reprocessed by subsequent substitutions. The only way around
this that I can think of would be to introduce a variant of the eval
system attribute which would passthrough it's result.
Not really because they are private, but I'll try the patch as soon as I
return to work (unless I manage to find another image). And I've noted
that image::foo.png should workaround the problem.
I'll keep you posted.
Seems to work. I'm attaching the source image and the asciidoc file. It
doesn't work with 8.4.4 (in the .html, a complete line is blanked
because of a //) but works with 599:529eef550c82.
Thanks for the quick fix.