Document why Chrome is needed (firefox seems to print fine to PDF)

[olberger]

Hi.

The docs mentions that the PDF export (https://github.com/hakimel/reveal.js#pdf-export) requires Chrome, but AFAICS, the printing to PDF seems to work for me in Firefox 45.

However, this may be related to the particular choice of background and other presentation options I've chosen for my particular slide deck.

Would you mind documenting what really requires Webkit, or is this maybe something that varied in time as other browser engines were improved ?

Thanks in advance.

[geerlingguy]

Ditto—I just tested in Chrome, FireFox, and Safari on Mac, and Chrome on Mac doesn't actually allow 'show backgrounds' in the print options. Safari and FireFox do, but only FireFox will print the full page width without any margin (Safari seems to add in margins even if you opt out of the URL/date metadata).

[geerlingguy]

Here are the settings I used with FireFox 47, and they worked great to produce a 16:9 aspect ratio presentation export (note that I created a custom page size with 0 for margins on Mac OS X 10.11):

[prakriti-patra]

Hi, I have made a presentation using RevealJS that uses PlotlyJS in its slides. The presentation works fine in Chrome and FireFox. However, the PDF Download functionality is not working in FireFox as expected. Only one page gets printed which has the first 2 slides. Each slide does not break into a different page. In Chrome, it works perfectly fine though. I am using Firefox Version 49.0.2.

I have initialized my Reveal code using

Reveal.initialize({
          controls: true,
          progress: false,
          history: false,
          center: true,
          theme: Reveal.getQueryHash().theme, 
          transition: Reveal.getQueryHash().transition || 'default', 
        });

I have also included the pdf.css file using

<script>
  var link = document.createElement( 'link' );
  link.rel = 'stylesheet';
  link.type = 'text/css';
  var url = window.location.href;
  var inst = url.match('print-pdf');
  link.href = (inst && inst.length && inst.length > 0) ? '/assets/pdf.css' : '/assets/paper.css';
  document.getElementsByTagName('head')[0].appendChild(link);
</script>

Has anyone faced a similar issue? Any help would be largely appreciated.

[rugk]

I think this info is outdated. Print stylesheet should be supported quite fine in most cases…

Would you accept a PR to remove this dependency from the Readme?

[Jmuccigr]

FWIW, on Safari 11.0.3 in High Sierra 10.13.3, Safari always shows the background, no matter what the status of the checkbox.

[rugk]

Yeah, okay, some browsers prevent t6he background from being colored. But that may be deactivatable in the settings (in Firefox it is, AFAIK).

[Jmuccigr]

I meant that Safari does show the background and the checkbox doesn't affect it.

[shmerl]

I tried printing to PDF in Firefox 70.0b4 - the result is not readable.

[lanmaster53]

So, everything has been printing fine in Chrome for me, but every other browser is a mess. I believe this is still an issue and here's why.

My presentation is all markdown with the same background on every slide. I used custom code to add a footer and border to every page, but only when printing. I do a lot of front end development and played nicely within the confines of each slide to provide these features. In Chrome, FF, and Safari on MacOS, the presentation renders perfectly in the browser in both presentation and print-pdf modes.

The problems begin when I actually print the page (mainly in FF). When I began having the print issues addressed below, I reverted back to stock and introduced each custom feature one-by-one to discover which feature was breaking things. Sure enough, the outline and footer were indeed the issues, but not because of my custom code. I know this because as I said above, all of the browsers rendered them properly, and Chrome (and to some extent Safari) even printed it perfectly, exactly how it was in the browser window, which was the expected behavior for all.

The unique thing about print mode vs. presentation mode is that the only thing that fills the entire slide area of each printed page is the background element. Therefore, this was the element that I had to attach the border and footer to so that it would appear in the same place on each page. A key thing to remember is that this element also contains the configured background image.

When printing in FF, the first page was fine, but I noticed that FF only printed the background image on the first page. However, it continued to print the border and footer on subsequent pages without the image, and this caused the border to escape the bounds of the page and the footer to float to the top. Almost as if the background element, which the footer and border were attached to, wasn't there anymore, or was substantially changed, causing some really confused rendering. I tried every combination of FF print settings, but nothing fixed it. Clearly FF is breaking the background portion of the DOM somewhere between rendering the print-pdf page in the browser and passing it to the system for printing.

Safari actually prints the background and footer correctly like Chrome did. However, as someone mentioned above, it maintained space for other printed elements even when they were disabled in the print settings, and that pushed everything around and made a mess of things. This is clearly a Safari issue.

Chrome is great, behaves as expected, and does everything I need.

Once again, when rendering print-pdf mode, everything looks perfect on every browser. It is when the browsers pass the DOM to the system print dialogue that things get crazy and FF and Safari just aren't playing well enough with Reveal right now.

[rugk]

So would be nice to open bug reports for Firefox and Safari, would not it?

[lanmaster53]

I hesitate to open a bug when I don't have a better idea of what is going on. Especially since I went back, attached my outline and footer to a different element (a new element that was added in a more recent version), and everything is now working on all browsers. (Safari still does it's weird hidden element thing though).

[rugk]

FYI Firefox is looking into improving their print support, ref https://twitter.com/svoisen/status/1182728307223085056.