Problems with data-uri image generation

64 views
Skip to first unread message

Yves-Alexis Perez

unread,
Jun 10, 2009, 7:14:09 AM6/10/09
to asci...@googlegroups.com
Hi Stuart,

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.

Cheers,
--
Yves-Alexis

Yves-Alexis Perez

unread,
Jun 10, 2009, 7:29:50 AM6/10/09
to asci...@googlegroups.com
On mer, 2009-06-10 at 13:14 +0200, Yves-Alexis Perez wrote:
> I didn't yet investigated the problem, but I guess, as +++ means
> something in asciidoc it gets filtered later in the process.

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.

Cheers,
--
Yves-Alexis

Stuart Rackham

unread,
Jun 10, 2009, 4:34:21 PM6/10/09
to asci...@googlegroups.com

Could you please post an example AsciiDoc file and image and I'll try to
to figure it out.

Cheers, Stuart


>
> Cheers,

Stuart Rackham

unread,
Jun 10, 2009, 5:31:40 PM6/10/09
to asci...@googlegroups.com

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.

Cheers, Stuart


>
> Cheers,

Stuart Rackham

unread,
Jun 10, 2009, 7:09:08 PM6/10/09
to asci...@googlegroups.com
I've just implemented a patch which should fix the problem, check it out
and let me know if it works:
http://hg.sharesource.org/asciidoc/rev/529eef550c82

Cheers, Stuart

Yves-Alexis Perez

unread,
Jun 11, 2009, 3:10:33 AM6/11/09
to asci...@googlegroups.com
On jeu, 2009-06-11 at 08:34 +1200, Stuart Rackham wrote:
> Could you please post an example AsciiDoc file and image and I'll try to
> to figure it out.

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.
--
Yves-Alexis

Yves-Alexis Perez

unread,
Jun 11, 2009, 3:20:30 AM6/11/09
to asci...@googlegroups.com
On jeu, 2009-06-11 at 11:09 +1200, Stuart Rackham wrote:
>
> I've just implemented a patch which should fix the problem, check it out
> and let me know if it works:
> http://hg.sharesource.org/asciidoc/rev/529eef550c82

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.

Cheers,
--
Yves-Alexis

trouc.png
trouc.txt

Arnauld Van Muysewinkel

unread,
May 26, 2016, 4:05:59 PM5/26/16
to asciidoc
Hi.

It seems this issue is still present.
I'm experimenting exactly the same with asciidoc 8.6.9 (under OSX).

Unfortunately, the link to the patch proposed by Stuart Rackham is not reachable anymore.

Could someone point me to any kind of solution / workaround ?


Thanx in advance.

-- 
Arnauld Van Muysewinkel

Arnauld Van Muysewinkel

unread,
May 26, 2016, 4:33:09 PM5/26/16
to asciidoc
I also posted a description of the issue here : https://github.com/asciidoc/asciidoc/issues/98

Reply all
Reply to author
Forward
0 new messages