Some time ago (read about it here) we introduced shared server packages, which allowed for unlimited usage on a server that’s shared with other customers.
This is sort of an intermediate package between the regular packages we offer and the private server packages, where you get a whole server to yourself – or even a whole load balanced landscape.
However, we have now decided that we will NOT add any more shared servers to our landscape. This means that all slots that are still open are going to be the last ones that you can get – until one of our current shared customers leaves/downgrades/upgrades of course.
At the time of speaking we still have spots in all three geographical areas – Asia, Europe and the USA – but they may be gone very quickly. Please contact us to discuss pricing and terms if you’re interested in your own spot on one of these conversion servers.
All our services have always allowed you to define your own page size by using width and height parameters, or by setting a default page format in your members area.
We have also made the parameters pagesize and orientation available to both the API as well as the save as PDF link. This will allow you to control the page sizing more easily. In case you were looking for information on page breaking, then you may want to check out information on the blog here.
List of supported page sizes
We currently support the following list of page sizes in our rendering process.
|A0||841 x 1189 mm, 33.1 x 46.8 in|
|A1||594 x 841 mm, 23.4 x 33.1 in|
|A2||420 x 594 mm, 16.5 x 23.4 in|
|A3||297 x 420 mm, 11.7 x 16.5 in|
|A4||210 x 297 mm, 8.3 x 11.7 in|
|A5||148 x 210 mm, 5.8 x 8.3 in|
|A6||105 x 148 mm, 4.1 x 5.8 in|
|A7||74 x 105 mm, 2.9 x 4.1 in|
|A8||52 x 74 mm, 2.1 x 2.9 in|
|A9||37 x 52 mm, 1.5 x 2.1 in|
|B0||1000 x 1414 mm, 39.4 x 55.7 in|
|B1||707 x 1000 mm, 27.8 x 39.4 in|
|B2||500 x 707 mm, 19.7 x 27.8 in|
|B3||353 x 500 mm, 13.9 x 19.7 in|
|B4||250 x 353 mm, 9.8 x 13.9 in|
|B5||176 x 250 mm, 6.9 x 9.8 in|
|B6||125 x 176 mm, 4.9 x 6.9 in|
|B7||88 x 125 mm, 3.5 x 4.9 in|
|B8||62 x 88 mm, 2.4 x 3.5 in|
|B9||44 x 62 mm, 1.7 x 2.4 in|
|B10||31 x 44 mm, 1.2 x 1.7 in|
|C5E||163 x 229 mm|
|Comm10E||105 x 241 mm, U.S. Common 10 Envelope|
|DLE||110 x 220 mm|
|Executive||7.25 x 10.5 in|
|Folio||210 x 330 mm|
|Ledger||17 x 11 in|
|Legal||8.5 x 14.0 in|
|Letter||8.5 x 11.0 in|
|Tabloid||11 x 17 in|
Whenever you use our service to convert web pages or HTML to PDF, you will notice that the PDF is always downloaded from one of OUR subdomains e.g. europe.htm2pdf.co.uk.
In case you’re using the API or the SDK, then this probably will not be an issue for you as you can store the PDF on your server and serve it to your end-users from there. But if you’re using the ‘save as PDF‘ functionality, you may not want your users to know that you’re using an external service – for reasons of your own.
For that reason we offer the ability (at a surcharge) to route your own subdomain to our servers. So if your website is at www.example.com then you could route htm2pdf.example.com one of our serves or load balancers and we would make sure that you can then use a “save as PDF” link to htm2pdf.example.com instead of xxxx.htm2pdf.co.uk.
This functionality was always available for customers with a private server, but now we will also offer it to customers with a regular subscription. Please note that we will quote an installation fee and maintenance fee for hosting your subdomain. Feel free to inquire for details!
Lately we have been getting a lot of inquiries about where we do our actual conversion. These inquiries are mostly related to data protection laws in the jurisdiction of the person or company inquiring about this.
Ever since ‘cloud computing’ has become popular, more and more companies are concerned that it’s no longer clear where their data resides and this has led governments to institute data protection laws that make sure that data is only processed in the area that it’s supposed to be processed. Whoswholegal.com did a really nice post about it here.
Now some time ago we activated servers in Asia and Europe, on top of the servers we already had in the USA. We did this primarily to reduce latency for customers in continents other than the North American continent. But we soon came to realize that it also fulfilled a need to have access to servers, which are sure to be in a geographical area, just for the purpose of data protection.
Therefore we want to clarify in this post what we actually do to ensure that your data is processed in the area that you want it to be processed.
When you register for our service the process is as follows:
- Your subscription data (name, email, plan type, default settings etc) is propagated to all our servers
and access to all conversion servers is immediately granted
- For each of the services that we have, you choose the server that you want to use for the conversions by choosing the right ‘service call’. Your data will only arrive at a server in that geographical location and it will NEVER be shared with any other location. It will also be automatically deleted after a maximum of 2 hours.
Here’s how this works for our different services:
- With the API you can choose the API call that represents the server of choice. In case you’re using a dedicated server or a special shared server, then you use that one. In case you want to use for example our Asian conversion server then you would call the API at http://api.htm2pdf.co.uk/urltopdf (see http://www.htm2pdf.co.uk/html-to-pdf-api)
- When you use our PHP SDK to create PDFs you can use a simple PHP statement to set the server of choice. For example, you can use $pdf->SetServer(‘usa’) if you want to make sure you’re using our American servers.
Hopefully this post has shown you how we make sure your data only goes to the area of choice. Of course this is also valid in case you sign up for an enterprise plan, because we would then discuss the location of your dedicated or shared server with you.
As always, please feel free to reach out with any questions you may have!
Since the first time we rolled out the HTML to PDF API, it has been accepting POST as well as GET requests. But – in all our innocence – we always thought that people would find it easier to use a GET request. Simply because it’s so much more intuitive.
We were obviously mistaken! Now that we’ve added more information in the documentation about HTTP POST, we’re seeing that more and more businesses are making use of it.
A few good reasons to make use of POST instead of GET are:
- Your web server does not need to be accessible for us to crawl, so you can use it for pages in a members area or other secure area.
- You don’t have to create a URL first in case you only want a PDF and not a web page to begin with.
- Your conversion will be faster, because we don’t have to first visit your site and then take the HTML to our site. This basically saves one roundtrip, but can be significant with especially larger files.
Because of these advantages we have also enabled the header and footer parameters to be input as raw HTML. The same advantages apply as above, especially in the sense that you won’t have to be creating a URL first before you can use a header/footer for your PDFs.
If you are looking for more information about this then please refer to the documentation on the API or contact us directly.
At the end of the last year we wrote about our new process of setting you up on an unmetered shared or private server. Before then it always took us a few days to get you completely set up, but now it typically takes one business day or – in cases where you’d like an unmetered account on a shared server that has open spots – a couple of minutes.
In this post we’d like to address the limitations of these different servers and the differences in use compared to our regular plans.
First of all let’s make it clear that both the unmetered shared server account as well as the private server account allow for as many conversions as the server can handle. In the case of the private server you are free to use that capacity however you like and you have 8 cores and virtually unlimited bandwidth at your disposal. You can also ask for multiple private servers with a load balancer if you run an insane amount of conversions, but that’s a different topic.
For the unmetered shared account there are two important limitations. These are basically the same limitations that apply to all our plans i.e.:
- You can only access the server for one conversion at a time. If we’re still processing a conversion for you, you can not request another conversion to start at the same time. We actually prevent you from doing so, by blocking additional incoming connections from the same account during the conversion process.
By doing this we always have enough capacity on our servers to serve the customers that share the server with you.
- Each conversion can take a maximum of 60 seconds to complete. Again, this is to protect other customers against resource hogging on the servers.
Differences in usage compared to regular services
All functionality that’s available in our regular services (such as the HTML to PDF API and SDK) is available to you when you sign up for an unmetered or private server account. So you’ll get access to all of these (as opposed to a singular service). You can choose whichever you want to use.
Other than that you’ll have to call the API and SDK a little different. This is because we’ll give you a different subdomain to use.This is because you can only use the specific server that we reserved for you and not the other general servers.
For the API this means you will not be calling europe.htm2pdf.co.uk/urltopdf?apikey=…. but sharedX.htm2pdf.co.uk/urltopdf?apikey=….
For the SDK you will be setting the subdomain by calling $pdf->SetServer(‘sharedX’); if sharedX is the subdomain that we assign to you.
I hope it helps you understand how easy the whole process is and what you need to do to get up and running. If your company wants to outsource the HTML to PDF creation process and wants to be sure it’s done professionally – then get in touch or sign up!
The team of HTM2PDF would like to wish you and your loved ones a great New Year and we hope that you’re having wonderful holidays!
You can rest assured that in the new year we’ll be trying our best to improve our service even more and stay ahead of the pack with new features, speed improvements and great customer service.
Like we hope that you convert into the new year successfully, we’ll make sure to keep converting your HTML into PDF successfully!
Have a good one!
Wow – this has been an exciting week! We’ve managed to setup a really fast server setup process in our company. The result is faster delivery of a custom server to you than ever before!
Of course regular users have always been able to get instant access to our services upon sign-up. This was always one of our greatest assets and still is. It takes literally 2 minutes to sign up and start converting!
But now there’s good news for customers, who would like to have unlimited access to our services. We already offered custom services on request (and still do), but now we have added two standard umlimited packages to our portfolio:
- unmetered package
With this package you will be set up on a server, which you share with a maximum of 4 other umetered accounts. You can choose between servers in Asia, Europe and the USA and you can have access within one business day and often within a few hours of receiving your request.
Restrictions are only that you can not convert documents that take longer than 60secs to process and that you are competing for resources with other customers (if any). These servers run with 8 CPUs and can easily handle thousands of conversions a day.
- private server package
With this package you will get your own VPS and subdomain on htm2pdf.co.uk, where you will unlimited access to all our services. You can choose between servers in Asia, Europe and the USA.
VPS requirements can be tailored to your needs as well as an SLA if needed. This package can also be delivered in one business day. For this package we can also discuss hosting in different locations than just the ones offered by our default hosting partner.
It still remains possible to add custom features and special requests. So hopefully you’ll find this addition just as exciting as we do!
If you have questions about these possibilities – send us an email!
Today we’re pleased to announce that we’re doing more performance improvements to our systems, which we’ll be rolling out over the next weeks. As always, we look forward to your feedback if you have any.
One of the things we’re doing is very good news for our HTML to PDF SDK and API users. We’re going to split our servers over two locations and will allow you to choose where you use your resources.
Although our conversion service is one of the fastest (if not the fastest!) conversion services out there, this will especially help you if are converting huge files. Not so much because of the conversion process itself, but mostly because you will reduce latency because we’ll be serving the resulting PDF from a closer location. Our own measurements show that depending on your location you may expect quite dramatic improvements.
Precise implementation details will be announced on our blog and the documentation pages as soon as we have tested all the implementations ourselves and with our beta-test users.
We’re also considering acquiring servers in the Asia region. If you have any other suggestions related to performance improvements – please contact us!
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!