I still maintain there is a bug.
On the settings for a given form there are two entries for date format.
The one which specifically references the [date] tag is set as follows:
– – – Begin cut and paste – – –
Use [date] in the name of your PDF
Enter date format without space, -, /, _, etc..
Fj,Y April7,2017
– – – End Cut and Paste – – –
Then further down is a section that reads as follows:
– – – Begin cut and paste – – –
Select a date and time format —> F j, Y g:i a —> April 7, 2017 9:24 am
– – – End Cut and Paste – – –
This second section DOES NOT reference the [date] tag.
So what you are say is that the first setting is useless and has ZERO effect on the resulting form output despite the fact that it specifically says that it should whereas the second setting DOES have an effect on the resulting form output despite the fact that it completely omits any reference to the [date] tag.
So that is, to me, a bug when you have a setting that does not do what it says it does and another setting does something that it does not say it does. Therefore, if that is how this should work then the first setting should be removed from the settings page and the second setting should be edited to show that it directly effects the inputted field on the resulting PDF document.
I would, as mentioned elsewhere, also like to see a second edit window so that CSS style can be applied in what effectively would be placed in the <style></style> section of the head of a page. Inserting CSS styling inline with the HTML tags is a pain and results in messy looking code.
Another thing I ran into is that I was using Dreamweaver to lay out my form’s PDF output and the editor for this plugin appears to see and treat word-wraps as carriage returns and effectively applies a “<br>” when one was not explicitly presented.
