self-hosting (own server) and new version of reveal.js

[turboteddy]

Hi there.

User story As a user, I want to use asciidoctor-reveal.js to generate slides that I can host on my own server, using node / npm.

Problem The optional step 4 in the install guide is sub-optimal. I suggest a solution that is simple but effective: A --static attribute, as for example reveal-md offers. It works well as a script defined in package.json, e.g.

"scripts": {
  "build-static" : "reveal-md src/ --css src/css/inject.css --static public/slides --static-dirs=src/assets",
}

This is clean and DRY, easy, and makes all relevant resources (including right version of reveal.js) automagically ready for deployment (without being constrained to Gihub pages).

Speaking of reveal.js version: I noticed that your very recent release (v2.0.1) still uses reveal.js 3.7.0, while reveal.js 3.8.0 has been out for quite a while.

[obilodeau]

The step 4 you refer to is when using the Ruby stack. Using node / npm reveal.js will be pulled in by default due to: https://github.com/asciidoctor/asciidoctor-reveal.js/blob/35b2bfadd34711c6b62d6f7e013b80b9b501d621/package.json#L49

The AsciiDoc document will refer to that reveal.js directory by default unless the revealjsdir attribute is set.

I understand that you are trying to make our project simpler but I don't understand the reveal-md example you are giving me.

Try again using our node / npm stack and guide me into what needs to be improved.

Unrelated but regarding your last comment:

Speaking of reveal.js version: I noticed that your very recent release (v2.0.1) still uses reveal.js 3.7.0, while reveal.js 3.8.0 has been out for quite a while.

We know. Even our recently released 3.0 still uses reveal.js 3.7.0. 3.8.0 is a breaking change for our users since embracing it means generating HTML that will break users of previous versions. We are tracking that progress with this milestone: https://github.com/asciidoctor/asciidoctor-reveal.js/milestone/8

[turboteddy]

Sorry for the late response, @obilodeau .

What I meant to demonstrate with the reveal-md example, is a simple, effective and DRY way to generate slides that can be hosted anywhere (i.e. self-contained, with all relevant resources available). As the Static Website build mode of reveal-md is explained:

This will export the provided Markdown file into a stand-alone HTML website including scripts and stylesheets. The files are saved to the directory passed to the --static parameter (default: ./_static):

reveal-md slides.md --static _site

This should copy images along with the slides. Use --static-dirs to copy directories with other static assets to the target directory. Use a comma-separated list to copy multiple directories.

reveal-md slides.md --static --static-dirs=assets

This works nicely, and I can use a package.json script to generate the self-contained slides, e.g. with this setup in package.json:

"scripts": {
  "build-static" : "reveal-md src/ --css src/css/inject.css --static public/slides --static-dirs=src/assets",
}

The essence is that the resulting output is a self-contained ("portable") static folder, containing all the required resources to serve the slides (images, css, js). I'd love to migrate to asciidoctor-reveal.js, as I prefer to use the AsciiDoc format. But I do not have the resources to configure and maintain a custom build process for asciidoctor-reveal.js which would allow me to get the same result as with the above described convenience of reveal-md's inbuilt Static Website build mode. I can imagine there are other folks out there with the same need for a simple and effective build process for static, self-contained slides that can be...

1. copied as a folder (portable)
2. hosted anywhere (relative references to all relevant resources in same folder / subfolders)

The revealjsdir-attribute is nice to have, but should ideally be unnecessary. That is because the resulting output is assumed to be dependent on a particular version of reveal.js - and should therefore correspond with the one defined in asciidoctor-reveal.js' own package.json. The option to use a CDN is nice - but for the same reason, the CDN path should ideally be provided automatically (to assure correct version of reveal.js for a given build of the slides).

I hope this makes it easier to understand the reveal-md example that I provided.

Cheers ;-)

[g4gilson]

hi @turboteddy, @obilodeau,

If I understand, the goal is to have the html page that can be printed properly offline and without navigator cache. It is actually possible with revealjs, highlight and MathJax (with incoming v4.1.0) with following configuration:

:revealjsdir: local/revealjs
:source-highlighter: highlightjs
:highlightjsdir: local/highlight
:stem:
:mathjaxdir: local/mathjax

but html, for this example, still use https://cdnjs.cloudflare.com/ajax/libs/font-awesome/[...] Maybe there is a way to point to a local repertory for font-awesome to get only local ressources in our html page

[ggrossetie]

but html, for this example, still use https://cdnjs.cloudflare.com/ajax/libs/font-awesome/[...] Maybe there is a way to point to a local repertory for font-awesome to get only local ressources in our html page

Yes, you can use :iconfont-remote!: and put font-awesome.css in stylesdir. For consistency, we could remove iconfont-remote and replace it with :fontawesomedir:. Thoughts?