In this post we’ll shine some light on the level of CSS support that our conversion engine offers. As you can see all over the site we support CSS, quite some CSS2 and some CSS3. To be precise, you can see in this article on Wikipedia how Webkit compares against other rendering engines as far as CSS goes.
But one question that comes back from time to time is about the @page directive. The @page directive has been proposed to be part of CSS2 with the idea that it would be helpful for paged media. And since PDF is “sort of” a paged media, it appears to be quite useful.
To make a long story short – we do NOT offer @page support in our version of Webkit. And to be frank – we don’t think the ‘nightly build’ (as is specified on the development website) offers that support either. We know that, because we tried to implement it and have talked to its developers, who have long left the project.
But to offer some more positive news – we have a very useful alternative, which we’ve developed some time ago. It was inspired by a client that wanted to use @page to implement company stationary (so basicly the pre-printed paper you see lying around at all the big companies with logo / letterhead etc.). Because we feel that this type of functionality was very useful we added it to our HTML to PDF API as well as to the HTML to PDF SDK.
With this functionality you choose between three different ‘stationary backgrounds’ that can be applied to your PDF documents. These are:
- one for the first page
- one for all pages between the first and last page (if not specified, the first stationary background will apply)
- one for the last page
We accept all major image formats as input for these backgrounds and we also allow you to place them at any position you want or scale them to fit the whole page.
With this functionality we hope that you can at least cover some of the functionality that the @page directive was created for. It’s been live for quite a few months now and working flawlessly so we invite you to take advantage of it!