Posted by & filed under Service announcements.

All our private server plans are hosted on the Linode network. This is one of the biggest cloud hosting providers in the world and is well know for it’s speed and reliability.

Our main site is hosted in London (UK), but for our license holders we offer access to servers in Asia (currently Tokyo) and the USA (currently Atlanta) as well.

Since we regularly get requests to host private servers close to the data centers of our clients, we’d like to update you with the full list of locations that we can currently host in (easily):

  • USA:
    • Newark
    • Atlanta
    • Dallas
    • Fremont
  • United Kingdom: London
  • Germany: Frankfurt
  • Asia:
    • Singapore
    • Tokyo

If you want to know which location would be most suitable for your private server, then you can do a speed test here.

You are also welcome to reach out if you want us to setup hosting in a different location with a different provider.

Posted by & filed under HTML to PDF conversion, HTML to PDF SDK, Save as PDF.

Some of our users have asked the following question over time:

How can we create a ‘save as PDF’ link, without showing that we are using the HTM2PDF service to generate the PDF?

This question is typically asked by companies that like the simplicity of our ‘save as PDF’ links, but want to keep the user on their website or at least show that the link goes to their website.

Now this can be realized very easily in one of (at least) two ways, which are:

  1. We host our service on one of your subdomains. We can easily do this (for a fee) if you point the DNS entry that subdomain to the server that we will use for your service. This allows you to use the exact same functionality as we already offer, but then instead of linking to http://www.htm2pdf.co.uk/display you link to http://yoursubdomain.yourdomain.com/display.
  2. You create a simple script, based on the API or SDK, and link your ‘save as PDF’ link to that script on your server. The advantage is that this costs you nothing and that you have full control over the parameters that you want for the ‘download as PDF’ link. You can even use parameters that we don’t have in our ‘save as PDF’ functionality, but do have in the API / SDK!

The script that we describe as the 2nd option can be VERY easily created with the examples that we already have on our website (see API examples or SDK examples). Below we’ll show you how you can create a script that takes the ‘orientation’ parameter and the ‘page_size’ parameter. Note that we use ‘HTTP_REFERER’ value. This is the most important trick in the script: it takes the refering page and that’s what we typically like to convert to PDF. Of course you can add a ‘url’ parameter or any other parameter as well in a similar manner.

require 'htm2pdfapi.php';

if (isset ($_SERVER['HTTP_REFERER'])) {
$url = $_SERVER['HTTP_REFERER'];

try {
$pdf = new Htm2PdfApi ($userid, $apikey);

if (isset ($_GET['orientation'])) {
$pdf->SetPageOrientation($_GET['orientation']);
}
if (isset ($_GET['page_size'])) {
$pdf->SetPageSize($_GET['page_size']);
}

$pdf->CreateFromURL ($url);
$pdf->Display();

} catch (Exception $error) {
echo $error->getMessage();
echo $error->getCode();
}
}

With this simple script you’ll be able to utilize all the parameters from the API or SDK, link to your own site and add any features you want.

You could also add caching very easily, by saving the PDF on your local server and serving the saved PDF as long as your page has not been changed. This will serve the PDF to your visitor a lot faster and will also save you costly credits on your plan!

We hope this helps – please reach out to us if you have any questions!

Posted by & filed under HTML to PDF conversion, HTML to PDF SDK, PDF tooling.

Some time ago we wrote a post about how to convert an entire website to PDF by using our conversion service. In this post we’ll show you some sample code that you can use when you’re coding in PHP.

In PHP you can use our full-blown web to pdf sdk, which allows you to easily set your preferences, convert your pages and then merge them together into one large PDF. Before you start doing this, you should figure out a way to get all the pages of your website in a list. There are various tools on the web out there, some of which create an XML sitemap for example.

After you’ve decided which pages you want to convert you’ll basically put them in an array and then loop over these to convert them. As a last step you’ll then all merge them together.

Your code will then look something like this:

// initialize the service
$pdf = new Htm2PdfApi ($userid, $apikey');

// now set some options
$pdf->SetPageSize('A4');
$pdf->SetPageOrientation('Portrait');

// create an array with the URLs you want to convert
$urls = array (
'http://www.example.com/',
'http://www.example.com/page1//',
'http://www.example.com/page2//',
'http://www.example.com/page3//',
'http://www.example.com/page4//',
);

// convert all these URLs one by one
foreach ($urls as $url) {
$pdf->CreateFromURL ($url);
}

// merge them all together and save them as one PDF!
$pdf->MergeFromCache (count($urls));
$pdf->Save('/home/website.pdf');

This should help you on your way! Of course if you don’t want to go through the trouble of doing this yourself, especially if you have a large website and you don’t know how to find all the pages – just contact us for a quote as we’ll be happy to do it for you!

Posted by & filed under HTML to PDF API, PDF tooling.

We’d like to think that our pages have lot of examples to work with. The SDK is fully explained and, since it’s a complete library, there’s no reason for you to write any code yourself when you use that.

The HTML to PDF API page also has plenty of code examples and we’d like to think we’re very complete in the amount of programming languages we give examples in. All the major languages such as Java, C#, PHP, Perl and many more are explained.

But now we’re calling out to you to contribute MASHUPs. We’re really looking forward to hear what kind of code you’ve written for yourself around our conversion service and how you’re using it. And not just for us, but also for all our other users!

If you have a mashup or maybe even a custom library or class to show for, then please send it over! Of course we’ll properly attribute your contribution and maybe we can even work out some contribution of our own in return!

Posted by & filed under HTML to PDF conversion, PDF tooling.

Recently we’ve been receiving more requests for a complete website to PDF conversion. These needs typically arise when companies want to have an archived version of their website or use a PDF as a catalogue version or due to other reasons.

Both our API and SDK have long been supporting this functionality, but we’ve never really explicitly written about it before. The reality is that you can use the merging functionality to easily accomplish this. Basically you just run each single page through the API or SDK consecutively and then follow that up with a merge command and you get your full PDF.

Since there are companies out there that don’t want the hassle of doing any coding themselves, we are currently in the process of automating this entirely. The process will allow you to send us a list of links or a sitemap, plus a specification of the page layout and we’ll then return you a link to the PDF for download. Since it can take quite a while for big websites, we will most likely offer this in a form where you will get the link over email once the process is ready.

If you have any wishes for this process yourself or if you want know more about the status of this implementation, then please reach out to us.

Posted by & filed under HTML to PDF conversion.

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.

Posted by & filed under HTML to PDF API, HTML to PDF conversion, Save as PDF.

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.

Page formatDimensions
A0841 x 1189 mm, 33.1 x 46.8 in
A1594 x 841 mm, 23.4 x 33.1 in
A2420 x 594 mm, 16.5 x 23.4 in
A3297 x 420 mm, 11.7 x 16.5 in
A4210 x 297 mm, 8.3 x 11.7 in
A5148 x 210 mm, 5.8 x 8.3 in
A6105 x 148 mm, 4.1 x 5.8 in
A774 x 105 mm, 2.9 x 4.1 in
A852 x 74 mm, 2.1 x 2.9 in
A937 x 52 mm, 1.5 x 2.1 in
B01000 x 1414 mm, 39.4 x 55.7 in
B1707 x 1000 mm, 27.8 x 39.4 in
B2500 x 707 mm, 19.7 x 27.8 in
B3353 x 500 mm, 13.9 x 19.7 in
B4250 x 353 mm, 9.8 x 13.9 in
B5176 x 250 mm, 6.9 x 9.8 in
B6125 x 176 mm, 4.9 x 6.9 in
B788 x 125 mm, 3.5 x 4.9 in
B862 x 88 mm, 2.4 x 3.5 in
B944 x 62 mm, 1.7 x 2.4 in
B1031 x 44 mm, 1.2 x 1.7 in
C5E163 x 229 mm
Comm10E105 x 241 mm, U.S. Common 10 Envelope
DLE110 x 220 mm
Executive7.25 x 10.5 in
Folio210 x 330 mm
Ledger17 x 11 in
Legal8.5 x 14.0 in
Letter8.5 x 11.0 in
Tabloid11 x 17 in

 

 

 

Posted by & filed under HTML to PDF conversion, PDF tooling, Save as PDF.

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!

Posted by & filed under HTML to PDF API, HTML to PDF conversion, HTML to PDF SDK.

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!

 

Posted by & filed under HTML to PDF conversion.

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.