If you want to use the new PrintToPDF functionality in 2025r2 please vote for the following feature requests:
Page number and page count for PrintToPDF Options for header and footer in PrintToPDF Write PDF in PrintToPDF to memoryblock and not to folderitem Options for margins for PrintToPDF Option for paper size/orientation needed for PrintToPDF
The last one is the most important one. We asked what the use case is for printing one page only and didn’t get a reply. I need A4 and not one single page in PDF.
3 Likes
Emile Schwarz:
2025r3 ?
2025r2 is the release version with the new but not very useful feature of PrintToPDF.
What Trix calls PrintToPDF is DesktopHTMLViewer.PrintToPDF(file As FolderItem)
And what she desires is just a question of CSS (@media styles) as:
Not sure if feasable by an external interference from Xojo. The devs should taylor theirs designs as they desire.
I already explained that, but now I can show something:
<!DOCTYPE html>
<html>
<head>
<title>A4 PDF with Header and Footer</title>
<style>
@media screen {
header {
display: none;
}
footer {
display: none;
}
}
@media print {
@page {
size: A4;
}
header {
position: fixed;
top: 0;
left: 0;
right: 0;
height: 50px; /* Adjust as needed */
background-color: lightgray; /* Optional background color */
text-align: center;
}
footer {
position: fixed;
bottom: 0;
left: 0;
right: 0;
height: 30px; /* Adjust as needed */
background-color: lightgray; /* Optional background color */
text-align: center;
}
main {
padding-top: 50px; /* Make space for the header */
padding-bottom: 30px; /* Make space for the footer */
}
}
</style>
</head>
<body>
<header>This is the header</header>
<main>
<p>Your content here...</p>
<p>Your content here...</p>
<p>Your content here...</p>
<p>Your content here...</p>
<p>Your content here...</p>
<p>Your content here...</p>
</main>
<footer>This is the footer</footer>
</body>
</html>
1 Like
can this be called in code without opening the desktophtmlviewer??? something similar to wkhtmltopdf in the command line??
That’s not exactly “code” (well, parts are kind of). I would call them more like presentation styles with conditional features.
They can be injected in your HTML to stylize them, with different presentations per media (screen, printing…)
Then the viewer will render your content following your style guidance.
Tricks can be made I think. A small hidden viewer used just as a render engine for example.
I think that in many cases the HTML may have a
@media screen {
body {
display: none;
}
So in a viewer it is blank, no content. But as @media print is defined, it prints and creates PDFs out of this “nothing”.
Not tested, just thought right now. 99% of chances of working without issues… theoretically.
The last time I checked that it wasn’t supported by Webkit.
Rick Araujo:
A small hidden viewer
Hidden, yes, small, no. The last time I checked that the rendering time was faster if the html viewer is of medium size.
No, the html needs to be loaded into a htmlviewer. Even the long dead wkhtmltopdf does that internally I’m sure.
It makes no sense, if Webkit does not support standard features, it’s useless.
Beatrix Willius:
Hidden, yes, small, no. The last time I checked that the rendering time was faster if the html viewer is of medium size.
Not sure. Maybe Display: none makes it fast as it will not try to render for screen. For printing it will use A4 offscreen.
No, Webkit does not support headers and footers. Just for you I tested again on Sequoia. Here is the result:
It does, but seems that their layout engine is defective.
In safari, the footer is not placed at the end of the page as instructed.
But Firefox renders correctly…
And Xojo does the worst case
Using print it acts like this, print on A4 considering some smaller area and ignoring background paintings
And PrintToPdf() is something even worse, completetely disobey all instructions resulting this (not even an A4, no header or footer):
So PrintToPdf() is doing a worst job than Print() deepening the inconsistencies.
I guess that Safari like inconsistencies may be worked around finding the “Safari only CSS instructions”
I would prefer a CEF for macOS and have it working seamlessly equal on all platforms using the same markup instructions.
You are funny. I already have a solution in place which can print multiple pages correctly. The only drawback is that this is done in 2 steps.
Beatrix Willius:
You are funny.
Sometimes I can be.
Share your code with Xojo, have you fixed webkit?
The Xojo people should know how to use declares on macOS. PDFs from html can be created with an NSPrintOperationMBS(Monkeybread Xojo plugin - NSPrintOperationMBS class ). The second part for header/footer uses CGPDFDocumentMBS (Monkeybread Xojo plugin - CGPDFDocumentMBS class ). You draw the first PDF inside of the final PDF and then add the header and footer.
Better to use standard procedures an make them consistent and multiplatform.
1 Like
