Bug 363091 - Problems with form fields
Summary: Problems with form fields
Status: RESOLVED NOT A BUG
Alias: None
Product: okular
Classification: Unclassified
Component: PDF backend (show other bugs)
Version: 0.24.0
Platform: Other Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-15 01:31 UTC by Konstantin Svist
Modified: 2016-05-16 22:15 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
test file (43.82 KB, application/pdf)
2016-05-15 01:31 UTC, Konstantin Svist
Details
test file #2 (44.17 KB, application/pdf)
2016-05-15 01:32 UTC, Konstantin Svist
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Svist 2016-05-15 01:31:24 UTC
Created attachment 98978 [details]
test file

See attached document, field "180 deg" (left-middle of the page)
Pre-filled text appears properly, but if changed, text is not displayed for this field at all.

Evince devs tell me this is a poppler bug, but apparently even poppler bug can be dependent on the frontend...


Other bugs in the attached document:


Major:

* font size is changed when default text is changed. Try entering letters that have descenders: g,j,p,q,y -- they appear cut off
** this is especially bad in a list box -- try selecting item 3
** Note: in test2.pdf the font sizes are fixed - that works around this bug. However, there should be no reason to cut off some letters in "auto" mode.

* after editing, text field's gray border/outline is removed

* List box style is changed after editing. Before editing, highlighted value is blue; after editing it's black. Coupled with the bugs right above, it makes the input change significantly.
** Similarly, combo box loses its down arrow indicator

* hidden-but-printable field is editable

* single-line field with "spell check" flag does not highlight spelling mistakes (multi-line one does, KUDOS! most other frontends don't)

* fields with "rich text" flag don't accept rich text (test by copy/pasting HTML content from some page rendered in 
a browser -- tables, colors, links, formatting.. should be copied over)

* Field format specifications are ignored after any editing:
** all are rendered as plaintext -- no format decorations are applied
*** "number" should insert thousands separators and 2 digits after the decimal separator
*** "currency" setting often uses parentheses and red text to highlight negative amounts. This does not apply to positive amounts
*** "phone" should be rendered in a region-dependent way. In NA, it might be something like "+1(234)567-8901" 

** no validation is performed:
*** "number" should only allow digits and up to 1 decimal separator (can safely ignore thousands separators)
*** "phone" should only allow digits (this may be much more region-dependent, though)

* radio buttons are ignoring "reset form" on "mouse up" action -- so once a radio button is checked, it stays checked

* while zoomed in a lot, user can see "export value" of radio and check buttons -- in the document, they're all "Yes". There's no reason to show these to the user.


Minor:

* fields with "scrollable" flag don't seem to be scrollable in view mode (not sure if they should be; would they be actually scrollable or just have an image of a scroll bar?)

* no tooltips are displayed on any form fields

* 90- and 270- degree text fields look very inconvenient in edit mode - the editable field tries to fit into the rendered version, and ends up being tiny (just 3 letters-wide in the test case)

* While editing, user can't see exactly what the result will look like until she submits the changes.
** The thumbnail view is updated after a short delay -- that's helpful but of limited use, since thumbnail is usually so small and sometimes not shown by default.
** Check/radio buttons are visible in the actual document.. why not make them editable as-is instead of an ugly overlay? Evince does this already. Ideally, all fields should be editable in the style which will be rendered (or very close to it)

* Signature input is not recognized at all. If there are no plans to support this feature, maybe at least highlight it and issue a warning message explaining as much?


RFE:

* there's no way to highlight form fields (may be desired in a complicated document so user doesn't have to guess where the input fields are)
** required field should be highlighted with emphasis (usually pink/red shading)


For reference:
Poppler bug: https://bugs.freedesktop.org/show_bug.cgi?id=95391
Evince bug: https://bugzilla.gnome.org/show_bug.cgi?id=766398
Comment 1 Konstantin Svist 2016-05-15 01:32:17 UTC
Created attachment 98979 [details]
test file #2
Comment 2 Albert Astals Cid 2016-05-16 22:15:35 UTC
Thanks for caring about form support in okular, but reporting 1453 issues in the same bug entry is not good behaviour, it makes keeping track of what is fixed, what is not, and the answers/questions for each individual issue impossible.

Please report every problem you find in a separate bug.