Open BenjaminAster opened 2 years ago
@BenjaminAster May I work on this issue?
@arya-vats Of course you may! After all, this is an open community where everyone can work on everything.
Saving a document as a PDF can be surprisingly complex for the average end user, so I think this is desparately needed. I like the idea of window.print({ saveAsPDF: true });
, but there should also be an option to change the default print settings, such as "Landscape" for layout, enabling "Background graphics" and the ability to change scale and margins.
Note The idea described in the following comment is redundant because, as @mbrevda pointed out, all of these things can be done with pure CSS. I'll keep my original comment here so that the conversation makes sense:
@anaestheticsapp Great idea! If author-controlled options like layout or background graphics would be implemented, I think it would make sense here to make them universally available for both printing and saving as a PDF. I'd suggest an additional settings
option where the author could tell the user agent how the print layout should look by default. The user should then be able to customize these settings in the browser's native printing dialog. The following is an example of how the Window.print()
parameter object could look like:
interface PrintOptions {
saveAsPDF?: boolean; // always sets "save as PDF" as the destination
print?: boolean; // always sets "print" as the destination
settings?: {
layout?: "portrait" | "landscape";
margins?: {
all?: number; // top, bottom, left, right
vertical?: number; // top, bottom
horizontal?: number; // left, right
top?: number;
bottom?: number;
left?: number;
right?: number;
};
scale?: number;
informationalText?: boolean; // headers and footers
backgroundGraphics?: boolean;
};
}
As an alternative to passing print options, would it make sense to specify them via CSS using Paged Media where all these (and much more) are already specified?
@mbrevda Ok, you're absolutely right! I've never looked into @page
before, but yes, it seems all those things can actually already be done with just pure CSS. Size and layout can be controlled via size
, margins via margin
, the headers and footers can be hidden by setting the @page
margin to 0 (and then giving the body a margin manually with @media print
), and background graphics can be enabled via the print-color-adjust: exact
CSS property (Chromium needs a -webkit-
prefix here).
So I guess the settings
option would actually be redundant here.
One thing that was brought up was the ability to not convert the entire page to PDF, but just a subsection of it, for example, for printing receipts:
<body>
<section><!-- App UI --></section>
<section class="receipt">
<h1>Receipt</h1>
<ul><!-- Receipt contents --></ul>
</section>
<section><!-- App UI --></section>
</body>
If there were a way to pass a selector like .receipt
, the user could create a PDF from only a subsection.
@tomayac This can already be done (with a bit of effort) by re-layouting the whole page with @media print {}
(as described in my Chromium Monorail comment) so that one element (in this case the <section class="receipt">
) fills in the whole page, and everything else (in this case the app UI elements) gets a display: none
.
But yes, I agree that it would be convenient to specify an element that gets printed individually and without some hacky CSS solution. Maybe something like window.print({ saveAsPDF: true, selector: "section.receipt" })
?
It would be useful to be able to edit the metadata. For example as of now I think it's only possible to have the user agent as Creator
and the moment you downloaded the pdf as CreationDate
, which seems strange if the documents report another date.
Interesting - didn't know about print-color-adjust: exact
and @page { size: landscape; }
, that's actually solving half my problems!
Instead of having a boolean, another option could be to just pass the HTML element into saveAsPDF.
window.print({ saveAsPDF: document.body })
window.print({ saveAsPDF: document.querySelector('section.receipt') })
Agree, would make sense to be able to specify metadata when generating the PDF document. I guess the browser could just use the data already provided by HTML <meta>
tags.
<meta name="pdf:title" content="Receipt">
could be used if the page generates a PDF from a subsection (as it would likely differ from the title of the HTML document).
To simplify the API surface, perhaps the ability to print could be added to any element, like someSelector.saveAsPdf()
To simplify the API surface, perhaps the ability to print could be added to any element, like someSelector.saveAsPdf()
:+1: In some situations it would be nice to have the ability to get the printed PDF file programmatically
There are several use cases where it would be handy to be able to show a "save as PDF" dialog programmatically. For example, a document editing application might want to allow their users to export the document as a PDF without using any PDF generation library. While most user agents already allow users to select a "save as PDF" option when a document is printed (e.g. when
Window.print()
is called), there is currently no possibility for the author to hint the browser that the print dialog should be shown with the "save as PDF" option enabled.I am proposing an addition to the
Window.print()
method with an optional parameter that allows authors to tell the user agent the way that the print dialog should be shown:If the user agent is not able to provide a way to export the document as a PDF, it may ignore this option.