Put in Text in Textfields at PDF files

[jan.thiel@…]

Hello Lucide team, at the Acrobat Reader, I have possibility to write direct to the pdf document and then print it out. Another feature is, to save a copy of the current pdf document.

best regards, Jan Thiel

[ktk]

Moving to 2.0, we can think about that when we are bored ;)

[Eugene Romanenko]

Attached f1040.pdf from ticket #57

[Eugene Romanenko]

Sample file from ticket #125

​http://www.irs.gov/pub/irs-pdf/f941.pdf

[Eugene Romanenko]

Preliminary support of Interactive Form added in Poppler 0.6 Release Candidate 1 released on May 30, 2007 (very buggy yet).

When it will be stable we may start implementing Form support in Lucide.

[Silvan Scherrer]

whats the state of Form support now? afaik Form support of poppler is stable now.

[dmik]

Adding this feature will require changes in the LuDocument? interface but this doesn't look too difficult. There will be a new interface for encapsulating an input field anchored to a certain place on a page of the document and a method in LuDocument? returning a sequence of input fields on a given page to navigate through.

The main question is where the input processing should actually take place. There are two possibilities:

1. In a plugin. Lucide will blindly send keyboard and mouse input happening when the input field is selected or clicked to the field object which will convert this input to check marks or to letters, change the document contents and redraw the field on the screen.

2. In Lucide. When the input field is selcted or clicked, Lucide will overlay a normal PM window corresponding to the input field (e.g. WC_ENTRYFIELD) which will handle all user input and then, when editing is done, it will send the results (e.g. a text string) to the plugin.

The main difference is that 1. is potentially more flexible and can draw the input in WYSIWYG mode (using the same style, font, anti-aliasing etc.) but it's definitely more work since all "low-level" things such as caret blinking and moving, clipboard exchange and others will have to be done by the plugin.

On the other hand, 2. provides better integration with the system (unified editing, clipboard support -- all this comes for free, w/o any work from the plugin). The cost for it is slightly more SOM interfaces and methods and the fact that the text that is being edited will look differently from the text that will be saved with the form (in terms of the font look and feel). The flexibility is actually not an issue because we may provide the same blind input redirection mode as in 1. if we really need to.

[dmik]

For me, 2. definitely looks like a preferable way to go. This will require the following changes in the SOM interfaces (briefly):

• The new interface LuInputField? that describes a generic rectangular input field bound to a page of the document. It will include a number of basic properties such as the field ID, rectangle of the input area, font size, modified and readOnly flags, etc.

• A new interface derived from LuInputField? per each field type: LuInputButton?, LuInputText?, etc. They will have type-specific properties such as button state, text string and so on; basically modeled after the respective poppler classes.

• Two new methods in the LuDocument? interface: isHaveInputFields() that tells if the document has input fields at all, and getInputFields( pagenum ) to obtain a sequence of input fields on a given page.

If nobody disagrees, I will start implementing this on Monday.

[Silvan Scherrer]

i also vote for the 2nd methode. i have the feeling the integration is a bit more clean.

[dmik]

BTW, Lucide fully builds using kmk/gcc now and seems to work as good as before. Lucide.dll is slightly bigger than the one by OpenWatcom? but that's due to the C++ overhead that appeared since GCC 4.4.2 that we already discussed within Qt.

See README.DEV for the build instructions.

[Silvan Scherrer]

includes push buttons and more

[dmik]

I got check boxes changing their state in r327 but here's the first problem: this is not reflected in the visual representation of the document. As far as I see, the check boxes are not drawn at all (i.e. even if the check box is set in the source document, nothing is drawn for it, both in the old and new Lucide). Investigating. May be related to font encodings.

[dmik]

The ISP got my connection down today, so couldn't do a lot. Though I found the reason for the problem with the Dingbats symbols. It's actually two reasons (it was quite hard to figure that out):

1. The non-standard char name to Unicode code point conversion scheme is not always interpreted right in poppler.

2. The encoding table stored in poppler (using this name-to-Unicode scheme) for the base ZapfDingbats? font used for check marks in nearly all PDF documents I have doesn't match the font contents according to what I see. If I correct the code point for the check mark symbol in that table all starts to work as it should.

[dmik]

Problem 1 has been fixed in r328. Problem 2 needs more investigation to understand why is there a mismatch in the first place and why it works in Evince (gnome).

[dmik]

Problem 2 is solved in r331 and r332. Please note that to display check marks in PDF documents with forms you need to have either the original Zapf Dingbats Type1 font installed or the latest version of the free Dejavu Sans TTF font which contains the necessary Unicode block (this font is present in recent eComStation releases by default).

So, marking check boxes should fully work now. Everyone is encouraged to test it with his PDFs. Note that you can save the results to a new PDF using Save as... (although an error message box is given which will be fixed later). However, the "modified document" paradigm isn't yet implemented in Lucide AFAICS so there is no warning offering you to save the document when you close Lucide after changing the form.

[dmik]

One-line text input is done. Please test.

[dmik]

Remaining things are multi-line text fields and saving (which is actually a separate task and also broken in the original Lucide). I'll try to finish it today.

[dmik]

Multi line input is in.

[dmik]

The Save As problem has been fixed.

I also implemented tracking the modified state of the form contents and asking the user to save the document on close if there are modifications.

Keep in mind that we don't support push buttons (since there is no javascript support in poppler). Also, we don't support radio buttons, combo boxes and lists since I couldn't get PDFs with these types of fields which means they are very rare.

In either case, I think that it's more than enough for this ticket now. Please someone test and confirm this. After that I will merge the branch to the trunk and prepare Lucide for release.