PhantomJS 2: PDF rendering too large, page.zoomFactor doesn't work #12685

Closed
thomasbachem opened this Issue Oct 28, 2014 · 166 comments

Projects

None yet
@thomasbachem

I compiled PhantomJS 2 HEAD on OS X 10.9.5 (MacBook Pro Retina) via brew install phantomjs --HEAD.

When rendering a PDF via rasterize.js, the page contents are rendered much larger than with PhantomJS 1.9, and using the zoom argument doesn't change anything at all.

Experimenting with paperSize, the page contents that do usually fit exactly into 210mm (A4) do now need 303mm, so there's a 144% increase in size.

@elgarfo
elgarfo commented Nov 3, 2014

+1 experiencing exactly the same problem.
compiled from source (eddb0db) on debian 7.6

any idea how to work around this?

edit: used css to work around the problem for now
downsides: rendering gets a little ugly and its still a pixel too wide i'd say

html {
    zoom: 0.68; /*workaround for phantomJS2 rendering pages too large*/
}
@mgartner
mgartner commented Jan 3, 2015

I'm seeing this issue too. It is especially frustrating that I'm trying to use 2.0 to get webfont support, but normal HTML content doesn't fit into PDFs like it did so nicely in 1.9.x.

I'd really appreciate it if anyone could point me in the right direction to what might be causing this in the PhantomJS code base. I'd glady work on submitting a PR to fix this.

@thomasbachem

@ariya I fear this bug will be overlooked quite easily regarding the amount of open tickets. Perhaps you can mark this ticket properly as a regression?

@9point6
9point6 commented Feb 19, 2015

+1 still broken in 2.0 brach

@bompus
Contributor
bompus commented Feb 20, 2015

Still broken for me also. The elgarfo patch works, but it's hacky :)

@ariya
Owner
ariya commented Feb 22, 2015

@thomasbachem Good point, labelling it now. Thanks!

@ariya ariya added the Regression label Feb 22, 2015
@ariya ariya added this to the Release 2.1 milestone Feb 22, 2015
@thomasbachem

@ariya Thanks, I just linked two duplicate tickets.

@polarathene mentions some observations in #12936 that may be of help, though I couldn't verify those myself:

I've just done some thorough testing of 2.0.0 PDF conversions and noticed the paperSize 'A4' definition that was 992px wide(120dpi) in 1.9.8 is now 595px wide(72dpi) in 2.0.0. Previously in 1.9.8 your unit values other than % had were scaled down, so that the PDF version required you to zoom to 125% to view units at their original size, also caused the whitespace issue on the right present in your picture due to that scaling. In 2.0.0 units don't appear to be scaled down, they are 100% matching to the browser. paperSize however is now scaling up from it's given px size by 1/3rd, this is matching it to 96dpi/96px per 1 inch which is a CSS inch. Thus 72DPI 595px A4 paperSize is resized to 794px 96DPI A4 when rendered. I've also learnt from OSX(and likely Linux) users that 1.9.8 provided 100% match for their PDF renders but with 2.0.0 they're having to downscale their units from 96dpi to 72dpi, eg 794px wide element needs to be changed to 595px for correct 100% zoom A4 PDF, for comparision on 1.9.8 with windows users that meant changing from 96dpi to 120dpi, 794px wide element needed to be 992px wide. Also worth noting is that between both versions % units would still remain precise, 90% element would always be 90% of the PDF at 100% zoom, for whatever reason they were not scaled like other units.

@mkrn
mkrn commented Feb 25, 2015

+1 Version 2.0 fixes Function.prototype.bind but breaks paperSize)

@Feendish
Feendish commented Mar 6, 2015

Also experiencing this issue. I'd love to switch to v2 to fix the page-break-avoid:inside issue but this is a problem now.

elgarfo's tweak seems to work but as noted it causes rendering issues.

Has anyone a better work around? Are there adapted pixel settings for A4&Letter? I'm on Unix.

@polarathene

@Feendish I wrote a lot on the mentioned issue above, but if you read the workaround I gave for mac it should work for unix.

@jimclarkuk

@Feendish Following on from the analysis by @polarathene we opted for a transform which seemed to result in fewer rendering issues than using zoom.

.page {
    transform-origin: 0 0; 
    -webkit-transform-origin: 0 0; 
    transform: scale(0.75); 
   -webkit-transform: scale(0.75);
}
@Feendish
Feendish commented Mar 9, 2015

@polarathene thanks. You gave a comprehensive break down. I just couldn't follow it exactly.

I tried using the dimensions_width formula you suggested but it was still off.

In the end given your note that the DPI is 72 in Mac/Unix I use a DPI to pixel calculator http://www.hdri.at/dpirechner/dpirechner_en.htm and just hard coded the pageSize to 595x842 for A4 Portrait. 595px = 8.26772 inches x 72dpi where 8.26772=210mm.

@jimclarkuk I tried your solution too with no luck. Page breaking was messed up with overlapping elements.

@thomasbachem

@Feendish What exactly do you mean? Setting

page.paperSize = { width: '595px', height: '842px', margin: '0px' };

Doesn't change or fix anything for me under Mac OS X 10.9. The page is still too small compared to 1.9.8.

@Feendish
Feendish commented Mar 9, 2015

@thomasbachem I'm building the HTML from scratch to test it. Haven't tried running it on established HTML source yet.

I used Bootstrap 3 to make a sample long Invoice.

JS code-> http://pastie.org/10011943
HTML source -> http://s000.tinyupload.com/index.php?file_id=97390552363329839541
Bootstrap override.css -> http://pastie.org/10011951

It now generates a clean A4 sized portait PDF of 44 pages.

I'm on Linux (Centos 6.4).

@polarathene

@thomasbachem It's been a while but from memory that's the dimensions for A4 at 72dpi(Mac/Linux): http://www.a4papersize.org/a4-paper-size-in-pixels.php

Setting A4 as your papersize would have the same effect. I don't have a mac and haven't tested on linux, what are the px dimensions of an A4 pdf document for you at 100%? On windows they're A4 at 96dpi, I'm guessing you get 72dpi(595x842)? It's been a while but I think you need to upscale your viewport from 72dpi px to 96dpi. On 1.9.8 I used a similar technique that @jimclarkuk provided, though mine scaled up(120dpi to 96dpi). The windows workaround on 1.9.8 wasn't perfect however, if you can get away with it, you should be able to adjust the paperSize to fit your viewports(probably not the same px width/height) and then alter the zoom on the pdf viewer to see the document as intended.

Another alternative could be to run a windows VM or use a web service like Azure to run Phantom on a windows instance.

@Feendish
Feendish commented Mar 9, 2015

Just to clarify @polarathene on Linux setting "A4" as paperSize doesn't work. The content is sliced off on the right hand side.

I have to explicitly set the pixel width&height to get it to work on Linux with v2.0.0

@polarathene

@Feendish what viewport size are you using with your papersize?

@Feendish
Feendish commented Mar 9, 2015

I'm not setting a viewport. I always assumed it was one or the other based on Phantom examples.

Should I be setting one? In 1.9 branch it worked without viewport.

@polarathene

I'd be interested to know if your results are different after setting the viewport. If you get a full A4 pdf filled with the website, also try setting your viewport to half just to confirm that you're getting half once it's rendered to pdf format.

My understanding is that there is a default viewport size, I can't recall what that is though. Plenty of responsive sites will adjust based on the viewport you provide, as well as fixed width sites. Both I imagine can be affected by having a poorly chosen viewport size?

@thomasbachem

@polarathene @Feendish I tried to play around with setting different viewport sizes, and it changed nothing with PhantomJS 2.

@polarathene

@thomasbachem it would depend on the site you're rendering. If you use it on a responsive site that has a mobile layout at a small viewport, changing your viewport to a small size should trigger it just like resizing your chrome window would. I think rendering will still scroll the viewport if needed to fill in the papersize? I'll be using phantom again soon, perhaps can set up an example project for the issue with workaround :)

Honestly though, the issue is with phantom, with 2.0.0 osx/linux got the problems windows had with 1.9.8, while on 2.0.0 windows works like osx/linux used to. Whomever worked on that part of phantom should be able to provide a fix, even if it's a different build which breaks windows, I'd imagine that'd be the quick fix.

@polarathene

If phantomjs itself is the cause, I can only see tinkering with the values here: https://github.com/ariya/phantomjs/blob/2.0/src/webpage.cpp#L1061 that seem like they'd be relevant, but it might actually be handled by QT which was updated with 2.0.0. I see plenty of references for 96dpi, perhaps dpi handling has changed between the QT versions used in 1.9.8 and 2.0.0....which'd mean phantomjs won't ever fix this issue until QT does? I have no QT experience, if someone from the phantomjs team could chime in, is it a QT bug or has phantomjs done something differently with pdf rendering via QT since?

@Feendish
Feendish commented Mar 9, 2015

Setting a viewport of

page.viewportSize = {
width: 595,
height: 400
};

has no effect on the rendered page.

@polarathene

@Feendish try 100x100,if you're still getting no difference then tweaking viewport won't help much. Again I did say it completely depends on the website design itself. For the website I was working with, js scripts were generating highchart graphs based on viewport width, they rendered incorrectly without setting the viewport properly.

@jrf0110
jrf0110 commented Mar 10, 2015

+1 this sucks really bad :(

@thomasbachem thomasbachem referenced this issue Mar 10, 2015
Closed

Release of PhantomJS 2.0.1 #12902

0 of 7 tasks complete
@Vitallium
Collaborator

Can someone provide a working example? So can take a look on it.

@thomasbachem

@Vitallium That'd be great, thanks in advance! There is a test case in #12936.

You can also just compare the PDF output of any web page with rasterize.js in 1.9.8 and 2.0.0.

@floundies

just throwing my hat into the ring... also have this issue. switching back to 1.9.8 for the time being.

@dhwaneetbhatt

@floundies

paperSize: {
  width: (width * (72/96)) + 'px',
  height: (height * (72/96)) + 'px'
}

This seems to solve issues of broken PDF rendering on 2.0, the reason being they have made changes to the DPI in some way, detailed discussion here: #12936.

Let me know if that works for you.

@thomasbachem

@dhwaneetbhatt Doesn't work for me. Why reduce page dimensions when the rendering is too large already?

@polarathene

@thomasbachem You are using OSX/Linux? From what I understand you have 72dpi being used by the OS, and the browser displays at 96dpi. So when you provide px values those get scaled up to 96dpi and then rendered to PDF, @dhwaneetbhatt is reducing those values to 72dpi so that Phantom will return them to the size you wanted at 96dpi as you see in the browser. Alternatively provide the value in inches and multiply by 72, should have a similar effect.

So just to clarify, Phantom appears to upscale your px(and other units besides %) values to 96dpi, take the pic then save it back to your pdf which the image is too large for the original intended size. When you provide the size in 72dpi it should be corrected and look right. I use windows so I cannot verify this, on 1.9.8 I previously had to change my values from 96dpi to 120dpi due to the rendering being too small. This wasn't perfect though, and needed some extra code to scale css or text I think....which still wasn't 100% correct for some websites.

@thomasbachem

@polarathene Yes, I'm using OS X 10.9. I get what your saying, and it sounds reasonable, but it doesn't work on my environment.

As noted above and also observed by others here, the upscale factor is 1.44, so you need to e.g. set the CSS zoom property to 0.69 (= 1 / 1.44) to fix it. Dividing 72 and 96 dpi (= 0.75) doesn't lead to this number however.

Furthermore @dhwaneetbhatt proposed to reduce the page dimensions, but the content is rendered too large already, so we if we were going to work around this by manipulating page size (which sucks as I want an A4 PDF) we'd need to increase page size.

@polarathene

A4 at 72dpi should roughly be 597px by 842px, try using that as your paperSize? I'm assuming that when you provide paperSize as A4 it's using a different value? I see the zoomFactor solution as a bit odd at 0.7, fairly certain it's due to DPI, whatever caused the problem for OSX/Linux users with 2.0.0 fixed the same issue for Windows users in 1.9.8, I'm pretty sure that either PhantomJS or QTWebkit has changed the way it handles DPI.

Again to clarify, you are reducing the values so that Phantom renders at the correct values. With Windows we had to increase the page dimensions for content that was rendered far too small and this was a DPI issue with units. zoomFactor only scaled a portion of the the website correctly(text I think) when I tried that prior to rescaling the units before passing on to Phantom. It might have changed or be different for OSX/Linux users however.

Worth noting, depending on the website you're rendering, you may want to also adjust your viewPort size as well, I can't recall if I matched them or if one of these had not been affected by the rescaled units. What you need to keep in mind is that Phantom is adjusting your units prior to rendering, and that an A4 PDF has DPI of 96, at least on Windows which is a width of 8.3in to 797px at 100%.

Just to verify, does increasing the paper size work for you as you are stating it does? Or does reducing it have the desired effect?

@lasterra
lasterra commented Apr 8, 2015

My solution

           var zoom = page.zoomFactor;
            page.evaluate(function(zoom) {
                    document.getElementById('body').style.zoom=zoom;
             },zoom);
            page.render(output);
@YorickPeterse

Also experiencing this problem when using Phantom 2.0 on Linux, using 96 DPI. I'm using the following paper settings:

page.paperSize = {
    format: 'A4',
    orientation: 'portrait',
    margin: '1.5cm'
};

Rendering a report without any zoom settings (as mentioned by @elgarfo) results in my document being rendered as following:

broken

The resulting PDF spans multiple pages in the above screenshot. If I apply the following CSS:

body {
    zoom: 0.53; /* using 0.55 or higher results in the elements not lining up correctly */
}

I instead get the following PDF:

correct

This particular PDF only spans a single page (as intended, clipped off in the screenshot). The downside is that some text is a bit fuzzy and the spacing between certain elements is a little bit different.

@polarathene

@YorickPeterse Can you read my previous message and try setting the paperSize dimensions yourself instead of 'A4'? If that doesn't work can you also try adjusting the viewportSize dimensions as well? It's been a while since I've used Phantom, would be helpful to others if you can confirm my assumptions of the 2.0.0 linux/osx issues being similar to the windows issues in 1.9.8.

@YorickPeterse

@polarathene Using these settings I get a PDF that does fit on a single page, although said page (and its content) are much bigger than a usual A4:

page.viewportSize = {
    width: 1030,
    height: 1500
};

page.paperSize = {
    width: page.viewportSize.width,
    height: page.viewportSize.height,
    margin: '1.5cm'
};

These particular dimensions were based on the dimensions of the PDF, I set them in such a way that the width/height are enough to fit the document into a single page. Printing the resulting PDF works perfectly fine (probably because the printer downscales the PDF), so for now this should do the trick.

@andreild7

@YorickPeterse I'm using the same environment as yourself (Unix).

My workaround for v2 was as @polarathene says to explicitly set pageSize:

page.paperSize = { width: '595px', height: '842px', margin: '0px' };

The reason for those specific numbers for A4 is that DPI for Unix is 72.
A4 Portait in inches is 8.26772 x 8.26772 which translated to 595px by 842px.

Setting a viewPort has no effect.

It looks to me that the code isn't accounting for the fact that Linux is 72DPI. It assumes it's 96 which throws off all the calculations.
.

@YorickPeterse

@itgslabs

page.paperSize = { width: '595px', height: '842px', margin: '0px' };

These particular settings still result in content clipping out of the page:

clip

@polarathene

If I recall correctly, setting the viewport size can have an effect depending how your site works. For me I had a highcharts graph that set it's size based on the viewport size given not the pagesize. I'd have to look into my old source code but I am pretty sure for 1.9.8 on Windows, one was set to the A4 at 96dpi px size, and the other was set to 120dpi(page size I think).

For linux/osx you'd be using dimensions for 72dpi as @itgslabs confirms. When rendered the pdf at 100% should match in px the dpi it's being displayed at for A4? I cannot confirm on other OS but for Windows pdfs display at 96dpi thus a width of 794px.

I do remember that I also had to apply a CSS transform in addition to this, these seem familiar:
http://stackoverflow.com/a/10559205/2639089
https://filippo.io/taking-retina-screenshots-with-phantomjs/

You'd just want to do the opposite of scaling up. An alternative also might be SlimerJS.

@davidwindell

Doh! I just wasted a few hours getting 2.0 built and ready on Ubuntu 14.04 to discover A4 PDF's are doing this (cutting off the side of the page).

Does anyone have a working solution? Setting page dimensions didn't make a difference.

@zackw
Collaborator
zackw commented Apr 20, 2015

Do we understand to what extent this is PhantomJS .vs. Webkit's fault? Pinning that down seems like it needs to be the first step.

@bbrdaric

Is it even realistic to expect the same results from PhantomJS PDF export, as they are in Chrome/Chromium print preview / Save as PDF? I mean...that would be awesome!

To get this, I think we need to match PDF export settings. As far as I can tell from Chrome export settings, that would be

Format: A4,
Orientation: portrait
DPI: 600
Margin left: 0.4"
Margin top: 0.4"
Margin right: 0.4"
Margin right: 0.39"

I also tried to export some wide table and failed (table got cut off, similar to @davidwindell), but I need to investigate a bit more.

@MarttiR
MarttiR commented Apr 23, 2015

This not very elegant solution worked for me: pulled 1st1@de90d07 onto release 2.0 and replaced the hardcoded 72dpi values with hardcoded 96dpi values in the function stringToPointSize().

@davidwindell

@MarttiR broken link?

@toabi
toabi commented Apr 23, 2015

I guess @MarttiR means this: 1st1@de90d07

@mgartner
mgartner commented May 9, 2015

Does anyone have any idea on where this bug might live or how to start tracking it down? It's tough without any experience with this codebase, so does anyone with experience have ideas on where to start searching?

@polarathene

@mgartner It's possibly not in PhantomJS codebase but a change in QT's webkit. Or look at @MarttiR 's fix. From when I worked with the issue on Windows in 1.9.8(now fixed but an issue in Linux/OSX), I noticed that the input values at some point are altered(DPI thing), and while that also transforms units other than px such as mm, cm, etc; it did not affect % 100% remained 100% of the final document size, as did 50% stay at halfway. I assume those unit transformations are consistent with Linux/OSX in 2.0.0, so I'd look for code that is handling these unit conversions.

Alternatively if @MarttiR 's solution doesn't cause any problems, define constants for each supported platform DPI and perhaps a custom DPI variable, if you can detect the platforms DPI default to that, and have a cli flag enforce using different platform DPI's or a custom DPI value. Would there be any issues with that solution?

@mgartner

The company I work for desperately wants to upgrade to 2.0 to get web font support, but this bug is currently preventing us from doing so.

As we don't have in depth knowledge of this repository or WebKit, we were considering putting up some money on bountysource.com or a similar website to try to get this fixed as soon as possible. Has anyone had success with this approach, and would someone be willing to take a serious stab at it if we put some money behind it? Any idea what a fair price would be?

@Vitallium Vitallium self-assigned this May 14, 2015
@polarathene

@Vitallium When was this fixed in dev? I had a look at recent commits from this year and didn't notice any related to the issue. Any idea how far off a release containing the fix will be?

@Vitallium
Collaborator

@polarathene I fixed this issue but didn't push the fix yet. (https://github.com/Vitallium/phantomjs/tree/custom-dpi)

@Vitallium Vitallium added In progress and removed Fixed in dev labels May 15, 2015
@andrewmclagan

eagerly awaiting this PR!!!

@ZimbiX
ZimbiX commented May 16, 2015

I really appreciate you producing a fix for this @Vitallium. After building your branch though, I can't work out how to use it xP Is it possible / how does one call those methods be from the JS? Cheers

@rfink
rfink commented May 18, 2015

+1 this issue is holding us back

@TheSmokingGnu

Hi @ZimbiX

Did you manage to get this working? I was waiting for someone else to try before I did this in JS also.

@ZimbiX
ZimbiX commented May 26, 2015

@TheSmokingGnu I'm afraid not =( I've really spent far too long trying to do adequate PDF export, and to be so close is rather frustrating.

@wizpig64

@vitallium I'm having trouble building your custom-dpi branch on debian 8 64x. the 2.0 branch builds just fine using the instructions on phantomjs.org/build.html. I don't have any experience with make, but here's where the output fails, less than a minute in:

Building main PhantomJS application...

cd src/ && ( test -e Makefile.phantomjs || /home/phillip/Projects/phantomjs/src/qt/qtbase/bin/qmake /home/phillip/Projects/phantomjs/src/phantomjs.pro -o Makefile.phantomjs ) && make -f Makefile.phantomjs 
make[1]: Entering directory '/home/phillip/Projects/phantomjs/src'
make[1]: *** No rule to make target 'qt/mkspecs/linux-g++-64/qmake.conf', needed by 'Makefile.phantomjs'.  Stop.
make[1]: Leaving directory '/home/phillip/Projects/phantomjs/src'
Makefile:42: recipe for target 'sub-src-phantomjs-pro-make_first-ordered' failed
make: *** [sub-src-phantomjs-pro-make_first-ordered] Error 2

Thanks for your work on this issue, there seems to be a lot of us here waiting for this to be sorted out!

update
I needed the libicu52:i386 package to get the build working, I only had the 64 bit version.

@Vitallium
Collaborator

Hey guys, it would be nice if someone could compile this branch and test it to check if we really fixed this issue. Thanks!

To set custom dpi, use page.settings.dpi property.

@petergrainger

Hi @Vitallium

I'm having problems setting the dpi. I tried
page.settings.dpi = "75";
then
page.settings.dpi = "120";

and I didn't see any difference, is there some way I can hard code the value.

I tested this by compiling and running on:

Linux version 3.2.34-55.46.amzn1.x86_64 (mockbuild@gobi-build-31003) (gcc version 4.6.2 20111027 (Red Hat 4.6.2-2) (GCC) ) #1 SMP Tue Nov 20 10:06:15 UTC 2012

My javascript is as follows, I've added it to the rasterize.js that is included in by project (I didn't put the rasterize file there, but I'm stuck with it. The arguments I'm using are: token reportPath "A4") so I'm only setting address and output. Do I need to set a zoom factor and papersize also?

var page = require('webpage').create(),
    system = require('system'),
    address, output, size;

if (system.args.length < 3 || system.args.length > 5) {
    console.log('Usage: rasterize.js URL filename [paperwidth*paperheight|paperformat] [zoom]');
    console.log('  paper (pdf output) examples: "5in*7.5in", "10cm*20cm", "A4", "Letter"');
    phantom.exit(1);
} else {
    address = system.args[1];
    output = system.args[2];
    page.viewportSize = { width: 1100, height: 750 };
    if (system.args.length > 3 && system.args[2].substr(-4) === ".pdf") {
        size = system.args[3].split('*');
        page.paperSize = size.length === 2 ? { width: size[0], height: size[1], margin: '0px' }
            : { format: system.args[3], orientation: 'landscape', margin: '0cm' };
    }
    if (system.args.length > 4) {
        page.zoomFactor = system.args[4];
    }
    page.settings.userAgent = 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36';
    page.settings.dpi = "120";
@petergrainger

Oh, and and thanks for your work so far @Vitallium it's really appreciated!

@Vitallium
Collaborator

@petergrainger could you please try again? I pushed small changes.

@petergrainger

Thanks @Vitallium compiling now.

@petergrainger

Hi @Vitallium

I'm still unable to alter the dpi value
I tried with an integer
page.settings.dpi = 120;
and a string
page.settings.dpi = "120";

but I still can't see any change in the output. I can change the page size to fit or make the original page smaller but it doesn't look as good, thanks anyway. It worked OK in previous version (1.9) :) I would use that but I can't get it to work with https TLSv1.2

@Vitallium
Collaborator

I was able to change DPI on Windows and OS X. I'll check it on Linux.

@wizpig64
wizpig64 commented Jun 2, 2015

@Vitallium I was able to build on a fresh debian jessie chroot (commit 21722f7), but like @petergrainger I'm seeing no effect with setting page.settings.dpi. I am using a modified rasterize.js, similar to peter's.

@wizpig64
wizpig64 commented Jun 4, 2015

I booted into my pc's os x 10.10.1 hackintosh partition, and built the same commit there, and was still unable to see any changes when messing with page.settings.dpi. Maybe it has to do with other variables like zoomFactor, but I can't seem to get dpi to matter no matter what i fiddle with. Here's my script, like I said, pretty similar to peter's.

var page = require('webpage').create(),
    system = require('system'),
    address, output, size;

if (system.args.length < 3) {
    console.log('Usage: rasterize.js URL filename.pdf dpi zoomFactor');
    console.log('  paper (pdf output) examples: "5in*7.5in", "10cm*20cm", "A4", "Letter"');
    console.log('  image (png/jpg output) examples: "1920px" entire page, window width 1920px');
    console.log('                                   "800px*600px" window, clipped to 800x600');
    phantom.exit(1);
} else {
    address = system.args[1];
    output = system.args[2];
    page.viewportSize = { width: 1000, height: 600 }; //this viewport forces bootstrap's medium grid pattern
    size = system.args[3].split('*');
    page.paperSize = size.length === 2 ? { width: '8.5in', height: '11in', margin: '0px' }
                                       : { format: '8.5in*11in', orientation: 'portrait', margin: '0.25in' };
    page.settings.dpi = system.args[4];
    page.zoomFactor = system.args[5];

    page.open(address, function (status) {
        if (status !== 'success') {
            console.log('Unable to load the address!');
            phantom.exit(1);
        } else {
            window.setTimeout(function () {
                page.render(output);
                phantom.exit();
            }, 200);
        }
    });
}
@rfink
rfink commented Jun 4, 2015

Got it working hack-ily. Setting the zoom factory dynamically on the body, via evaluate. Still, I hope a fix comes through.

@schneidmaster

Hey @Vitallium - unless you recently changed it, I believe it's page.dpi not page.settings.dpi. I am seeing some changes when altering that setting but many page elements are still rendering too large - it seems to be primarily affecting padding/spacing.

@schneidmaster

As an update: I seem to have isolated the problem to some kind of issue with body elements being scaled up incorrectly. Using the compiled bugfix branch, setting page.dpi = 96.0;, and adding body { min-width: 1200px; } solved all of my issues.

@Vitallium Vitallium modified the milestone: Release 2.0.1, Release 2.1 Jun 9, 2015
@billschaller
Contributor

I am able to use page.settings.dpi to achieve the desired result.

There are some strange bugs however. For example, setting page.paperSize to Letter, and viewportSize.width to 2275, and dpi to 150 makes a 100% width div render within the confines of the produced 8.5in page, but measuring clientWidth on the body or div elements then returns 2275 pixels instead of what ends up being printed. I will try and put together a small demonstration case later this evening or tomorrow.

@elgarfo
elgarfo commented Jul 17, 2015

hey @zeroedin-bill what exact setup did u use? i tried building custom-dpi from @Vitalliums repository, but was unable to get any changes by setting page.dpi or page.settings.dpi.
i've used a fresh debian 7.8 x64 machine for building. i tried setting absolute pixel sizes and millimeters for the page and neither worked for me.

@billschaller
Contributor

Not to be rude @ariya but this issue has been open over a year with no real progress on a fix. A lot of people, myself included, use PhantomJS for PDF rendering. So given the lack of any reasonable warning or explanation in the official documentation, I think this is probably about as appropriate a place as any to discuss alternatives and workarounds, including use of other packages.

In the interim while PhantomJS is broken, it is nice to know about alternatives that can render properly to PDF.

@ariya
Owner
ariya commented Jan 8, 2016

Frankly @zeroedin-bill that is quite rude. This is PhantomJS issue tracker so it's perfectly fine to focus the details of the defect for the benefit of someone who will volunteer to investigate and to fix it in PhantomJS. If you think this should be about "What is my alternative of converting HTML to PDF?" discussion, why not discussing it over in e.g. Stack Overflow? Not only it can reach a bigger audience and invite other experts, but it also keep the discussion here focused on PhantomJS-related details.

I tell you what, if you open a discussion on Stack Overflow as described above and link it from here, I think that's a win-win for everyone.

@billschaller
Contributor

@ariya Yes, that would probably work out, if there were not already a massive body of posts, questions, blogs, and content pointing people here for HTML to PDF rendering. There are forum posts that reference this bug ticket.

You've got a pile of open bugs around PDF rendering, and nobody with the free time and very specific and rare domain knowledge to fix them. That is OK. Everyone understands that open source is a labor of love and free time. Eventually I am sure someone with the time and skills will step up to fix this. In the interim, however, the correct solution is to simply fix the documentation by adding a section explaining the caveats and suggesting alternatives for the broken use case.

I won't clutter up the thread any further, but I will close by saying that I have found PhantomJS to be a very useful tool, and I very much appreciate the work you and others have done on it. I apologize for being rude.

@ariya
Owner
ariya commented Jan 8, 2016

This pageZoom factor issue is already mentioned in http://phantomjs.org/release-2.0.html (under the section Regression compared to PhantomJS 1.x).
If anyone has an idea on how to expand that text, edit the content (see the Please take a moment... at the beginning of the page), and create a pull request for that, I'd be happy to merge it.

@billschaller
Contributor

@ariya I've opened an issue to discuss modifications to the docs.

#13868

@Vitallium maybe you can shed more light on what exactly the issue is?

@Vitallium
Collaborator

@zeroedin-bill AFAIR, zoomFactor doesn't work at all, e.g. it does nothing with the latest QtWebkit upgrade. To ensure the consistency of PDF rendering on all platforms we have to solve two issues:

@trophygeek

@zeroedin-bill This workaround seemed to address the pdf output issue for me (@YorickPeterse mentions it above.) I'm curious if you tried it? Maybe this workaround doesn't work correctly on all platforms?

page.viewportSize = { width: 1238, height: 1763 };
page.paperSize = {width:'1238px', height:'1763px'};
page.settings.dpi = 150;

Notes: I'm running main branch code on Linux (Wheezy). I did have to play around with the sizes to find one that I liked. And, I'm using a self-modified qtwebkit that turns off @media printing as per this discussion.

@martonw
martonw commented Jan 8, 2016

Hi all - for proper PDF DPI setting there is a working version I submitted previously and hopefully it will be merged soon to the master I just need some clarifications to submit the changes - see comments here: #13583.
The bad news that you will not be able to change PDF DPI without any modification in qtwebkit - at least this is where I ended up - see the link for detailed explanation. You can play with page size and css zoom but neither of these will change the actual DPI. Even if you manage to have a proper zoom, any image, diagram or other graphic will have a low resolution and will look ugly in the exported PDF.

@billschaller
Contributor

@martonw That makes a lot of sense. So it sounds like to have a really usable PDF renderer we need changes to qtwebkit.

@zackw zackw modified the milestone: Release 2.1, Release 2.2 Feb 3, 2016
@bateller
bateller commented Feb 8, 2016

I'm running phantomjs 2.1.1 on CentOS 6.2 and having the same issue.

I tried changing viewport, pagesize, dpi setting, etc. all to no avail. The only thing that worked was setting CSS in the HTML of the page I'm rendering. Specifically setting:

<style type="text/css">
html {
    zoom: 0.55; /*workaround for phantomJS2 rendering pages too large*/
}
</style>

(I also tried 0.53 as someone else suggested, but 0.55 seemed to fit best with the 'original' PDF (pre 2.1.1).

Although this renders some lines thicker and a little off, but it's workable until theres a true fix.

I'm creating invoices in 8.5x11" format.

@marcbachmann marcbachmann referenced this issue in marcbachmann/node-html-pdf Feb 15, 2016
Open

Size of Rendered Content #110

@bubenshchykov

+1 struggling )

@vlapo
vlapo commented Mar 8, 2016

+1

@geri777
geri777 commented Mar 8, 2016

+1 - using 2.1.1 and there is NO affect on the PDF when changing viewPortSize or zoomFactor.
Latest working version is 1.9.8 - guys!!!

@elgarfo
elgarfo commented Mar 11, 2016

#13583 thank you so much @martonw this finally fixed my rendering issues. i used your pull-request to patch 2.2.0-development.

@astalwick

Seconded. Thanks to @martonw. I've been manually patching for awhile now.

I am very much looking forward to seeing some progress on this issue. It's been a year and a half since it was reported.

@Vitallium
Collaborator

Hi! We're really sorry for taking this issue to be fixed for a so-so-so long time. Thanks @martonw for providing the fix! Landed in master (dd07001)!

Thanks!

@ZimbiX
ZimbiX commented Mar 11, 2016

@martonw Nice work! I've been following this issue for some time, and didn't realise that you had since submitted a fix: #13583. Your issue explanation there is quite good.

There are happenings in a few places regarding this issue; also relevant: #13553

The cross-project modifications seems to have complicated things a bit. It appears that the required changes to qtwebkit were submitted by @131 and merged a few days ago by @Vitallium: Vitallium/qtwebkit#7

As far as my somewhat inexperienced eyes can see, the following is what now needs to happen:

  • Remove qtwebkit changes from @martonw's pull request
  • Update the qtwebkit dependency (this is probably the sticking point, with other things impacted)
  • Merge @martonw's PR

Thanks for the hard work everyone.

@ZimbiX
ZimbiX commented Mar 11, 2016

Haha nice xD

@Vitallium Vitallium added Need testing and removed In progress labels Mar 11, 2016
@Vitallium Vitallium closed this Mar 11, 2016
@Vitallium Vitallium removed the Need testing label Mar 11, 2016
@martonw
martonw commented Mar 11, 2016

Good news thanks @Vitallium. If you need anything else for this merge let me know.

@bubenshchykov

You guys rock!

@TWKDreamState

Is this in master now as I can't get it to work?

@JardarM
JardarM commented Mar 25, 2016

I have tried a few of the suggested trix above without success. Thus I was wondering if there was an official script fix to solve the PDF printing issue? I am using 2.1.1.

Also is there any release binary available for this fix?

@ppermezel-solucom

Hi,

I was stuck with the same problem with phantomjs-2.1.1-linux and finally these settings rocks for generating an A4 portrait version with 1cm margins:

rasterize.js :

"use strict";
var page = require('webpage').create(),
    system = require('system'),
    address, output;

address = system.args[1];
output = system.args[2];

var dpi = 72.0, dpcm = dpi/2.54;
var widthCm = 21.0, heightCm = 29.7; // A4
page.viewportSize = { width: Math.round(widthCm * dpcm), height: Math.round(heightCm * dpcm) };
page.paperSize = {width: page.viewportSize.width+'px', height: page.viewportSize.height+'px', orientation: 'portrait', margin: '1cm' };
page.settings.dpi = dpi;
page.zoomFactor = 1.0;

page.open(address, function (status) {
        if (status !== 'success') {
                console.log('Unable to load the address!');
                phantom.exit(1);
        } else {
                window.setTimeout(function () {
                        page.render(output);
                        phantom.exit();
                }, 200);
        }
});

CSS (extract):

@page {
    size: 21cm 29.7cm;
    margin: 10mm 10mm 10mm 10mm;
    orphans:4;
    widows:2;
}

html,
body {
    height: 100%;
}

body {
    margin:0;
    zoom: 0.75;
}

I hope it may help somebody...

@billschaller
Contributor

This is not yet in master - it is in PR #14085. I have tested the patch by Vitallium and it works for me consistently on both linux and windows.

See my comment: #14085 (comment) for more info.

@TWKDreamState

Agreed :) this works great - would be awesome to have it merged!

@jacquesfu

Merge +1

@mskrzypek

Merge +1

@billschaller
Contributor

@TWKDreamState @jacquesfu @mskrzypek It's been merged.

@scottmccaskill

I have been using PhantomJS for 3 years; version 1.9 randomly dies when creating lots of pdfs. Otherwise, it's been a great product for us. The suggested fix for this problem was 2+. Upon installing 2.1.1, I immediately ran into the issue of the zoomFactor not working at all/really huge pdfs that don't fit to A4 pages.

So I pulled master and tried to compile on Ubuntu 16.0.4 with 9GB free storage and 7.5 GB RAM. It fails every time with
Creating qmake...
.Done.
Running configuration tests (phase 2)...
No QPA platform plugin enabled!
If you really want to build without a QPA platform plugin you must pass
-no-qpa-platform-guard to configure. Doing this will
produce a Qt that can not run GUI applications.
The dependencies needed for xcb to build are listed in
src/plugins/platforms/xcb/README

I have xcb installed. I have tried modifying the build.py script to add -no-qpa-platform-guard. That will compile for awhile and then die at
kernel/qwidget.cpp: In member function ‘void QWidgetPrivate::show_sys()’:
kernel/qwidget.cpp:7921:50: error: ‘struct QWExtra’ has no member named ‘proxyWidget’
if ((q->isWindow() && (!extra || !extra->proxyWidget))
^
kernel/qwidget.cpp: In member function ‘void QWidgetPrivate::hide_sys()’:
kernel/qwidget.cpp:8056:50: error: ‘struct QWExtra’ has no member named ‘proxyWidget’
if ((q->isWindow() && (!extra || !extra->proxyWidget))
^

Makefile:47705: recipe for target '.obj/qwidget.o' failed
make[2]: *** [.obj/qwidget.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/ubuntu/phantomjs/src/qt/qtbase/src/widgets'
Makefile:497: recipe for target 'sub-widgets-make_first' failed
make[1]: *** [sub-widgets-make_first] Error 2
make[1]: Leaving directory '/home/ubuntu/phantomjs/src/qt/qtbase/src'
Makefile:45: recipe for target 'sub-src-make_first' failed
make: *** [sub-src-make_first] Error 2

ERROR: Failed to build PhantomJS! Building Qt Base failed.

I will pay cash money for someone who can get me a build on Ubuntu 16.0.4 that 1) dies less often and 2) does not have this zoomfactor/dpi problem.

Thoughts? What am I doing wrong?
Thanks.
Scott

@bcjordan bcjordan added a commit to code-dot-org/code-dot-org that referenced this issue Jun 2, 2016
@bcjordan bcjordan Revert phantomjs version to fix ariya/phantomjs#12685 649d8b5
@Guite
Guite commented Jun 16, 2016

Is there a linux 64bit binary available including this fix? Just working with 2.1.1-linux and trying to get a pdf exported with 300dpi.

@Guite
Guite commented Jun 16, 2016

I am checking the pdf file using: pdfimages -list -f 1 -l 3 output.pdf which outputs the following indicating the images having only 72dpi:

page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
   1     0 image       8     8  rgb     3   8  jpeg   no         9  0    72    72  631B 329%
   1     1 mask        8     8  -       1   1  jpeg   no         9  0    72    72  631B 7888%
   1     2 image       8     8  rgb     3   8  jpeg   no        13  0    72    72  631B 329%
   1     3 mask        8     8  -       1   1  jpeg   no        13  0    72    72  631B 7888%
   1     4 image     116   136  rgb     3   8  jpeg   no        20  0    72    72 7535B  16%
   1     5 smask     116   136  gray    1   8  image  no        20  0    72    72 1141B 7.2%
   1     6 image     128   128  rgb     3   8  jpeg   no        25  0    73    73 11.0K  23%
   1     7 smask     128   128  gray    1   8  image  no        25  0    73    73 1128B 6.9%
@ankit14101986
ankit14101986 commented Jul 21, 2016 edited

@Vitallium That would be great if you can share any rough idea/time on when the resolution of pdf export zoom/scale issue resolved and available in the binary format?

Appreciated your efforts.

@israelidanny

I second @ankit14101986
We have a major dependency on the ability to generate PDF documents, and the latest problems introduced across the board in phantomjs in all recent versions (1.9.x and 2.x) created total havoc. All of our customers are affected.

If there's any way to help speeding this being released up - I'd love to help.

@jleppert

It's not surprising this issue has yet to be fixed fully. The images are of course not respected for the DPI based upon my investigations and in fact vector content is not preserved as well, the entire thing is just one huge image. Just see for yourself with the cairo tools, open up the PDF. PhantomJS is not a good solution for rendering HTML to PDF.

@motoservo
motoservo commented Aug 1, 2016 edited

Haven't read over this entire thread because it's too long. But for any interested, it was 1.9 that was mis-rendering the size and that was a known bug. I'm sure it's discussed in other threads but from what I remember it was fixed in 2. Which might explain why it suddenly broke for people who may not have been aware older phantom was wrong. Test in Weasyprint as a reference. or any other renderer.

@polarathene
polarathene commented Aug 2, 2016 edited

@motoservo Not sure what the situation is currently, but iirc the problem that was fixed with 2.0 ended up appearing on other platforms instead of the affected platform(s) in 1.9. So bit of a tableflip, the problem isn't exactly the same, one was to do with images being too big the other too small from memory.

@ricokahler
ricokahler commented Aug 6, 2016 edited

This issue should be reopened because I don't think setting the page.settings.dpi does anything.

By default, the PDF on linux tends to have bigger text. I was able to get the PDFs to render as the same size as chrome renders (i.e. the normal size) but this solution requires hard-coding desired DPI value.

A few observations

Disclaimer: these observations may be wrong but going through the source code and running my simple tests prove them to be true.

The current QWebFrame::print(...) that the current master of phantomJS uses, does not scale the painter at all because in the current qtwebkit that phantomJS uses scales the painter by:

const qreal zoomFactorX = (qreal)printer->logicalDpiX() / printer->resolution() which I think works out to a zoomFactor of 1 all the time.

I found that printer->logicalDpiX() and printer->resolution() will always hold the same value: If you take a look at QPdfWriter and QPrinter, they both delegate to QPdfEngine. And if you look at the QPdfEngine::metric() with the case QPaintDevice::PdmDpiX in the qtBase, you'll see the that the logical dpi is equal to the resolution of the printer.

And since the page.settings.dpi property sets the resolution of the pdf writer the page.settings.dpi won't have any affect on the scale of the painter.


My patch fixes the multipaged PDFs and scaling inconsistency issues but again it hard codes the DPI to 96. What we really need some way to replace the hard-coded 96 with the custom DPI property set by page.settings.dpi. From the observations above, the printer->resolution() cannot be used.

I don't think it would be all that bad to hard-code this value to 96. Chrome seems to render PDFs at 96 DPI and more importantly hard-coding the value provides consistency. I don't think setting page.settings.dpi works in the current branch (especially because multipaged PDFs are broken).

Edit:

I think page.settings.dpi is currently broken in the master.

    pdfWriter.setResolution(m_dpi);
    std::cout << "m_dpi: " << m_dpi << "\n";
    std::cout << "pdfWriter.resolution(): " << pdfWriter.resolution() << "\n";
    QVariantMap paperSize = m_paperSize;

(i have no idea how to properly debug c++)

var page = require('webpage').create();

page.settings.dpi = 500;
page.content = '<html><head></head><body><h1>Heading 1</h1><p>The quick brown fox jumps over the lazy dog.</p></body></html>';

page.onLoadFinished = function () {
    page.settings.dpi = 500;
    page.renderBase64('pdf');
    phantom.exit();
};

This always prints 96 dpi for me.

I think the real solution is to add the methodQWebFrame::print(QPagedPaintDevice *pagedPaintDevice) to QWebFrame in webkit. QPagedPaintDevice is the super type for QPrinter and QPdfWriter. but QPagedPaintDevice doesn't have ::resolution() but if my observations are correct, then this should be the same as ::logicalDpiX.

I think a possible solution would be to change the print(...) to take in an additional two parameters.

void QWebFrame::print(QPagedPaintDevice *pagedPaintDevice, qreal dpi, qreal zoomFactor) const
{
    QPainter painter;

    if (!painter.begin(pagedPaintDevice))
        return;

    const qreal zoomFactorX = (qreal)pagedPaintDevice->logicalDpiX() / dpi * zoomFactor;
    const qreal zoomFactorY = (qreal)pagedPaintDevice->logicalDpiY() / dpi * zoomFactor;

    // similar to qprinterRect from ::print(...)
    QRect unscaledRect = pagedPaintDevice->pageLayout().paintRectPixels(pagedPaintDevice->logicalDpiX());
    QRect pageRect(0, 0, int(unscaledRect.width() / zoomFactorX), int(unscaledRect.height() / zoomFactorY));

    QtPrintContext printContext(&painter, pageRect, d);
    painter.scale(zoomFactorX, zoomFactorY);

    int lastPage = printContext.pageCount() - 1;
    for (int page = 0; page < printContext.pageCount(); page++) {
        printContext.spoolPage(page, pageRect.width());
        if (page != lastPage) pagedPaintDevice->newPage();
    }
}

I'll try to implement something like this soon and i'll post results back here.

This should fix:

  • multipaged PDFs
  • zoomFactor
  • DPI
  • renderBase64('pdf')

We should also remove support for printing headers and footer because I've found them to be slow but that's a different topic for discussion.


Related issues: #14268 #12691 #12936


@israelidanny @ankit14101986 @motoservo Try my patch. it might fix your issue. Here's some binaries (use at your own risk)

@destegabry

This issue is labeled as closed but I still have problems rendering multipaged PDFs on PhantomJS 2.1.x as the rendered pages are zoomed in. Any news on this?

@cmoulliard cmoulliard referenced this issue in marcbachmann/node-html-pdf Aug 31, 2016
Open

zoomFactor doesn't work with phantomjs-prebuilt #175

@ebdrup
ebdrup commented Sep 3, 2016 edited

Workaround for this bug

After 3 days of work I finally managed to find a good workaround for this bug.

We render pdfs, pngs and jpgs with phantom 1.9. This bug has been preventing us from upgrading for months. This bug is only present when rendering pdfs.

I pass a querystring to the page being rendered if rendering a PDF:
?compensateForPhantomV2PdfRenderingBug=true.

On the page being rendered I insert the scaling solution described above:

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
</head>
<script>
if(document.location.href.indexOf('compensateForPhantomV2PdfRenderingBug=true') !== -1){
    var css = 'body { transform-origin: 0 0; -webkit-transform-origin: 0 0; transform: scale(0.75); -webkit-transform: scale(0.75); }';
    var head = document.head || document.getElementsByTagName('head')[0];
    var style = document.createElement('style');
    style.type = 'text/css';
    if (style.styleSheet){
        style.styleSheet.cssText = css;
    } else {
        style.appendChild(document.createTextNode(css));
    }
    head.appendChild(style);
}
</script>

I know this is a phantom bug, because we detect how big to render our content, in pixels, with javascript like this:

var pixels = function (cm) {
    if (typeof cm === 'number') {
        return cm;
    }
    if (dimensions[cm]) {
        return dimensions[cm];
    }
    var $dim = $('<div style="top:-10000px;left:-10000px;position:absolute;width:' + cm + ';height:1px;"></div>').appendTo('body');
    dimensions[cm] = $dim.width();
    $dim.remove();
    return dimensions[cm];
};
var pageHeight = pixels('29.7cm');
var pageWidth = pixels('21cm');

So the content should fit perfectly on an A4 page. It does fit perfectly in phantom 1.9. But is broken and too large on phantom 2.1. Adding the scaling as described above compensates for this bug.

Workaround for blank pages bug

Then I came across a bug that Phantom 2.1 was adding blank pages to the PDF, that phantom 1.9 did not. This might be caused by the scaling bug compensation mentioned above, so I'm mentioning it here. I found that adding this javascript fixes the issue with extra blank pages:

var $html = $(document.getElementsByTagName('html')[0]);
$html.height(0);

(I'm using jQuery, because we already have it on the page, there should be an easy Vanilla JS solution too)

@jasonmorita

For those going the page.paperSize route, be aware height is required.

@jasonmorita
jasonmorita commented Sep 29, 2016 edited

Similar to @lasterra my solution is this:

  page.open(url, function() {
      page.evaluate(function(zoom) {
        return document.querySelector('body').style.zoom = zoom;
    }, 1.0); // <-- your zoom here
  });
@fedenko fedenko added a commit to soft-solar/django-phantom-pdf that referenced this issue Oct 5, 2016
@fedenko fedenko added viewport size option and workaround for PhantomJS bug (ariya/ph… f9fa317
@israelidanny

Why is this closed? This is still an issue with a lot of dirty hacks and no proper fix
@Vitallium

@Vitallium
Collaborator

@israelidanny the fix has been landed to master and will be shipped with the next release version. If you feel that this issue is still present, feel free to file a new issue and attach a sample code that reproduces your problem.

@israelidanny

@Vitallium alright, not aware that it was fixed, last time I tried master it was deeply broken. I'll give it a try and report my luck here.

@gbraad
gbraad commented Oct 19, 2016

the snippet provided by @jasonmorita works: https://gitlab.com/gbraad/document-generation-assets/commit/7a6721d6005ac1a2a3a20e125b87ce5358835167.

This is still needed for the current published version on 2.1.1. It feels like a workaround and didn't solve the problem. In an older version: 1.9.0 I was able to only rely on the page.zoomFactor to accomplish the same. When is the fix expected to be released?

@jkondratowicz
jkondratowicz commented Oct 26, 2016 edited

The way I understand it, 2.2 release is not coming at all, instead 2.5 is planned, but is still very far away, so this issue won't be fixed any time soon - is this correct? Has anyone been successful in building a binary from current master? build.py is gone, so I'm not even sure how to get around to do that.

@tlauritzen

I have set the paperSize to A3, and everything seems to work fine (Phantomjs 2.1.1). This is my paperSize configuration:

page.property('paperSize', {
	format: 'A3',
	orientation: 'portrait',
	margin: { 'top': '1cm', 'left': '1cm', 'bottom': '2cm', 'right': '1cm' }
});

I had no problems with printers wanting to print in A3, and a colleague of mine added some extra (A4) pages without noticing :-)

Pagebreaks worked without additional hacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment