Allow conditional logic in PDF form?

Looking a bit more into the options currently available, the PDF can be made to look "more" like the form by checking the ... something like ... view text and such.  It adds just about all of the elements in your form, trying to keep the flow as the element are listed, BUT loosing most if not all CSS done to manipulate the layout.  

For most people, that should work to pretty darn close to the form during submission.  For me, well ... it can be close, but often not close enough.  Background image, for example, are gone in PDF. I was expecting the PDF to be as if the form was printed the moment it was submitted w/ all of the page layout even including effects done through custom CSS and such. Media being frozen, as usual when printing animated web pages.

However, if there is any kind of logic in your form, ex conditionally hiden fields, they  all show up UNLESS the data for it is blank and you have the ckeckbox to exclude these.  So any fancy form is going to look, at a minimum, ... weird.

So you can customize the PDF which gives a bit more control, but no logic to match the actual form. Forms with separate paths can become ... crowded ... as everything you pick will be included.  That will need some work.  Adobe has a leg up on this since they overlay data onto a virtual 'paper'. The page layout is as if you were using paper.  Not much better, if you ask me.

The PDF generator should follow the conditions set for at least "hide/show" logic of the form.  As such, elements not seen during form submission will not be seen in the PDF.  Ex: I've got a form which shows one of three text elements depending on selection of a radio selector. In PDF... all three text elements are shown.  It should show just the one needed.

UPDATE: We are excited to announce that we have just released the new version of JotForm PDF Editor.

PDF's an not capable of interpreting conditional logic from forms.  It is something we have not be able to implement in fillable PDF forms either.  Some things simply cannot be translated from web format to PDF format. 

If you use an edit submission link that can be included in email notifications, it is possible to return to form itself with the data filled in:

http://www.jotform.com/help/40-How-to-Let-Users-Update-Their-Form-Submissions-at-a-Later-Date

Add a print button to your form and print the actual form:

http://www.jotform.com/help/24-Print-Button-on-Forms

Actually, the PDF format allows a whole lot more than one think.  One can include scripting, videos, etc.  It stands for Portable Document format, not Printing.  In fact, Adobe has added features which makes PDF more of a container of whatever ...  I have seen PDF "documents" which are actually a interactive (simple) game (basically some Java scripting).  Others forms feed and grab data from a backend database (which could be JotForm). Of course, being an open format, there is weird things going on in some PDF "documents" which might not be up to ISO standards.

 

But more to the point, there are several ways of converting HTML pages to PDF.  Looking at Adobe web site, one can find :

 

You can create PDFs from documents printed on paper, Microsoft Word documents, InDesign® files, digital images and web pages, to name just a few examples. Different sources use different tools for PDF conversion.

To be even more precise, what I was suggesting earlier on was to create a 'snapshot' of the web view of a form as a PDF.  Wether this is done at time of submission, to be a 'frozen' view of that submission, or on the fly, to use latest page layout of the form, is up to JotForm developers. There are bad & good aspects with each of those two approaches.  In either case, the PDF itself does not need to have the conditional logic and such.  It's just a PDF view of the web formated form.   Akin with copying the value of cells, not the formating or formulae, in a spreadsheet.  The PDF will show what would be shown on the screen in someone's browser. In fact, the conversion of HTML (and its CSS) to PDF could even account for "@media print" aspects to be ... just as if printed at the time submitted. It depends on the tool used to generate the PDF : take resulting HTML and make PDF...

 

As such, it is not impossible.  There are a bunch of plugins for other systems which achieves this. Included in the long list are :

http://docraptor.com/ - "you just send HTML, JS and CSS and you get back beautiful high quality documents at scale.  It's an online service, so not what you would be looking for.  Furthermore, I never used it.  It's just an example a recently bumped into surfing the web ...  It looks great tho: http://docraptor.com/samples

 

http://www.runpdf.com/ is an other example of an online service for html to PDF conversion. This one supports HTML tags, HTML5, CSS3, JavaScript, SVG, WebFonts, ...

 

http://pdfcrowd.com/ is an other.  It has a free mode with no need to give any information.  I just pointed to a blank preview of one of my JotForm forms, the free level gives no control over page size and such, so I got this which is, for all intents, exactly my JotForm form.  Cool !

Short of the (not so stupid if you want people to pay) default of doing landscape instead of portrait and cutting, obviously, into pages (the 'paper' aspect of PDFs), the result is fantastic.  

It has all of the HTML and CSS.  All I did was give it the URL of the form, the exact same URL used by the people filling out the form.  But it could be sent an HTML file, thus the content as well... for potentially perfect results.

 

Tons more options are out there.  The ones needed for JotForm would probably be hosted on your "own" (AWS) servers.  Which solution to use is a choice for the developers.

 

Question is how will JotForm do it ... and when ?

 

One thing I learned in my 30 + years in computer science is nothing is impossible in the virtual world.  One simply needs to figure the way of programing it ...  Where there is a will, there is a way.  Available time and budget are important factors.  ;(

Actually, you currently generate a PDF and even allow some customization of this PDF.  You probably have the tool already in hand.  All that is needed is to give it the HTML/CSS of the form as viewed by the user instead of the view pre-defined by you or customized by the form creator.

It's just a different view of the same data ...

It could make things easier at your end since you would not need to build the PDF 'table' view or let us customize this view.  You just grab the form's web layout and that's the PDF.  If someone wants to customize it, they could use @media print in their custom CSS of the designer depending on how your html to pdf tool works.

 

I understand what PDF's are capable of.  The issue is with the conversion between formats.  If it were as simply as running it through a conversion tool, we would have done it long ago.  My workaround presented the option to print the full form exactly how it is seen when filling it out.  Which would include conditionally hidden fields and things of that sort. If the tools you are using work to export the form, they would work with this method also.

 

What I meant by conversion between formats is that submission data is stored in plain text.  It would need to then be converted back into another format, in your case back in to web format, then converted once again from that format to a PDF.  While possible, it is not likely to be implemented. 

The thing is most people don't think of printing the form right there and then when filling one up... When I first tried the 'print buton' I also had some issues (which I need to recreate, if possible, to get your thoughts).

Worse, when there is a payment involved, the user may need a copy of it months later. Being able to reprint at will a submitted form becomes an important feature.

 

As for converting the data back to a PDF, you already do it with the PDF link, even with customized PDF.  I just need to add the PDF link to the autoresponder message so a user can get to it. The PDF is just not THE form but a different and simplified (no logic) rendering of it. For many forms, it does the trick.  For forms with logic and some fancier page layout, it can get ... ugly ... fast.

 

All I am saying is why not use the original web form format instead of a very different one ??

Isn't it the same steps involved at your end : take raw data, feed it through something and convert to some PDF format (pre-defined or customized) ?  There is a definition, somewhere, of what these PDF are to look like.  Of course, the web form has some tricks ...  

At its 'simplest' it would be using the "edit link" to get the web view (all the logic is built in) and feed this virtual web view (a html file, with data already processed and imbedded) to the tool generating the PDF.  This sounds like taking the raw data and passing it to the existing tool to make the PDF ... Rather than doing it manually with the workaround, it would be nice to have the feature as a 'click'.

 

I'll see what I can pull off from this side given the instructions to make a non-editable 'edit link'. The end user might have to do a few clicks, but it should work ... at least for now.   It's quite a few extra steps at the end of creating a form. Steps to be done once the form definition is stable...

 

I think I can live with this (temporary / long term) approach.  At least it can be made to work. I just need to start writting a work flow so I don't miss any steps with the various workarounds ...

 

Thanks for all the quick and quite useful support.

 

Allowing the user to have a PDF of a submission is one of the easiest thing to do with JotForm. You can either include the PDF link (Not the Edit link) in the Autoresponder, or add the print button as previously suggested and use it to get a PDF of the form with filled data ( All modern browser allow you to save the form as PDF when clicking the print button).

JotForm has a lot of features, you just need to explore them and learn how to use them to achieve what you need.

Here is a demo form that will allow to print form entries and save it as PDF

- https://form.jotform.com/60826243169963.

Note that the conversion is made by the browser, not JotForm itself. 

If you need styling edit in the PDF or printing, it simply requires a little CSS with '@media print'. If you cannot find the code, we always here to help.

 

Browser is not an operating system, as such, it has its limitation. What can be achieved inside your 'El Capitan' with Acrobat, cannot be done with the browser, either for security reasons or limitation in the technology.

I could never found an application that convert a web page from the browser with Script and video or all the interactive contents into a PDF file. Even the Acrobat DC plugin does not. If you know a web software that can make this type of conversion, please share it with us, we can learn from it. 

 

The point you are missing is the PDF currently available is NOT the form, it's the collected data reformated, without any of the conditional logic or other particuliarties of the actual form.  It is, basically, a better looking dump of the collected data.

Yes, if one creates relatively simple forms - no conditional aspects, no custom CSS, the PDF is possibly real close to the form if not dead on. However, JotForm allows for so much more than simple forms.  It allows for :  conditions, hiden fields, ... as well as customized CSS.   The PDF currently allowed, even if customized, can't properly reflect the more advanced forms.   These advanced forms are where JotForm shines compared to alternatives ...

 

Adding the print buton and using it just before submitting is currently the only way to get 'hard' version of the submission (a print which can be to a PDF print driver which the user must have installed ahead of time, not always the case).

 

The next best way, currently, would be to give the 'edit link' AND disable all fields, along with 'submit' buton, as detailed earlier by yourself or an other member of JotForm, so the user can RETURN to the form webview to use the browser's print, since JotForm's 'print buton' would be disabled in the process.  More work when creating the form, but good for the end user and ... JotForm.

I will be testing and most likely using this approach for at least some of our forms.  It gives a enduser the best experience, but me the most work.  I do the work "once" for each form.

 

It would be so much easier and natural for the person submitting a form to be able to return to submission with a "view only link" (ie equivalent to automatically disabling fields and 'submit' in otherwise 'edit link') to print from his/her browser OR, better still, to generate / display the PDF version of the web view with the data built in.  The end result would be nearly the same.

This would also be so much easier for us to create forms with a real PDF version.  Of course, this shifts all of the work to the JotForm developers - done "once" regardless of the number of forms.

 

I believe allowing a "view only link" could be "simple", depending on how things are done w/in backend of JotForm.  It could be a special mode of the existing "edit link" where fields are ALL disabled (automatically) along with any submit butons...  In other words, it forces the "disable" conditions without any work for the form creator.

 

In other words, it is usually best to shift the work towards the source where it is usually done once rather than towards the end users who would need to do the work every single use - thousands of times.

 

As mentionned earlier, I'll give the workaround a try.  It should not be too painful at this time ... I will be looking forward to an eventual "view only link", whenever (and if) it becomes a reality.

 

Challange accepted :

Look into the few web page (HTML/CSS) to PDF converters pointed to in my earlier post.

Here is PDFcrowd (service which got my attention to date) generated PDF of our main public page (CscProvidence.ca) :

The top portion is a slideshow.  The generated PDF has the 'first' slide, not showing the animation. Which is fine AND a lot better than most other solutions found to date.  It would also be perfect for what I am looking out of JotForm - a PDF view of the form's web view with data (a snapshot). Note the actual PDF generated kept the text as text - I can cut and paste it.  It is not an image, as the above screen capture.  Which is fantastic !

 

An overly animated web site, like one of the top 10 animated web sites (Bundy.MadeByWild.com) obviously "fails" because the (free version of) PDFcrowd sees and grabs the first display which is a blank page (in this particular case).

A different approach used by these overly animated web sites, like InvolveDigital.com, gives a bit better results - several pages with the contents shown in the order it appears when you scroll thru their web sites.  But again, this is an extreme case which would not be expected in a form ... even if one I would create ;)  Its animations beyond the needs of a form.

A page with just a video turns out blank.  It has no HTML/CSS other than play a video.

Go explore it ... the free version does not even need to create an account, it just works (with lots of limitations as to PDF page format, ...)  There's enought to get one's appétit wet.

 

Giving it the YouTube default page (https://www.youtube.com/?hl=fr&gl=CA) is interesting...  The top autoplay trailer is lost but the other parts are properly shown within the delay of the default of PDFcrowd.  

giving it an actual YouTube to 'watch' (

gives good results short of the video portion which appears black - maybe didn't wait long enough to grab the web content ?

 

Which brings up interesting settings with the paid version (which I have yet to sign for, still looking at alternatives in case there is even better) :

 

Notice (hard to read beneath the "get a license ..." blob) some key parameters :

- define PDF page size, margins, etc. (after all, PDF are what I call 'electronic paper') BUT they include a "One Long Page" which would be great to avoid ill placed page breaks.

- ability to password protect, block printing, copying, etc (within PDF standards that is)

- (under the "Get a ...") looks like settings to play with time delay before taking 'snapshot' or what hey refer to as "Initial PDF View" of the contents to convert to pdf. Default: continuous adjusted to width after 200 ms

- HTML options such as "do not run JavaScript" (!), "do not print images", "do not print backgrounds", "Use print version if the page if available", "do not make hyperlinks" (which means it does by default - cool !) and even "zoom" (set the % wanted).

This might be a winner given it also allows to pass it the HTML/CSS file (rather than a URL) to convert as well as an API to build PDFcrowd into applications (ex: JotForm ?)  It even allows for a "Save to PDF link" to add to a web page for visitors to click and get the PDF of the page - sounds like what is needed, no ?

It's a question of whether it is priced right for integration by JotForm or if there is better options out there in the wide wide world of Internet ...

 

PDFcrowd otherwise "freezes" (takes a snapshot) of pages with the type of animations I woud expect or be able include in fanciest JotForm forms short, maybe, of the video portion (rare in forms ?)

 

Again, thanks for the informative, useful and prompt support.  It is most appreciated as I get prepared for making more forms with JotForm.

We will look into the services you shared with us. We appreciate the effort you took to point their features. Please let us know if the workaround solves your problem.

Thank you.

To go back to a prior JotForm post in this thread :

 

---%----

Here is a demo form that will allow to print form entries and save it as PDF

- https://form.jotform.com/60826243169963.

Note that the conversion is made by the browser, not JotForm itself. 

-----%---

 

This is fine for printing the form before submitting it.  What happens if the person wants to print a copy 3 weeks later (for whatever reason : lost first, forget to print first, ...) ? They can't ! Sample would look how in the default PDF ?  Although the sample is a relatively simple form ...

 

Now try to do the same, print after the submission, a form such as this one (it's a clone, you can modify it as JotForm, others shouldn't have access or rights to even clone) :

https://form.jotform.com/61265811926963

It just doesn't work into a nice PDF given some elements are shown only after given values of a bunch of fields.  The default PDF prints all elements and system passing info to the PDF creator, doing 'black box' type tests at my end, does not take into account the conditions and such.  This would not be the case if the PDF was generated based on a 'view only' version of the 'Edit link' - webview would always be 'right' regarless of condtions.  In fact, it would change according to the data.  Which is exactly what is wanted - ability to print THE form exactly as displayed/filled.  The default PDF format, even if customized, is just a record of the data filled especially if the form as condtions, hidden fields, etc.

 

Am I being clear enough ?

Basically, take a form like mine (see link above) and print it before submitting (add print buton) and compare to the PDF format, even when showing all fields/elements.  See the difference ??

 

By the way, yes I can add @media to manipulate the browser printed version of the form, as I had already mentioned earlier in this thread or in a similar thread.   However, this will be lost in PDF of JotForm, customized or not, since it does not use the web view of the form.  So we would be forced back to having a 'view only' version of the 'edit link' to get all the work done in the form definition, including @media in the custom CSS.

 

Is that clearer now that we have done a few full circles around the situation, need and possible work arounds ?

 

Have a great weekend, the sun is out ...

Thank you for sharing your thoughts and knowledge with us! We really appreciate that users take time to explore how the system works to provide solutions.

 

Thank you!

UPDATE: We are excited to announce that we have just released the new version of JotForm PDF Editor.