PDF files with editable form fields

rbuser

Hi,

using the FormField property of the Checkbox component, I've noticed
that there is a difference between the design and the preview at the one
side and the PDF-Output at the other side: The Checkbox in the
PDF-Output is larger if the FormField property is set to true.

This occurs only in the PDF-Output. Preview and priting to a printer is Ok.

Testing is easy: Take the example in PDFForm.zip and change the
FormField property of one or two of the four Checkboxes to true.

Regards

Heinz Blase

D7, RB 18

rbuser

Testing is easy: Take the example in PDFForm.zip and change the
FormField property of one or two of the four Checkboxes to "false".


Am 16.02.2017 um 22:11 schrieb Heinz Blase:

nicocizik

Hi Heinz,

This is an unfortunate result of the original checkbox design.

Checkboxes in ReportBuilder are drawn using the Wingdings font which
does not take up the entire control space. In PDF, form field check
boxes do take up the entire control space. Resizing and re-positioning
is possible however it changes the control position and makes designing
difficult.

For now, it is not recommended that you mix non-form fields and form
fields in the same form of a PDF.

It is on our todo list for a future release to redesign the Checkbox
components to avoid using fonts and render with vector graphics.

--

rbuser

Hi Nico,

there is another strange behavior using the Checkbox with FormField set
to "True":

Using the Style "csXMark" the Box in the PDF is allways marked, even if
Checked is set to "False". Using the Style "csXInBox" all works as apected.

Same with the other Styles.

Regards
Heinz


Am 17.02.2017 um 17:32 schrieb Nico Cizik (Digital Metaphors):

nicocizik

Hi Heinz,

There is a patch available for RB 18.0 that fixes this issue. Active
subscribers can email support@ to receive this patch.

--

nicocizik

Hi Heinz,

I have attempted to send you the patch multiple times however it appears
your email server is blocking the email with the error message below.

"554-Bad DNS PTR resource record."

If you have an alternate email I can use or can resolve this on your end
let me know.

--

rbuser

Hi Nico,

I have to mix form fields and non-form fields because my customer
demands a form, that ist filled out by two of his employees. The first
should not change the form fields, which had to filled by the second,
and vice versa.

My solution:
The "first" set of boxes are filled out in my program (non-form field in
the PDF).
For the "second" set of boxes only the naked boxes are written as
non-form fields. On the top of them only the "mark" is written as form
field which can to be filled in the PDF.

Your announced future release would be very helpfull....


There are other strange behaviours which I detected:

* Checkmark instead of X-mark
Writing a PDF with csXMark/csXInBox boxes shows different symbols
depending on the viewer.
- "Adobe Acrobat Reader" shows a "swinging" X
- "PDF-XChange-Viewer" shows a very "fat" X
- A viewer based on then "Chromium PDF Viewer" shows a checkmark !!!

* Form fields in an encrypted PDF
Form fields (boxes and labels) in encrypted PDFs are showing very
strange characters, even the blank boxes. Maybe because of the encryption?

Thanks.

D7, RB17



Am 17.02.2017 um 17:32 schrieb Nico Cizik (Digital Metaphors):

nicocizik

Hi Heinz,

Thanks for the feedback.

1. We extensively test our generated PDF files with Adobe products. The
form fields make use of the built-in font ZapFDingbats to produce the
"X" or check mark displayed inside the PDF. If non-Adobe viewers are
showing something different they are likely not supporting this font or
are using a substitute.

Below is a excerpt from the PDF Reference 1.7 under font management:

---

PDF prescribes a set of 14 standard fonts that can be used without prior
definition. These include four faces each of three Latin text typefaces
(Courier, Helvetica*, and Times*), as well as two symbolic fonts (Symbol
and ITC ZapfDingbats®). These fonts, or suitable substitute fonts with
the same metrics, are required to be available in all PDF consumer
applications.

---

2. Form field encryption: This issue will be fixed for the next release
of ReportBuilder (18.01).

--