Issues with the new invoice theme


I’m having a few issues with the new themes. We had an invoice in the old templates which worked fine, but after recently upgrading to version 16.12.11 (on Windows 10), we decided to try working with themes.
However there are some things that aren’t rendered correctly.

  1. Using rowspan in a td-tag doesn’t work. When I change the theme and save it, it automatically removes the rowspan-attribute.
    So <td rowspan=”3”> changes to <td>.

  2. We worked around the above issue, by using a table inside a td-tag. This works fine in the preview and print function. However when using the pdf-button (and e-mail), the inner table and all its content is not visible at all. There’s just an empty spot.

  3. A few css-properties are not working in my invoice.
    a. <td style="padding: 0.5cm 0;">
    At first sight, it looks like padding is ignored everywhere, when using the pdf-button. In preview mode, everything is fine.
    b. I have the following code, which shows an image over the entire width of the invoice. However when using the pdf-button (and e-mail), it ignores “width:100%” in the style attribute of the image tag.
    I fixed this for now, by changing the image itself to almost the correct width and added “text-align:center;” to the parent td-tag. But it’s not the best solution. Code:
    <tfoot> <tr> <td colspan="2" style="border-top: 1px solid #000; text-align:center;"> <img src="file:///C:\managerio\factuur-1.jpg" style="width:100%; margin: 20px 0 0 0"> </td> </tr> </tfoot>

  4. In the example invoices, all fields are just visualized by looping through the fields array and printing them on the invoice in the order they come.
    In my case, each field is at a certain predefined spot and the fields are not next/under each other. The field “invoice number” is for example at the top left, while the “invoice date is at the bottom right. To put the correct field on the place where I want them, I have now used the following code:


{% for field in fields %}
{% if field.label == “Bestelnummer” && field.text != null %}
Uw referentie

{{ field.text }}
{% endif %}
{% endfor %} `

The problem here is that I have to rely on “field.label”. This depends on the users language settings (in this case Dutch). I’m afraid that after a next update, some changes will happen to the language files and the description of fields will change. This would break my code.
Maybe it’s a good idea to add a property “” and this is always the English description and even if the English label would change after an update, id should always stay the same.

If there is another (better) way to solve my problem, please let me know.

Point 3 and 4 are not very crucial, because we have a workaround, but point 1 and 2 are really a problem, because we can not send any invoice at this moment through e-mail. If only one of these issues is fixed, we are saved.

Regards and thanks in advance

First, try updating again. You are already 20 versions behind, and recent changes have to do with PDF generation.

Second, try your padding changes in px instead of cm. That’s how the original is done, and it has worked for me.

Third, I’m no expert on CSS, but you may be using CSS code/attributes that are not supported by Liquid.

Hi Tut

Thanks for the fast reply. Adding padding in px instead of cm indead does the trick.

I forgot to mention that I’ve also tested on another computer where I installed the latest version (16.12.31, downloaded today) and it looks still the same.

I look further into the support of css attributes, but I don’t think it has anything to do with Liquid, but rather with the engine used to translate html to pdf. But still I’m going to search for it to be sure. If I find something, I’ll post it here, so that other users can also benefit from it.


Hi All

The latest test today with version 16.12.38 learned us this:

  • Point 2 of the start post is wrong. Tables inside tables are no problem.
  • The issue was caused by using colspan. The rows where colspan is used are no problem. The rows without colspan are affected. So my conclusion, avoid rowspan and colspan as well (allthough some of the themes seem to handle colspan correct).
  • We fixed our layout by putting table inside table, inside table… The outcome is good in layout mode and pdf as well. It now takes more then a minute just to generate the pdf, but at least, we have the layout we need.
  • Height, padding etc. is still unreliable in pdf-mode. Using px instead of cm or % works at first sight, but whatever value you use, the output looks always the same (so height:50px; and height:200px looks exactly the same in certain situations). The most leliable fix was adding whitelines to set the height.

So we have a workaround for points 1-3.

Is there anybody who wants to take a look at point 4?