4
3
2

In Maestro preview we can see an 'HTML Receipt' that looks presentable.

The same receipt as 'pdf' does not look presentable as it distorts word wrap, has many blank spaces, has mismatched font sizes and so on. However this is the default receipt produced by TM.


I would like to be able to create the Maestro > Preview > HTML Receipt as the 'pdf receipt' that I can deliver as part of a delivery service.

I notice that Jsoup and iText are packaged libraries, so I am investigating using them.

My plan is to:

  • collect formXml
  • use Jsoup to convert formXml to XHTML
  • use iText to convert XHTML to pdf

I need to use the above approach as iText v5 is the current version in TM. Once iText v7 is available I may be able to simplify the above.

However, I'm trying to work out how to get the css, so that the pdf receipt that I generate looks like the Maestro preview html receipt.

Where can I access the receipt css in the delivery service?

Any ideas would be appreciated.


Thanks

Mark

  1. Dan Cormick

    We're interested in this too. Receipts in Maestro are not what they were in Composer.

CommentAdd your comment...

5 answers

  1.  
    2
    1
    0

    Hi Mark,

    you can intercept the receipt rendering process by specifying your own executable and then pre process the html that gets passed to phantom. We currently are experimenting with this on test where we use nodejs to process receipts with puppeteer instead of phantom. You can modify rasterize.js to detect whether it is running under node js or phantom and so run both in parallel. You could then use javascript in puppeteer or phantom to customize the html/css before rendering the pdf.

    Please ask if you would like to know more about this method - we are struggling with PDF rendering also.

    Matt

    1. Matthew White

      I can think a few advantages of Puppeteer/headless chrome that possibly haven't been explored.

      1. You could run a pool of headless chrome instances and pass receipt render requests to them via websockets (or file based as is done now) and avoid the startup time of phantomjs. The number of instances/browser tabs could scale with the load. People do this with Phantomjs but it needs to kept on a tight leash as Phantom can leak memory. Killing Phantom and lauching a new one after 20 requests is not uncommon.

      2. Receipts could be pre-rendered in the chrome pool based off the receipt template produced by TM for a given form version and then TM just passes the xml data to the pool to render inside an already loaded receipt receipt template. This would work well with a dedicated receipt farm and would be another speed improvement for receipts and offload work off TM.

      As far as customizing receipts go I guess it depends on where you wish to work. It seems more natural to work with the HTML DOM, javascript and css given that it is there already and that would work well with puppeteer but could be done with Phantomjs as it currently stands. Obviously you could also process the form.html file before passing on to phantomjs.

      There is a fair bit of complexity here which to me says that the out of the box receipt quality needs be addressed rather than have various customers investing time in custom solutions.

    CommentAdd your comment...
  2.  
    2
    1
    0

    Hi Chris,

    thanks for the suggestion.

    However, that article does not really help.

    I'm trying to minimise the amount of hand crafting; the idea is to use the existing data and tools in TM, rather than have to create a special receipt template for every form, or go to the trouble an expense of establishing a third party pdf tool/service.

    iText and Jsoup exist in TM and it's possible to create a pdf document using them. The only piece that's missing is the receipt css.

    Ideally I'd like to create the receipt that looks like the Maestro html receipt, but have it in pdf format. To do that effectively in TM I can use iText, but need to get the css.

    The inbuilt Dynamic pdf receipt service uses PhantomJS; so it must obtain the receipt css from TM. I'm trying to do something similar, but as part of a delivery service. The idea is to get the form xml, and also get the receipt css, then pass them through Jsoup and iText to generate a pdf that I can attach to the email delivery.


    Thanks

    Mark

    1. Mark Murray

      Hi Chris,

      Just to clarify the above: I need access to the form html and the css, so that I can get a formatted receipt.

      Thanks

      Mark

    CommentAdd your comment...
  3.  
    1
    0
    -1

    Hi Chris,

    I've been investigating options for creating receipts and seem to keep returning to the same point. I'd really like to get access to the HTML Receipt and the Receipt CSS, to be able to create a great looking pdf version of the receipt.

    I was importing a form to TM this afternoon and noticed in the 'Form Version" > 'Form Design Info' tab there is a checkbox field labelled: HTML Receipt Template

    What does that mean? Is it something that I can control or get access to?

    At face value it looks like what we need.


    Thanks

    Mark

    1. Christopher Eagar

      Maestro does not produce a separate receipt template - a separate receipt design view is on the product roadmap. 


      For now you can use av-receipt as a class in CSS rules like this:
      form[name=“form”].av-receipt {

      For receipt specific styling.

    2. Mark Murray

      Hi Chris,

      thanks for the comments.

      you mention that Maestro does not produce a separate receipt template, but in Maestro you can look at an HTML receipt in Preview.

      Is that related to the roadmap?

      Where would I apply that above 'av-receipt' styles? as part of a receipt render service?

      Can I access the form html in that service? I still need the form html, to be able to apply the css.


      My ideal solution would be one that I can apply to all forms/receipts generically, rather than having to build a solution for each form/receipt individually. The Maestro > Preview > HTML Receipt looks generic enough, so hopefully we can work with that.


      Thanks

      Mark

    3. Matthew White

      Mark,

      I believe that the html receipt is just passed to phantom which then turns it into a PDF. There is no distinction between the two other than in maestro where you get to choose whether it is shown as html or PDF.

      MMat

    CommentAdd your comment...
  4.  
    1
    0
    -1

    I'm very interested in this method. We found updating Phantom to v2.1 did solve the random white space problem, but introduced the fields breaking across pages issue. And as Phantom is no longer supported, we'd rather move to a different method to create the PDF also. Puppeteer was easy to implement, but didn't solve the layout issues.

      CommentAdd your comment...
    1.  
      1
      0
      -1

      Hi Mark, 

      Is the following documentation of any use?

      PDF Receipting Options

        CommentAdd your comment...