Opened 13 years ago

Closed 9 years ago

#48 closed enhancement (fixed)

Put in Text in Textfields at PDF files

Reported by: jan.thiel@… Owned by: eros2
Priority: blocker Milestone: 1.3
Component: Plugin: PDF Version:
Keywords: form write into pdf textfields save copy Cc:

Description

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

Attachments (2)

f1040.pdf (180.2 KB) - added by eros2 13 years ago.
pdfformtest.pdf (176.4 KB) - added by diver 9 years ago.
includes push buttons and more

Download all attachments as: .zip

Change History (21)

comment:1 Changed 13 years ago by ktk

  • Milestone changed from RC to 2.0 and further
  • Version 1.0 Beta 1.1 deleted

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

Changed 13 years ago by eros2

comment:2 Changed 13 years ago by eros2

Attached f1040.pdf from ticket #57

comment:3 Changed 12 years ago by eros2

comment:4 Changed 12 years ago by eros2

  • Keywords form added

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.

comment:5 Changed 10 years ago by diver

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

comment:6 Changed 10 years ago by diver

  • Milestone changed from 2.0 and further to 1.3
  • Priority changed from major to blocker

comment:7 Changed 9 years ago by 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.
  1. 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.

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by diver

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

comment:10 Changed 9 years ago by 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.

Changed 9 years ago by diver

includes push buttons and more

comment:11 Changed 9 years ago by 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.

comment:12 Changed 9 years ago by 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.
  1. 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.

comment:13 Changed 9 years ago by 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).

comment:14 Changed 9 years ago by 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.

comment:15 Changed 9 years ago by dmik

One-line text input is done. Please test.

comment:16 Changed 9 years ago by 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.

comment:17 Changed 9 years ago by dmik

Multi line input is in.

comment:18 Changed 9 years ago by 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.

comment:19 Changed 9 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.