weird spacing with reveal
reagle opened this issue · 32 comments
The following command results in a PDF with too much spacing below the title in some slides.
decktape reveal -size 960x700 http://reagle.org/joseph/talks/2018/05-ica-lifehack.html test.pdf
For example, look at slide #5, "Genres". It's a 3 item numbered list, but item 3 is pushed off the bottom because of the spacing below "Genres".
I've already noticed some layout issues with images. Would you mind:
- Comparing with the PNG export by using the
--screenshotsoption and check whether it's only affecting PDF output - Creating a minimal test case so that we can report the issue to the Puppeteer project
Should --screenshots make a screenshots directory if it doesn't exist?
╰─➤ decktape reveal --screenshots --slides 4-5 --size 960x700 http://reagle.org/joseph/talks/2018/05-ica-lifehack.html test.pdf
Loading page http://reagle.org/joseph/talks/2018/05-ica-lifehack.html ...
Loading page finished with status: 200
Reveal JS plugin activated
Printing slide #/life-hacking-1 ( 4/33) ...
Error: ENOENT: no such file or directory, open 'screenshots/test_4_960x700.png'
The screenshot looks fine.
Thanks. Indeed output directory has to exist.
We need to produce a minimal test case, ideally removing Decktape from the equation, and submit an issue to the Puppeteer project.
- Why not have it automatically create directory if it doesn't exist?
- Here's a mimimal-er example.
decktape reveal http://reagle.org/joseph/talks/2018/min-eg-decktape.html test.pdf
Loading page http://reagle.org/joseph/talks/2018/min-eg-decktape.html ...
Loading page finished with status: 200
Reveal JS plugin activated
Doesn't look like it has anything to do with images. (I don't know anything about decktape or Puppateer, just download decktape today in hope of using it.)
Why not have it automatically create directory if it doesn't exist?
That's an improvement I want to do, though not high priority.
Doesn't look like it has anything to do with images
It's more related to the page layout. I faced some similar issues with absolute positioning. We need to find a minimal HTML page that reproduces the issue, like puppeteer/puppeteer#915. But you can try reporting the issue directly to Puppeteer and we'll progress /refine from there.
I don't know javascript and don't use this software, so I'm not the best reporter for puppeteer. But hopefully my example gives you something to start with.
No worries, I'll try to isolate the issue ASAP.
I'm facing exactly the same issue. It seems to have something to do with using <ul>'s and <ol>'s.
On one page I have code that looks like the following and the space appears between the <p> and the <ul>.
<h2>blah</h2>
<p>blah</p>
<ul>blah</ul>
I observed the same issue. On some of my reveal.js slides are a header and an image or a header and a list, but in pdf export the images/lists are moved at or below the bottom of the page. The screenshot export seems to be correct.
Same issue here. I can see it even when comparing the pdf rendering for the second page of the standard reveal.js demo. The arrow images at the "vertical slides" section are also very obviously wrongly positioned.
mac OS X used here.
Is there a workaround? Because besides decktape there is no alternative. reveal.js' ?print-pdf feature is still broken. Some issues there were closed but I have different problems now...
I managed to workaround the issue by combining the use of latest decktape with decktape 1.0.0.
Setup:
decktapeinstalled via package (currently 2.9.1)popplerinstalled via package (providespdfunite)decktape.jsis agit checkout v1.0.0then apply this patchphantomjs-linux-x86-64downloaded from here
Render slides that look good with old decktape:
./phantomjs-linux-x86-64 decktape.js -s 1280x720 --slides 1-9 slides.html OlivierBilodeau-Cybersecurity_from_the_Trenches-1-9.pdf
./phantomjs-linux-x86-64 decktape.js -s 1280x720 --slides 11-35 slides.html OlivierBilodeau-Cybersecurity_from_the_Trenches-11-35.pdf
./phantomjs-linux-x86-64 decktape.js -s 1280x720 --slides 39-50 slides.html OlivierBilodeau-Cybersecurity_from_the_Trenches-39-50.pdf
Render slides that look good with new decktape:
decktape --chrome-arg=--no-sandbox -s 1280x720 --slides 10 slides.html OlivierBilodeau-Cybersecurity_from_the_Trenches-10.pdf
decktape --chrome-arg=--no-sandbox -s 1280x720 --slides 36,37,38 slides.html OlivierBilodeau-Cybersecurity_from_the_Trenches-36-38.pdf
Combine everything:
pdfunite OlivierBilodeau-Cybersecurity_from_the_Trenches-1-9.pdf OlivierBilodeau-Cybersecurity_from_the_Trenches-10.pdf OlivierBilodeau-Cybersecurity_from_the_Trenches-11-35-valid.pdf OlivierBilodeau-Cybersecurity_from_the_Trenches-36-38.pdf OlivierBilodeau-Cybersecurity_from_the_Trenches-39-50.pdf OlivierBilodeau-Cybersecurity_from_the_Trenches.pdf
Voilà!
I also notice that I have complete sets of slides that still render properly with decktape. It is when I use specific things within revealjs that everything becomes corrupt. Nested lists seem to be one. CSS position: fixed seems to be another problem and using revealjs' stretch class too. There could be other things.
A workaround seems to be increasing (very much) the size. For example using --size='2048x1536' instead of --size='1024x768' works for me.
The workaround on increasing the size does not work for me, but using version 1.0.0 (which uses phantomjs instead of headless chrome and puppeteer) works fine: https://github.com/astefanutti/decktape/releases/tag/v1.0.0, so I would recommend just installing version 1.0 of decktape for anyone who needs to render reveal.js decks.
Hello, I also have the same issue with reveal.js presentation. Using v1.0.0 to bypass the problem. Any news regarding fix in the latest version?
@kzorba a minimal use case has to be built so that an issue can be reported in Chromium / Skia (the component used by the PDF engine). In the meantime, I'd be inclined to set the default size for Reveal.js to a larger value, as it seems to work-around the issue for some people.
As of today it seems ?print-pdf is working as expected.
@hvwaldow's workaround works too.
@astefanutti Can you help with creating a minimal reproducible example? I can create a reproducible example, but minimal as in puppeteer/puppeteer#915 is out of my reach with my limited JS/HTML/CSS knowledge. 😅 😇
I'm interested in this being fixed as well. For now the over-sizing workaround seems to be working for me.
@angelocroatti it looks like that's the root of our issue...
I had the same issue (with all the details and sample included), described in an reveal-md issue, to whom it may concern and help.
As a variation of the aforementioned workaround via increasing the size option, I have found that not providing a size option at all can also be worth a trial. I do however set a screen size in my reveal.js configuration, though.
Maybe this is of help to someone trying to work around the issue...
In the meantime, is there a fix or other solutions? No workaround works for me.
Currently, I have screenshots taken of the presentation and create a PDF file with those screenshots. However, the text cannot be highlighted and the quality is limited to the image resolution.
One option is to roll back to version 1.0, which is the last time decktape worked reliably for reveal.js slides: https://github.com/astefanutti/decktape/releases/tag/v1.0.0
This isn't @astefanutti's fault. It's a bug with Chromium that needs to be fixed by the Chromium developers, and there's nothing that decktape can do about it.
Decktape needed to move to Chromium/Puppeteer because since 2018, PhantomJS is no longer maintained (ariya/phantomjs#15344), so the old version of decktape that relied of PhantomJS won't be stable.
Basically, it's a bad situation, but there's not much any of us can do.
Have you tried opening your reveal.js presentation in Chrome, adding ?print-pdf at the end of the URL, and then printing from Chrome (Ctrl+P)? That is often the most reliable way to generate a PDF, at least for now.
Thanks for the feedback. I didn't mean to blame anyone. I am very happy that I can create a PDF at all with decktape.
I tried it via the Dockerfile which is included in the release of version 1.0.0. Unfortunately, there are very different spacing issues there.
I create the Reveal presentation with asciidoctor and use a header for my presentation there. Unfortunately this header is only displayed on the first page via ?print-pdf, because it has an absolute position in the HTML/CSS.
Anyway, thanks for the tips. I'll do some more trial and error. If I find a solution that works for me, I'll share it here.
A workaround seems to be increasing (very much) the size. For example using
--size='2048x1536'instead of--size='1024x768'works for me.
This actually saved my day. I had a very mixed presentation with backgrounds, footer and stuff, all I had was ?print-pdf and whatever combination I tried was useless (fixed one thing, two were broken), then I tried this, but the things that were broken magically went fixed, but other again went broken (like images pushed too low or too much space between some elements). By using --size I was able to have a perfect pdf export.
Note: since most presentations are 16:9, to render them the right ratio I safely use --size='2048x1200', which is not perfect ratio, but proven to work and reliable in my experience.
I wish I had found this before!
I've been able to mitigate spacing issues in the pdf output by switching from margin based spacing to using padding or even wrapping the misaligned element in a div with relative spacing and using absolute positioning to force it into the right position.
Changing:
<img style="margin-top: 20px;" ... />
To something like:
<div style="position: relative;">
<img style="position: absolute; top: 20px;" ... />
</div>
This should finally be fixed with the upgrade to Chromium 111, which contains support for printing via the new layout engine, a.k.a. LayoutNG, and some other related bug fixes:
https://chromestatus.com/feature/5108105013100544
https://bugs.chromium.org/p/chromium/issues/detail?id=1121942
I've had a ton of spacing issues with 3.4.1. Updating to 3.10 fixed all of the issues. Thanks!