Home » Programming » Archive by category "BlitzMax"

Convert HTML to PDF with HTML2PDF Web Service

HTML2PDF Web ServiceRecently I launched my new product HTML2PDF Web Service — a web service for converting HTML to PDF.

In this post I’d like to talk about HTML2PDF Web Service. Why to choose it, how to use it and what technologies were used to create it.

Why Choose HTML2PDF Web Service?

Programmatically generating PDF documents is a painful and time consuming problem that neither makes your developers nor designers happy. With HTML2PDF Web Service you can design your invoices or reports in HTML, style them with CSS and convert the resulting page into a PDF document. Using HTML2PDF Web Service saves your developers and designers time which is better spent making your product better.

Say your web application or mobile app (or any application for that matter) needs to generate invoices or reports in PDF format. Unless you can install special HTML to PDF conversion software you’re probably stuck with some of the libraries available for your language that can programmatically generate PDF documents. To do this you would probably design your document in something like MS Word, LibreOffice Writer or perhaps HTML. After this design has been approved you can start programming your PDF module; setting up coordinates, font sizes etc. And then all of the sudden you notice your library has limited support for doing actual document layouts and presenting tabular data that can span multiple lines. Now you need to write your own routines for splitting text over multiple lines, keep track of coordinates and make sure nothing overlaps. If like me you’ve already been there, it’s quite the nightmare.

So being able to design in HTML, style with CSS (heck, even use a bit of JavaScript) and convert the resulting page to PDF would speed up this process a lot. Am I starting to tickle your interest?

How to use HTML2PDF Web Service

Simply create your soon to be PDF documents in HTML, style them with CSS and if wanted you can use JavaScript as well. The final document is best previewed in a WebKit based browser such as Google Chrome, since that’s the technology HTML2PDF Web Service uses in the background to render the HTML and convert it to PDF.

Here are some examples on how to call the web service. Converting HTML to PDF is easy with the HTML2PDF Web Service. You can pass an URL to the page you want to convert or either send the HTML code with the request.


$ curl -H "X-API-Key: F8802062-4D31-11E3-8F59-BFD4058B6BFF"
       -H "X-API-Username: MyUsername"
       -d '{"content":"<html><head><title>My page</title></head><body><h1>Hello World!</h1><p>I am an HTML page converted to PDF!</p></body></html>"}'
       https://html2pdfwebservice.com/api/convert > page.pdf


#!/usr/bin/env perl
use strict;
use warnings;
use Mojo::UserAgent;

my $ua = Mojo::UserAgent->new;
my $tx = $ua->post(
    'https://html2pdfwebservice.com/api/convert' => {
        'X-API-Username' => 'MyUsername',
        'X-API-Key'      => 'F8802062-4D31-11E3-8F59-BFD4058B6BFF'
    } => json => {url => 'http://domain.com/invoice.html'}
if (my $res = $tx->success) {
    my $pdf_data = $res->body;


require 'net/https'
require 'uri'

uri           = URI.parse('https://html2pdfwebservice.com/api/convert')
https         = Net::HTTP.new(uri.host, uri.port)
https.use_ssl = true
# In case the SSL certificate isn't accepted
https.verify_mode = OpenSSL::SSL::VERIFY_NONE

req = Net::HTTP::Post.new(uri.path)
req['X-API-Username'] = 'MyUsername'
req['X-API-Key']      = 'F8802062-4D31-11E3-8F59-BFD4058B6BFF'
req.body              = '{"url": "http://domain.com/invoice.html"}'

res = https.request(req)
if res.code == '200'
    pdf_data = res.body
    # - or write to file -
    # File.open('invoice.pdf', 'w') { |file| file.write(res.body) }


$settings = array(
    'url' => 'http://domain.com/invoice.html',

$curl = curl_init();
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, json_encode($settings));
curl_setopt($curl, CURLOPT_HTTPHEADER, array(
    'X-API-Username: MyUsername',
    'X-API-Key: F8802062-4D31-11E3-8F59-BFD4058B6BFF'

curl_setopt($curl, CURLOPT_URL, 'https://html2pdfwebservice.com/api/convert');
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
// Helps to debug in case of issues
// curl_setopt($curl, CURLOPT_VERBOSE, 1);

// In case the SSL certificate isn't accepted because of outdated certificates
// on your server
curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, false);

$res = curl_exec($curl);
// Save PDF to disk
file_put_contents('document.pdf', $res);

Technologies used to develop HTML2PDF Web Service

The most interesting part in developing HTML2PDF Web Service was choosing which technology to use for converting HTML to PDF. After doing research on the subject and testing several solutions I eventually went with a WebKit based solution. By using WebKit it’s easier for the end user to preview their document using a WebKit based browser.

The HTML to PDF conversion server was developed using Go. Go is a fun language to program with, does concurrency in a really nice way and can produce a native executable for Linux, OS X, Windows and some other platforms. Thanks to Go the conversion server is fast, snappy and low on memory and CPU usage. Being able to create a binary executable allows me to sell the conversion server as a standalone product as well.

To get access to the web service there’s also a web application which is written in Perl. My favorite web framework of choice has become Mojolicious for quite some time now and thus HTML2PDF Web Service has been written with it. DBIx::Class has been used for database interaction and Validation::Class is used to validate all user inputted data.

Used databases are PostgreSQL and Redis. The former is used to store user accounts, subscriptions and more. The latter is used to keep track of token usage per user.

Sign up now for a free trial

If after reading all this and you’re still reading, please do sign up for a free trial. The trial gives full access to all the features of the web service so if you like it, please consider buying a subscription.

In case of any questions, please do contact me either through the comments on this page or send an e-mail to support at support@html2pdfwebservice.com.

Monkey re-branded to Monkey X and comes with Desktop target

Monkey by Blitz Research Ltd has been re-branded to Monkey X. Monkey X focuses on multi-platform and multi-device game development. Monkey code translates to the language used by the platform. Javascript for HTML5 games for example and C#/XNA when targeting Xbox 360. Supported platforms are Windows, Mac OSX, Linux, Flash, HTML5, iOS, Android, WP7/8, Xbox 360 and more. Ouya as well!

With the re-branding also comes a new free version. Before, the free version only supported the HTML5 target but now also includes the desktop target. Other targets can be acquired by purchasing a Monkey X Pro license.

Now that the desktop target is freely available as well I think I’ll go give Monkey a try soon. I haven’t used BlitzMax in ages (and I consider it a dead end as well) and since Monkey is very similar to BlitzMax I don’t expect too much trouble to get adapted to it.

Maximus has been taken down

As of today Maximus, the BlitzMax Module Manager, has been taken down. I’ve blogged about this some time ago and today I’ve decided it was finally time to go through with it. The website now redirects to the GitHub organization that hosts the code for the client and the website. These will still be available online of course.

So what does this mean for Maximus and BlitzMax?

  1. The Maximus client can no longer fetch the sources file from the Maximus website and thus it can no longer download modules from the website as well. You’re back to downloading and installing BlitzMax modules manually yourself. If you’ve got a Maximus webapp instance running somewhere you can however configure the client to use the sources file from there.
  2. Development on both the client and webapp had stopped some time ago, but I would still fix bugs if they popped up. With the cancellation of the hosted webapp this also means I won’t be doing any development on Maximus anymore.
  3. With the source code being available anyone is free to host their own Maximus instance. Since the webapp uses Vagrant and Puppet you should be able to get a local instance running quickly. There’s also an INSTALL file for manual installation on Ubuntu.

Developing Maximus and providing this service has been a fun ride of which I’ve learned a lot and resulted in a well crafted piece of software. I can however no longer provide the service and support it and so it’s time to move on. I want to thank everyone who has supported Maximus in any way possible. Thanks.

I’m now a freelance developer

To my surprise I hadn’t even announced here that I have recently started freelancing! As of August the 1st I now operate under the name Kras IT and am available as a freelance developer. Since it’s now the 1st of September this means I’m already in business for a month now which has been exciting. I’ve been with my previous employer for almost 7 years and after a lot of thinking and planning I decided to take the leap!

As a freelance developer you can hire me for all your PHP and Perl work. I mainly do webdevelopment but I do a lot of backend as well. Aside from that I also enjoy configuring Linux servers. I personally think being able to configure and optimize both your app and the server(s) the app is running on can be a great asset, as it gives a lot more insight in the overall workings of your software.

Aside from doing freelance work I also plan on doing product development. I’ve got a few ideas in the pipeline of which one I expect to launch within 5 months. I’m likely to blog about this in the near future as well as about freelancing and running your own business.

For a full list of skills you can take a look at my website at Kras IT. Currently the website is still Dutch only but my LinkedIn and résumé are in English. Do you’ve got any questions or are in need of a freelance developer? Feel free to contact me!

Server provisioning: my experience with Puppet and Chef

Server provisioning tools such as Chef and Puppet make it easy to automate installation and configuration of your servers. I’ve used both now in two projects where they provisioned my virtual servers built with Vagrant.

I’ve first heard of Chef and Puppet when I started using Vagrant. With Vagrant you can quickly get a virtual server up and running for your project. In its most basic form Vagrant can execute a shell script in which you setup your server. Because this is a bit limiting it’s interesting to look into a more automated provisioning process.

Just over a year ago I started using Vagrant for Maximus and after giving both Chef and Puppet a quick review I decided to go with Puppet. At the time I thought it looked easier to use and it had lots of modules available for installing software.

Earlier this week I decided to add Vagrant to a new project of mine: a small and simple CRM system which is adapted to my workflow, and decided to give Chef (Solo) a try. At first Chef looked like a lot more hassle than Puppet, but that’s mainly because you start off with a big chef directory just to get started and cookbooks have a folder hierarchy of their own as well. In contrast, with Puppet modules basically have a files, manifests and templates directory.

If I compare my experience between Puppet and Chef I had more trouble setting up my Puppet manifests than I did setting up my Chef cookbooks and recipes. I’ve found Chef cookbooks easier to use than Puppet modules. Mainly because configuring software with Chef seemed a lot easier. Maybe that’s because the available Chef cookbooks actually provide this functionality as it seemed totally absent in most Puppet modules I’ve come across. Maybe it was there but I couldn’t find it. That’s another thing, the Chef cookbooks seem to be better documented than the Puppet modules I’ve seen. One thing I do like about Puppet is that you can define dependencies between every step or command you want to run. I’m not sure if Chef supports this as well.

Just to make clear, my experience with Puppet and Chef is limited and I currently don’t use it to provision servers used in production (at least not yet, but I’m sure that’ll change in the future). This is just based on my experience. If you’re interested in these tools I suggest you try them both to see what it’s all about. They both have a solo/standalone version which doesn’t require a main server where your cookbooks or modules are stored.

One great resource of getting started with Chef can be found at Christopher H. Laco’s website.