DocRaptor

DocRaptor Blog

Tips and tricks for our HTML to Excel and PDF API

  1. Archive
  2. Categories
  3. RSS

Gone in 60 Seconds: How We Moved From Linode to AWS With Less Than a Minute of Downtime

Recently we moved DocRaptor from Linode to AWS, increasing average document creation speed by 6.9%, reducing network errors by an incredible 84.1%, and saving ourselves a ton of devops time related to scaling. Our move to AWS also allowed us to double our simultaneous request limit, scale up to meeting customer demand in a matter of minutes instead of hours, and gave us more time to help you create the documents you need.

DocRaptor is an infrastructure service, so our customers expect us to be up and creating PDFs and Excel docs at all hours. When we had datacenter issues 2 weeks in a row with Linode, we knew it was time to switch. We thought through all the details that needed to be accounted for, and started working on a migration plan. Over the course of a few weeks this plan solidified, and we scripted portions that could be automated.

The week before the migration we ran through the whole plan a few times, only excluding steps that would actually break production. This revealed a few small things that we missed, and highlighted a few more things we could automate, but mostly gave us confidence that our plan was going to work.

Even though we were migrating from Linode to AWS, most of our plan is data center agnostic, and we hope anyone who is thinking about migrating data centers will benefit. Here’s a step by step account of what our data center migration from Linode to AWS looked like.

Minimizing Downtime

One of our core goals for this migration was keeping customer impact low, and we spent a bunch of time planning to make our window of downtime as small as possible. We achieved this by breaking the migration down into several smaller, easily reversible steps, as well as having many tests along the way to verify that we were able to move from one step to the next with confidence. This careful approach allowed us to fully migrate DocRaptor from Linode to AWS with less than 60 seconds of downtime.

Testing AWS

We needed to verify that DocRaptor was setup and configured correctly in the new data center. We began by making a ton of documents on AWS and verifying these documents came out perfectly. We take customer privacy very seriously, so it was important to implement document verification in an automated way so even we didn’t need to manually inspect every document to verify it looked good.

Luckily most of the documents we generate produce the same binary file when generated multiple times (excluding a randomly generated id field in the PDF). This allowed us to verify AWS was working correctly on most documents, but there were a handful with different binary files. We needed to know why these documents were different, so we did some science.

Verifying Document Creation

DocRaptor stores a log of your document generation so you can get more detail if you run into issues. The reason we saw a few identical documents with differing binary files was minute differences in asset loading. Sometimes a customer has network or asset loading issues. Obviously if an image or a remote font fails to load the resulting documents are going to differ. This meant that we actually needed to test the variation within both systems, and compare those in order to know that AWS was performing at least as well as Linode.

Fortunately for us there are automated visual comparison tools. ImageMagick has a great tool called Compare that accepts two input images and returns a number indicating how similar the two images are (PHASH). Here you can see an example of an image diff using different font options from our example invoice on our try it out page.

Image diff using Compare

This technique allowed us to set a threshold, automatically run PDFs through Linode and AWS, convert them to images, and compare the PHASH values to our threshold. We sampled a huge number of customer documents and ran this comparison process on all of them. Because customer assets sometimes vary from request to request, we made our comparison more statistical by running the same document through both Linode and AWS multiple times, then checking the variation within each group.

Lo and behold, this finally gave us the confidence we were looking for that AWS was generating great looking documents, but what about when DocRaptor doesn’t produce a PDF or Excel document?

We still needed to verify that invalid input was handled the same between the AWS and Linode clusters. DocRaptor produces helpful error messages on a variety of invalid inputs such as document timeouts, invalid html, and javascript timeouts. While running documents through both services, we compared the error messages returned and verified that they were the same.

This was a great opportunity to gather statistics on how long it took to generate these documents, as well as any network errors that occurred. This experiment proved that on average we were producing documents 6.9% faster on AWS, with a whopping 84.1% fewer network errors!

6.9% faster

84.1% fewer network errors

Automating Our Infrastructure

DocRaptor is a complex system with a ton of moving parts. Different tools are required to do HTML parsing, Javascript execution, font handling, and PDF or Excel generation itself. We’ve been successful until now by cloning servers with the same configuration, but this method has quite a few downsides. Each new server still required some manual setup. We also didn’t clearly document and codify our setup procedure for each new server. As anyone who’s written software before knows, manual steps are a recipe for problems. It was time to fully automate our app setup!

Automating from scratch can definitely be a hassle, but we had already automated many of the big components thanks to our recent infrastructure work on Gauges and Instrumental. We’ve automated the setup and deployment of those apps using a combination of self written scripts and Puppet. We just had to add DocRaptor specific setup to our automation.

With very little effort we were able to spin up a whole new cluster, including web servers and background worker servers. Using a combination of Puppet scripts and Capistrano tasks we were able to reduce the spinup of a new server (or even a completely new cluster) to a matter of minutes. This work has already helped us test new code internally by making it incredibly easy to spin up a new server to use for testing.

Migration details

Below we’ve broken down our migration plan into sections with some explanation of each step. Want to check out our entire migration plan? We’ve added a link to a gist at the bottom of this post.

Estimated total time to execute: 2hr not including pre-replication

Ensure performance test make_doc script has production endpoint

Comment out deploys tests, DO NOT COMMIT

To ensure updates that we make to DocRaptor don’t cause issues we have a set of tests that run against production after every deploy. For this migration, however, we tested out of band in order to make deploys faster and limit any downtime.

Setup SSH tunnel between AWS background-001 to Linode MySQL
Replicate Linode MySQL to AWS (3hr+) as docraptor-production
One-time copy non-queue Redis data
Verify AWS endpoint working
  ./script/service_test http://aws.docraptor.com && ./script/service_test https://aws.docraptor.com

We’re using automated tests here to verify everything is working correctly.

-- Wait Till Day of Maintenance --

Tweet: Reminder: we'll be doing maintenance from 2-3pm EDT today.

Definitely wanted to keep all of our customers informed and post notice just in case there were issues.

Connect AWS to Linode MySQL
  Fallback: (AWS BRANCH) cap production resque:stop
Verify AWS endpoint working
  ./script/service_test http://aws.docraptor.com && ./script/service_test https://aws.docraptor.com

Here we pointed both AWS and Linode servers to our Linode mysql instance so everything was using the same persistent data store. Note that our fallback is one simple command that runs very quickly. If the verification test had failed there would only have been a few seconds of downtime at this point and we could then investigate and resolve at our leisure.

Mysql switch

Switch to old Instrumental API key in app and automation
  be sure to restart instrument_server

Up until this point we had AWS connected to a test application monitoring project so it didn’t conflict with the DocRaptor production monitoring data. Since AWS was now using the main persistent store we want all our data in one place.

Start continuous testing against production endpoint
Direct Linode LB to AWS ELB for 10 seconds
  Verify production traffic hits Linode
  Update Linode LB config to point to AWS
  Verify production traffic hits AWS
  Verify queued jobs in AWS
  Update Linode LB config to point back to Linode
  Verify production traffic hits Linode
  Verify queue draining on AWS

  Fallback: Manually move some jobs from AWS -> Linode Redis
Stop continuous testing (TODO: COULD BE MOVED LATER)

Here we’re running a small amount of production traffic through AWS using nginx as a proxy. This allows us to test AWS connectivity between all servers other than mysql and verify documents continue to be processed. In our configuration we had two different queues: one in Linode and one in AWS, so enqueued documents would automatically drain out of the old queue as they were worked. We also switched from Passenger to Unicorn as part of the migration, so we used that fact as a quick additional check to verify which service was actually handling requests. Again, fallback is easy, and in fact this entire step is basically a practice fallback for the next step.

Direct Linode LB to AWS ELB permanently
  cp /opt/nginx/conf/nginx.production.lb.conf.new /opt/nginx/conf/nginx.production.lb.conf
  /etc/init.d/lb_nginx configtest

  /etc/init.d/lb_nginx reload
  curl -I http://docraptor.com | grep Pass  # should be empty
  curl -I https://docraptor.com | grep Pass # should be empty and no ssl error
  Fallback: Same as the 10 second one above
Verify production endpoint working
  ./script/service_test http://docraptor.com && ./script/service_test https://docraptor.com
Verify no traffic hitting Linode app servers
Verify Linode Resque is drained
Make a new branch of aws_migration
  with AWS MySQL + Port
Deploy out-of-band AWS app instance pointed at AWS MySQL
  # uncomment, DO NOT COMMIT web-oob enabled!!!
  cap production deploy HOSTFILTER=web-oob.docraptor.com
  # recomment web-oob so we do not deploy it in the next steps
  # verify connection to correct MySQL:
  eb ssh web-oob.docraptor.com
  /data/docraptor/current/script/rails runner 'User.last; puts `lsof -i -p #{Process.pid}`'
Deploy AWS MySQL with pause to AWS instances
  cap production deploy deploy:web:enable
Clear failed jobs on Linode

We’ve verified that production traffic is handled correctly through AWS, so we’ll start forwarding all traffic through AWS. In order to minimize downtime we spun up a new out-of-band server that ran the new AWS-only code (web-oob), but didn’t add it to our AWS load balancer. This will allow us to later run tests against AWS without waiting for new code to be deployed to the AWS web servers. Another optimization to note here is the deploy of the new code to the in-band AWS servers has code to pause right before restarting the DocRaptor services. This is another way we kept downtime low, by essentially decreasing the “deploy time” to only as long as it takes to restart Unicorn and Resque.

Stage and switch using out-of-band server

-- Must Be In Maintenance Window --

Enable maintenance mode in PagerDuty
  Pingdom
Tweet: We're starting maintenance now, you may see intermittent errors over the next hour.
Run dc_switch cap task
  cap production dc_switch
  Fallback: is automatic
Continue paused deploy
  Issue?: cap production deploy:restart
Verify no passenger
  curl -I http://docraptor.com | grep Pass   # should be empty
  curl -I https://docraptor.com | grep Pass # should be empty and no ssl error
Verify production endpoint
  ./script/service_test http://docraptor.com && ./script/service_test https://docraptor.com
Requeue failed jobs
Stress test (10min)
  ./script/performance.rb old 1000000 pdf small | tee -a tmp/performance-old-pdf-small-final-switch.log
  Fallback: switch Linode LB to point to Linode apps (will lose data)
Wait a safe period (1hr?)

-- Maintenance Complete --

This is the only part of the migration where there is downtime. We need to switch which mysql instance we’re using, and we want to ensure replication has caught up when we do so. We inform customers that the maintenance window is beginning. We codified the majority of the actual switching procedure in a capistrano task called dc_switch, which allowed us to fail back to Linode very quickly in the case that anything went wrong.

Disable maintenance mode in PagerDuty
Tweet: Maintenance complete! Please enjoy your regularly scheduled document service :)

Scheduled maintenance is complete! Party Time! Everything below this point doesn’t have to be done immediately, so the pressure is off. Whew!

Enable cloudfront
Move cron jobs from Linode to AWS
Remove out-of-band server and cleanup cap tasks
Remove deploy pauser
Enable gitflow
Switch DNS
Wait at least 48 hours
Move any outstanding temporary storage files
Shutdown linode non load balancer boxes
Possibly wait more
Verify no traffic hitting Linode load balancers for 1 day
Shutdown Linode
Remove Linode boxes from AWS security groups

And there you have it, a sub-60-second downtime data center migration!

Want to check out our full migration plan? Here’s a gist we put together while working on our data center migration.

Data center migration is always a nerve wracking process, but by carefully planning and limiting your chance for downtime you can have a much less stressful time.

Our New Help Request Feature

Let’s talk about our new help request feature!

Here’s what a typical support request chain looks like: a user has a problem, and emails support. We receive the email, then request extra information, usually a doc log ID and the input HTML. The user provides this information, and then we can start solving the problem. This means a lot of back and forth emails between a user and a friendly dinosaur.

We wanted to simplify this support process, and make it easier for you to send us the information we need to help troubleshoot a problem document.

Setting “help” to “true” when you make your POST request automatically opens a ticket and sends us your document log, input HTML and generated document. You’ll get a confirmation email, and we’ll be able to start working on your ticket a lot more quickly.

Here’s our documentation for making a help request.

Don’t worry - you can still contact us the old fashioned way if you prefer. We love talking to you guys!

Retinafy Your Olark Attention Grabber Image

DocRaptor added Olark as a means of support a couple months back and it has been really great for talking to our new customers and existing customers. With the onset of mass availability of retina devices, we also went through our entire site and upgraded all our assets to look good on the devices of today. If you’re interested how to do that, check out Thomas Fuch’s Retinafy book. Unfortunately one thing that didn’t look that great was the Olark attention grabber (the little DocRaptor icon you see in the lower right of your screen, unless you closed it).

So if you’re in the same boat as us and want your customer support to look as good as the rest of your site, here are the steps you might take. Let’s start with an image. Let’s say I have a 100px x 127px version of that uploaded to Olark and my attention grabber settings are set correctly. By default I will get something that looks like this:

small alien image

You can immediately the aliasing difference between the alien image vs. the text and chatbox element. We want to fix that. The relevant details of this are explained a little more on this page about attention grabber customization. We have to combine that with a little custom CSS to override the default background styles. Note this will also allow you to set different images for when you are available for chat and not. Liquid error: No such file or directory - posix_spawnp

Liquid error: No such file or directory - posix_spawnp

In the end, we get something that looks much nicer: small alien image

Caveats: This will not work on older browsers (IE8 and below, for example) due to no support for background-size.

Making Printable PDFs Just Got Easier

We’ve recently made some changes to DocRaptor that make it much easier to generate easily printed PDFs: fully customizable crop marks and transparency support for TIFF images!

You can now completely customize the length and offset of your crop marks, allowing you to create a trim area on each PDF that will match printer specifications exactly. Custom dimensions for crop marks are set using two new CSS selectors: prince-mark-length and prince-mark-offset.

TIFF files with transparency are supported now, in both CMYKA and RGBA color.

Let’s take a closer look at how you can use these features when generating PDFs!

A PDF with customized crop marks

The default length of crop marks is set to 24pt, and customizing this value with CSS is easy. The syntax looks like:

prince-mark-length: length

Here’s a sample rule, setting the length of crop marks to 30pt:

@page { prince-mark-length: 30pt; }

Not surprisingly, customizing the distance between your crop marks and your trim box is easy, too:

prince-mark-offset: auto | [ length ] {1..4}

A sample integration might look like this, setting the offset between crop marks and the page to 6pts:

@page { prince-mark-offset: 6pt; }

You don’t have to do anything fancy with CSS to add transparency support for TIFF files. Transparency is set when you create the TIFF file, and DocRaptor will respect your wishes when you send the HTML document our way.

We created a sample PDF with customized crop marks to show you how this looks. This PDF also shows off transparency support for a TIFF file, and you can grab the source HTML for this generated PDF.

We’re always working to improve DocRaptor, so keep your eyes peeled for more feature updates!

A Better Dashboard, Part I - Your Document Usage

Tracking how many documents you’re making just got a lot easier! We’ve been overhauling the design of our user dashboard, and we’re excited to talk about how these changes can help you. Let’s get started by taking a look at your usage page!

More useful document generation stats

If you guys like meters and charts, I’ve got great news for you. In the upper right you’ll see a bar showing how manydocuments you’ve made this month. Below that, we’ve got more meters tracking how many production and test documents you’ve created, and how close you are to your monthly capacity. Don’t worry - you’ve still got unlimited test documents.

Track your monthly documents

We wanted to make it easier for you to track how many documents you create in a month, as well as exposing how many test and production documents you make in a month. This graph lives below your monthly tracking meters, showing what your daily document creation looks like.

We hope you guys love the changes we’ve made to your dashboard as much as we do! What could we add to make your dashboard more useful? Let us know!

This is the first in a series of blog posts that will dig into our user interface changes and how you can use them to geneerate better looking documents with less trouble than ever before. Same great PDF and Excel generation service, fresh new coat of paint.

Stay tuned for the next post in this series, when we talk about the improvements we’ve made to your document logs page!

Convert HTML5 to PDF with DocRaptor!

DocRaptor is now running Prince 9.0 in production, which adds full HTML5 support, better CSS3 support and faster Javascript. Many of our users have asked about support for HTML5 (the canvas element in particular) and we’re excited about this update.

All new accounts will default to using Prince 9.0. If you’re an existing user and you’d like to add HTML5 elements to your PDFs, you’ll need to log in and update your default Prince version setting. You can find this option under “Edit Profile” in your Account Dashboard.

Selecting Prince 9 as your default

Be aware that updating your Prince version may break your existing styles, and you may need to do a bit of tweaking to get HTML5 elements working with templates created prior to this update. Don’t worry! You can test Prince 9.0 by setting this optional parameter when creating a PDF: Prince Version

While support for HTML5 and the canvas element are the most exciting parts of this deploy, Prince 9.0 is a big update and brings a lot of new features and bug fixes to our service. You can read through the entire change set here:

Prince 9.0 change set

Want to see what kind of output you can expect with DocRaptor? Take a look at some sample documents on Prince’s website:

Sample generated PDFs

As always, let us know if you run into any problems, or need a hand!

Running Javascripts Before Generating PDFs

So maybe you want to use Javascript to spice up your PDFs prior to generating them. Many of our users need to generate PDF documents with more complicated output than HTML and CSS support. DocRaptor’s Javascript support to the rescue! Running arbitrary Javascript in your document prior to creating it is incredibly simple.

Take a look at this file, for example. You’ll notice it’s mostly Javascript (over 1600 lines of Javascript, in fact) and it produces a QR code you can scan to be taken to DocRaptor’s site.

The bulk of the Javascript allows for the creation of the code, and this line near the bottom of the script determines where the code sends a user:

Liquid error: No such file or directory - posix_spawnp

You can change this to be any site you wish, and the QR code will automatically update.

Getting DocRaptor to run any Javascripts prior to generating your PDF is easy. Simply pass this optional parameter prior to creation:

Running Javascript in DocRaptor

By setting another parameter, you can use Prince’s built-in Javascript engine. Prince provides documentation for several useful Javascripts, such as getting a total count of pages in a PDF, or generating tables of contents. You can see an entire list of these Javascripts here:

List of Prince Javascripts

To use Prince’s built-in Javascript engine, you’ll need to pass this parameter when creating a PDF using DocRaptor:

Prince Javascripts in DocRaptor

RAZUR Case Study

We’ve recently been working with a client who needed to implement dynamic PDF generation across multiple marketing pages. This was an interesting use for DocRaptor, and we thought it was a great opportunity for a case study. Chris Merkle, CEO of RAZUR, was kind enough to share his story with us.


Client: RAZUR

www.razuragency.com

Background

RAZUR was in the market for an HTML to PDF solution for their Client, an industry-leading managed security service provider. After reviewing multiple options, including developing their own PHP-based web solution, RAZUR choose DocRaptor.

“Our development team choose DocRaptor because it was cost-effective and allowed us to rapidly roll-out a solution for our Client,” says Chris Merkle, CEO of RAZUR.

The goal was to dynamically generate marketing collateral from content that was already stored in a content management system, without having to change static PDFs every few weeks.

Solution

By using DocRaptor’s URL-based solution and a highly-customized CSS3 stylesheet RAZUR was able to create a flexible template that would scale across 25+ marketing web pages. Hidden HTML “div” tags were used as wrappers to dynamically include “About Us” content, custom call-outs and page titles while adhering to the Client’s strict brand guideline.

Results

RAZUR’s Client is now able to provide their sales team and website visitors with elegant, always up-to-date PDF brochures with the click of a button. By using DocRaptor to generate PDF files, RAZUR was able to create a solution that saved hundreds of hours of content design; the Client no longer had to make changes to the slew of marketing collateral every time the web content changed.


We’re always happy to help developers implement DocRaptor. Our goal is to make it simple to convert HTML to PDF and Excel, and it’s great to hear from satisfied clients like RAZUR.

Do you have an interesting DocRaptor implementation story? Contact us if you’d like to share!

What if Debugging was Easier?

We just made it a lot easier to prototype with DocRaptor! We’ve implemented a new feature that will email errors to you when a PDF or XLS file fails to generate as expected. This feature makes it simpler for new users to implement high quality PDF and Excel generation, as well as helping our established users deal with unexpected problems.

Here’s an example of what these emails look like:

Sample Error Email

We include the error DocRaptor returned as well as a link to the document log for the failed document. By clicking through, you’ll see all the information we have for that document, including any problems or errors in DocRaptor’s attempt to create it.

All new users will automatically be opted in to receive error emails, but existing users will have to opt in. Or maybe you already receive a ton of email, and this feature isn’t super helpful to you. It’s easy enough to turn off. You can make your selection by clicking the “Edit Profile” link in your account dashboard. Behold:

My Profile Page With Error Email Opt In

That’s all there is to it! This feature will notify you when something breaks in production, reduce the time spent on debugging, and make it easier for our support team to assist you if you get stuck.

Generating Landscape Format PDFs

DocRaptor makes it easy to generate PDF files with customized sizes and orientations. Our service uses Prince XML for PDF generation, and setting customized sizes is simply a matter of using optional CSS rules.

Here’s some sample code that will generate a US Letter sized PDF in landscape format:

Liquid error: No such file or directory - posix_spawnp

Landscape format PDF

You can use optional Prince CSS parameters to create PDF files with a wide variety of standardized sizes and formats, as well as setting your own custom dimensions.

Here’s a link to Prince’s documentation, with a full list of their optional page size CSS parameters:

Optional PDF page sizes

HTTP Timeout Option

Most DocRaptor customers have complete control over the assets they use in their assets, but one of our newer customers is aggregrating content from a variety of marketing material. All of the assets from that material may or may not be available. Bloomingdale’s is not going to keep their May, 2012 email marketing content online forever.

Enter http_timeout, the latest feature available for DocRaptor. By default, we try to fetch an external resource for up to 60 seconds. With this option, you can set the timeout to whatever you want. As an example, here’s a contrived document that takes a long time due to timeout

Liquid error: No such file or directory - posix_spawnp

If you run that command, it will sit there for quite a while waiting for a timeout. Let’s try setting the timeout to 5 seconds:

Liquid error: No such file or directory - posix_spawnp

Much better.

The important part is

Liquid error: No such file or directory - posix_spawnp

This option only works if you’re Prince 8 (or newer). If you’re using an older version, the option is ignored. It’s not necessary to specify the Prince version if you’re already using 8.1 as your default. If you’re not sure, check your profile page. It’s easy to switch!

Prince 8 - 8 Times More Princely!

Good news, everyone! DocRaptor has been upgraded to Prince 8.1.

The latest version of Prince XML provides better CSS support, which means DocRaptor produces even better PDFs. Prince 8.1 is faster than our current installation of Prince 7.1, and supports CSS3 transforms and has experimental support for HTML5.

For a full list of the changes, check out the change log on Prince XML’s home page:

Prince 8.1 change set

A bit worried about Prince 8.1 breaking your Prince 7.1 layouts? Never fear! We are running both Prince 7.1 and Prince 8.1 side by side, which means you can still use Prince 7.1 to generate documents, if you prefer.

All new DocRaptor accounts will default to Prince 8.1, while all existing accounts will default to Prince 7.1. You can change this setting for all documents you create, or set it per document. Here’s a screenshot showing how to set this parameter globally:

My Profile Page With Default Prince Options

You can use our new Prince version API parameter to select which version of Prince you want to use for each document.

In the near future, we’ll provide improved support for Javascript DOM properties, but this feature has not been implemented with this update.

Don't get caught in the Jurassic Period. Upgrade to DocRaptor Gem 0.2.0

Good news, friend! DocRaptor Gem v0.2.0 Released today. Check out the new Gem with test suite and ARec-style ! methods. Here’s the repo. You can see code changes here.

Gem change log for 0.2.0:

  • tests!
  • added a create! method which will raise an exception when doc creation fails
  • added a list_docs! method which will raise an exception when doc listing fails
  • added a status! method which will raise an exception when getting an async status fails
  • added a download! method which will raise an exception when getting an async status fails

Have your own incredible idea? Send an email with feedback to the DocRaptor dinosaurs or fork it and send us a pull request.

DocRaptor Does Google Webfonts Part 3: Rails Edition

Mark from Carriemail asked about using Google Webfonts</a> in the DocRaptor Rails Example (clone it from github).

Now that the link-fest is over, let’s talk about how to do that (it’s really easy).

In app/views/index.pdf.haml (original), I add the following to the <head> of the haml file used to make the PDFs: Liquid error: No such file or directory - posix_spawnp

I also altered the table to use th and thead tags. The changes are on the google-web-fonts branch at github.

I added a couple of items to the sample app, and here’s what it looks like after the change (non-test document and font-size bumped).

Listing Examples

Note: If you’re planning to use this in production, I highly suggest using Rails Layouts and external stylesheets to manage your common code and style settings.

Thanks for the question, Mark!

Links:

DocRaptor Does Google Web Fonts Part 2 - Electric Boogaloo

In my original Google Web Fonts post, I gave a simple example of using Google Web Fonts via their CSS downloads. This post deals with using Google Web Fonts via javascript. Yay!

I’m going to pull the js example from the Webfont Loader page. It is reproduced below. Note: I have altered the sample to remove some CSS rules to make it easier to follow.

Liquid error: No such file or directory - posix_spawnp

If you’re using the DocRaptor gem example from the DocRaptor Examples repo, you could change the PDF block to look like this (assuming you had saved the above html to a file named google-fonts-js.html in the directory with doc_raptor_gem_example.rb):

Liquid error: No such file or directory - posix_spawnp

After running the file through ruby, you should end up with a PDF named google-fonts-js.pdf that looks like this (caveat: I bumped up the font size, centered the text, and turned off test mode for this picture):

Generated PDF Image

More beautiful fonts in your PDFs with ease!

Downloads:

No Margin PDFs with DocRaptor

We had a support ticket come in this morning about how to make a PDF with DocRaptor having no margins. What follows is a little background information and the simplest way to achieve the result.

Page Styles in Prince XML and DocRaptor

To understand how to do this, you need to know DocRaptor uses Prince XML to produce PDFs. Prince has several interesting additions to standard DOM/CSS, the most important of which for this tutorial is page styles.

Prince allows us to set styles on a @page element. That element corresponds to an element that wraps everything else that will appear in your PDF. An analog of this you are probably familiar with is the page styles you can set when physically printing documents. I encourage you to poke around the @page-related documentation on Prince’s site. Really cool stuff!

Setting Your Page to Have No Margins

Anyway, back to the tutorial. What we want to do is set our page to have no margins, as Prince’s default works out to around an inch/2.5cm. Here’s some HTML and a picture of the document that it generates.

Liquid error: No such file or directory - posix_spawnp

What it looks like:

no margin example

It’s as easy as that. Check out the downloads below to see the actual documents.

Downloads:

DocRaptor Does Google Web Fonts

Google Web Fonts are an easy way to add some panache to a website. With DocRaptor’s javascript and font-face support, they’re an easy way to add some style to a PDF.

Google’s Getting Started page has a a very simple example (reproduced below) that can be used to generate a simple PDF. Liquid error: No such file or directory - posix_spawnp

If you’re using the Ruby Example from the DocRaptor Examples repo, you could change the PDF block to look like this (assuming you had saved the above html to a file named font-sample.html in the directory with straight_ruby_example.rb):

Liquid error: No such file or directory - posix_spawnp

After running the file through ruby, you should end up with a PDF named google-fonts-ftw.pdf that looks like this (caveat: I bumped up the font size, centered the text, and turned off test mode for this picture): PDF generated image

And that’s it. Beautiful fonts in your PDFs with ease!

Headers and Footers in PDFs with DocRaptor

DocRaptor Support gets asked a lot if there’s support for headers and footers. The answer is a most definite YES!

We use Prince XML to product PDFs. As such, there are some specialty CSS rules that can be used to create consistent headers and footers for your PDFs. Here’s the Prince XML page header and footer documentation.

A simple example and output are below.

Liquid error: No such file or directory - posix_spawnp

After running it against DocRaptor, you should get a doc that looks like this: header and footer sample image

Downloads