Closed Bug 851937 Opened 11 years ago Closed 3 years ago

[css3-page] implement @page { size: <length>{1,2} | <page-size> }


(Core :: Printing: Output, enhancement)

Not set





(Reporter: bugzilla, Unassigned)


(Blocks 3 open bugs)


(Keywords: css3, dev-doc-needed, testcase-wanted)

8.1. Page size: the 'size' property
Name: 	size
Value: 	<length>{1,2} | auto | [ <page-size> || [ portrait | landscape] ] 

This property specifies the target size and orientation of the page box's containing block. In the general case, where one page box is rendered onto one page sheet, the 'size' property also indicates the size of the destination page sheet. 

Examples of @page's size usage:

size: <length>{1,2}
@page {size: 4in 6in;} /* 4 inches wide by 6 inches high in default portrait orientation */

size: <page-size>
@page {size: letter;} /* 8.5 inches wide by 11 inches high in default portrait orientation */

size: <page-size>
@page {size: A4;} /* 297mm wide by 210mm high in default portrait orientation */

size: <page-size>
@page {size: legal;} /* 8.5 inches wide by 14 inches high in default portrait orientation */
Does this block or depend on bug #851441?
Depends on: 851441
Blocks: 911804
Blocks: 947125
any news for this?
I don't understand what this feature is supposed to do.  How does it interact with a printer having only particular sizes of paper, and the user having chosen one of those sizes already?
Summary: [CSS3 Paged Media] Support for @page size → [css3-page] implement @page { size: <length>{1,2} | <page-size> }
Take as example a Shower.js presentation example (, they use the size for set the dimension of the print page.
If you open the site on Chrome you can see a full page in printing but in Firefox have a wrong layout.
Even simply adding support for the `[ portrait | landscape ]` portion of this spec would go a long way for fixing developer headaches with printing in Firefox. I don't even care if the user is able to change the orientation of the page afterward in the print dialog, I just want the intended orientation to be preselected when the print dialog pops up.


I restart this bugzilla because the API is not implemented
I met one of the contributors to the "paged media" project [1] and the project is used by many people.

In addition, the layout is also important for web pages, online documentation and web press.

If a CSS file uses the code below, the code does not work because it is not implemented:

@media print {
    Page {
        size: 148mm 200 mm

Page W3[2] explains how to code it

I think it should be inserted in the DOM of the browser because it works on other browsers




Type: defect → enhancement

I'm Julie and I work on Paged.js (
Thank you @:hellosct1 to restart the bugzilla!

Paged.js is a free and open source JavaScript library that paginates content in browser to create PDF outputs of any HTML content. it's a sort of polyfill for some specific CSS modules for print. These modules are only in the working draft stage, so we understand that browsers do not choose to implement them. However, there is a large community of people who want to work with web technologies to make printed PDF, that's why paged.js exists.

We defend open-source and free software, we would very much like to use Firefox for our work. Unfortunately, at the moment, we cannot and are obliged to use Chrome/Chromium.
Our problem with Firefox is that we cannot influence the size of the PDF that will be generated from the CSS because the only property we need is not implemented.
We can't change the PDF size after (with custom sizes in the dialog box for printing) because paged.js redo the calculations of the declared size of the user based on bleed.

It would be awesome if Firefox implemented this missing property !

Thanks, Julie


Nikos here, currently working for the French Court of Audit ( We are at this moment implementing a solution based in Paged.js to automatise production of pdfs in the browser simply through html + css.

Basic idea : the reports of the court of audit are public documents that attract wide media attention every year, and we are seriously experimenting with the perspective of offering an html version of those reports that can be read directly in the browser and be printed (or exported as pdfs) directly from the browser (we are actually considering on going as far as switching our whole document production to html by default!).

Our park of more than 1800+ laptops are all equipped with Firefox and since we are planning on implementing this feature in the near future, this might soon prove to be a blocking point for us. Firefox is for us a conscious choice, so it would really save the day if this property was implemented (and would avoid us searching for a Chromium workaround).



I'm Romain Lesur, data scientist using the R language and open-source contributor.
I co-authored an R package named pagedown ( which uses Paged.js to create reproducible scientific publications with web technologies. The very first release of pagedown was in January and we have ~1,000 downloads/month.
We got great feedbacks from many R users: they love the idea of using CSS for Print!

As @julie_b explained, we cannot use Firefox for now and a chromium-based browser is the only option. Some R users told me they were highly disappointed by this and I fully agree.

Moreover, in many places (my employer, for instance) the only authorized browser is Firefox. In short, I am locked and cannot use CSS to design reproducible scientific publications with FOSS.

Please, help us to use HTML and CSS for Print anywhere with FOSS!

It sounds like most of the use cases for this (as opposed to bug 851441, for the simpler case of just portrait and landscape) relate to print-to-PDF. Are there cases where you want this for printing to paper? If so, what do you expect to happen when the user doesn't have the desired paper sizes available?

(It's not that clear to me what should happen with this feature when the page author specifies certain paper sizes and the user is trying to print and doesn't have those paper sizes.)

Hi there, i'm Julien from the paged.js core team, happy to jump in.
I'm pretty happy to see this opened again. Thanks a lot for this.

On the industrial side of things (aka making books for big publisher) PDF is what we'll need.
But at the same time, it's pretty useful to be able to print at the right size to see how the content looks, to tweak css and html if we need to.
Plus, it would allow the html to books community to build home made magazine and fanzines, reducing the needs to use proprietary software. But we could always print from PDF to check this if that was too much to add to firefox.

On your last question, David, the specs describes what should happen if the page-size is bigger than what the printer would let you do (see 7.4 and 7.5 here:

If the page size is smaller than the sheet of paper, i would assume printing in the center of the page, so you could, with transparence, check recto/verso, baseline, etc. [book designer stuff :D] . Even though having an interface control to let the user decide what to do would be ideal (but i guess it would also make it harder to ship the page: size feature).

I would be happy to help answering the questions you'd have, about what we're doing and how it works behind the curtains if that help you understand what we're trying to achieve.

I'm grateful to the team to look into that,
Thanks a lot.

thanks for putting back this issue into condireration.
I'm part of Open Source Publishing, Brussels, graphic design organization designing with only F/LOSS.
We make printed publications from HTML/CSS/Javascript since 2013. Yearly for the printed communication of a Brussels theater, and sometimes to make books (a novel with NLP research, and a 412 pages book, and the quarterly magazine Médor whose content is all input on the website CMS and generates both the website and the printed magazine.

We've been using Chromium when it was still under webkit for the CSS regions, a feature more than necessary to make this type of publications. Then Blink was born, we had to switch to Epiphany and even making our own flavor of webkit This solution is rather unstable as webkit has also abandoned the CSS regions, and we are applying a patch to "survive". This word sounds a bit too deep, but knowing that we have a quarterly magazine based on this process, we don't know what will happen when the patch will stop working.

There are more and more initiatives making books with web technologies, more and more design students are using them. Please consider looking at the CSS regions and the page size attributes? If the W3C has made those specs, I assume it is not out of nowhere and that they did see a general interest in print through CSS.

Thanks a lot for reading my position,
Stéphanie Vilayphiou

It would really be great if we could give this issue some love <3

Folks, I think you made your point clear :) We don't need more me-too comments.

(In reply to David Baron :dbaron: from comment #11)

It sounds like most of the use cases for this (as opposed to bug 851441, for the simpler case of just portrait and landscape) relate to print-to-PDF. Are there cases where you want this for printing to paper? If so, what do you expect to happen when the user doesn't have the desired paper sizes available?

(It's not that clear to me what should happen with this feature when the page author specifies certain paper sizes and the user is trying to print and doesn't have those paper sizes.)

This comes a little late, but i just found about this bug.

I think my best example is to refer you to:
In that case document-size is smaller than paper-size, so POS receipt prints the top_blank_margin - which results in a lot of paper waste (Printer is, however, able to cut just bellow the last text-line / before the bottom_blank_margin).

ideally it should just "print the document" without margins by adjusting the page size (for the cases where the document-size is smaller than paper-size or the cases where document-size is bigger than paper-size - that also occurs).

hope i was clear enough to be of any help

Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.