Skip to main content
Document layout limitations
Matthew James Finkel avatar
Written by Matthew James Finkel
Updated over 5 years ago

Our document layout engine uses HTML & CSS to generate documents, giving you lots of power and flexibility in terms of layout and style. When you download to PDF, we use some software to convert your HTML to a PDF that’s ready to download. 

Converting HTML content to PDF generally goes smoothly and most folk won’t notice any problems at all. There are a few limitations that more advanced web developers might encounter.

Remember that you can create styles to target just the browser preview and not  the PDF – perfect if you use document approval most of the time. See: Target the browser preview

Custom font kerning and spacing issues

Since Current RMS is a web application, fonts used in your documents must be web fonts. Google Fonts is a great source of web fonts. 

Our PDF rendering software doesn’t always work correctly with web fonts and you might notice issues with font kerning or spacing. 

Here’s an example of Open Sans, notice the letter spacing and kerning:

Here’s an example of Quicksand, notice that h , n , m , and o  letters are somewhat clipped:

We’ve investigated this and we’re not too sure what the cause is. Adjusting kerning or letter spacing in CSS doesn’t make a difference. It’s likely that the problem lies with a third-party component used by our PDF rendering software.

Before selecting a font, we recommend testing fonts by adding them a document and previewing to PDF.

Fixing content to the bottom of the body section

If you’re used to creating quotations or invoices in word processors, it’s fairly straightforward to float content to the bottom of the page. This is because you’re working with known content, so you can position things exactly where you like.

Documents in Current RMS use dynamically generated content, so the information on them might fit on one page or might span multiple pages.

For this reason, there’s no way to float content to the bottom of the body section. 

Remember the header and footer are repeated on each page, so you can include information like page numbers at the bottom of each page – it’s just floating content to the bottom of one particular page that’s a problem.

Different headers and footers on different pages

All documents in Current RMS are made up of header, body, and footer content.

  • Header
    Code here appears above the top margin of the document and is repeated on each page when printed to PDF.

  • Body
    Code here is placed between the margins of the document. This is where your main content should go.

  • Footer
    Code here appears below the bottom margin of the document and is repeated on each page when printed to PDF.

The header and footer content will repeat on every page. There’s no way to prevent this from happening, so it’s worth bearing in mind if you’re looking to build cover pages or would like documents with different headers across pages.

Keep in mind that PDFs that are attached to document layouts and merged during PDF generation will not include the header or footer.

HTML and CSS properties not supported

  • CSS flexbox

  • CSS columns

  • CSS animations (of course!)

  • Embedded content like maps or iframes

Target the browser preview

The body of the document layout preview in the browser has an ID of print_preview , meaning you can create styles that only target the browser preview and not the PDF. This is handy if you use document approval more often than not.

For example, to set a custom font to show in the preview but not the PDF, you might use:

body#print_preview {
  font-family: "Open Sans", sans-serif;
}

The PDF doesn’t have a body ID of print_preview, so it’ll be safely ignored.

Remember, you may use the :not()  selector to apply styles when a condition isn’t matched. For example, to set the text color to red in the PDF but not the preview, you might use:

body:not(#print_preview) {
  color: red;
}
Did this answer your question?