[Okular-devel] [okular] [Bug 363091] New: Problems with form fields

[Konstantin Svist via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=363091

            Bug ID: 363091
           Summary: Problems with form fields
           Product: okular
           Version: 0.24.0
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: PDF backend
          Assignee: okular-devel at kde.org
          Reporter: fry.kun at gmail.com

Created attachment 98978
  --> https://bugs.kde.org/attachment.cgi?id=98978&action=edit
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

-- 
You are receiving this mail because:
You are the assignee for the bug.