I want to create a self-contained document with reveal.js output. The wiki page gives a recipe to avoid manually providing reveal.js code by using:
pandoc --standalone --self-contained -t revealjs -V revealjs-url=http://lab.hakim.se/reveal-js document.md -o document.html
But this fails with:
pandoc: Cannot decode byte '\xbe': Data.Text.Internal.Encoding.Fusion.streamUtf8: Invalid UTF-8 stream
The content is served as GZIP compressed on http://lab.hakim.se/reveal-js, so I suspect pandoc is trying to interpret it as plain text...
It would be nice to support it, as there is currently no other way for building a self-contained reveal.js document than manually providing reveal.js code.
revealjs-url should point to a URL serving JavaScript, not HTML...
This is the correct URL, revealjs-url takes the base URL, the js is on http://lab.hakim.se/reveal-js/js/reveal.js, and it works correctly if not using --self-contained...
ah, sorry you're right. I can reproduce on current master:
echo '# test' | pandoc --standalone --self-contained -t revealjs -V revealjs-url='http://lab.hakim.se/reveal-js' -o document.html --verbose
...
[info] Fetching http://lab.hakim.se/reveal-js/lib/font/source-sans-pro/source-sans-pro-semibolditalic.ttf...
pandoc: Cannot decode byte '\xbe': Data.Text.Internal.Encoding.decodeUtf8: Invalid UTF-8 stream
so the question is why pandoc tries to utf-8decode the font file (which is binary of course), when using --self-contained.
So it looks like the problem is not with the actual js
source, but with the font, which pandoc is trying to read
as a UTF-8 text file. (We need to figure out why.)
+++ Mauro Bieg [Sep 11 17 12:19 ]:
[info] Fetching http://lab.hakim.se/reveal-js//lib/font/source-sans-pro/source-s
ans-pro-semibolditalic.ttf...
pandoc: Cannot decode byte '\xbe': Data.Text.Internal.Encoding.decodeUtf8: Inval
id UTF-8 stream
A clue?
% curl -v 'http://lab.hakim.se/reveal-js/lib/font/sourcesans-pro/source-sans-pro-semibolditalic.ttf' > /dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 107.20.159.165...
* Connected to lab.hakim.se (107.20.159.165) port 80 (#0)
> GET /reveal-js/lib/font/source-sans-pro/source-sans-pro-semibolditalic.ttf HTTP/1.1
> Host: lab.hakim.se
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 11 Sep 2017 15:58:42 GMT
< Server: Apache/2.2.31 (Amazon)
< Last-Modified: Wed, 27 Jan 2016 16:15:00 GMT
< ETag: "20b5c-3ad30-52a531a98bcde"
< Accept-Ranges: bytes
< Content-Length: 240944
< Cache-Control: max-age=3600, public
< Expires: Mon, 11 Sep 2017 16:58:42 GMT
< Connection: close
< Content-Type: text/plain; charset=UTF-8
<
{ [1096 bytes data]
100 235k 100 235k 0 0 562k 0 --:--:-- --:--:-- --:--:-- 562k
If I'm interpreting this right, it looks like their server is serving the ttf font file as text/plain. Pandoc is treating it as such because that's what the header says! (So it looks like a configuration problem on the reveal.js website, though I may be missing something.)
Possible workaround:
Let us know if it works.
The problem is with the linked font, not the reveal.js file itself. I don't see any hope of fixing this unless the reveal.js server configuration is fixed (see the linked issue to reveal.js, which has received no comments).
@bulrush15 it works but it is not the point, the goal being to build slides without having to download revealjs and have these dependency files in my project directory.
Another way could be to directly embed and distribute reveal.js files with pandoc...
The underlying issue in reveal.js is fixed.
But see the cautionary comment on that issue:
https://github.com/hakimel/reveal.js/issues/1984
Most helpful comment
A clue?
If I'm interpreting this right, it looks like their server is serving the ttf font file as text/plain. Pandoc is treating it as such because that's what the header says! (So it looks like a configuration problem on the reveal.js website, though I may be missing something.)