GNOME Bugzilla – Bug 766398
Problems with form fields
Last modified: 2018-05-22 16:39:11 UTC
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 N.B. There are many more bugs I've noticed in this PDF. Should I list them here in the comments or file each one separately?
Created attachment 327829 [details] test file
very good test case. Some of the bugs should be in Evince some of the bugs will be in poppler. This in particular is in poppler. you can change the name of the bug to Problems with Text fields and enumerate the bugs here.
Oh, I didn't realize poppler was also the backend in Evince -- mainly because I filed a bug against Okular earlier (https://bugs.kde.org/show_bug.cgi?id=362765) and it turned out to be a poppler bug.. but since Evince didn't manifest the bug, I assumed the backend was different.. Anyway, here are some bugs that I've noticed so far from the 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 * after editing, text field's gray border/outline is removed * hidden fields are editable (although you have to know where to click to find them) * fields with "scrollable" flag don't seem to be scrollable (this may be because font size is "auto" ?) * fields with "spell check" flag don't highlight spelling mistakes * 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 Minor: * 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 what the result will look like until she submits the changes (radio buttons do this, YAY!) 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)
Ref poppler bug https://bugs.freedesktop.org/show_bug.cgi?id=95391
Created attachment 327910 [details] test file #2 Update: created another copy of the document, with fixed-size input text. This is a workaround for the 1st bug, "font size is changed" + "listbox" Although there should be no reason to cut off some letters in "auto" mode, anyway Further bugs: * Font position is changed slightly when edited. Usually not very noticeable, but if you try to add a space to any line of multi-line scrollable input, you can see that the text fits differently from original rendering. May -or- may not be related to border-is-missing-after-editing bug * List box style is changed after editing. Before editing, highlighted value is blue; after editing it's black. Coupled with the bug right above, it makes the input change significantly. ** Similarly, combo box loses its down arrow indicator * Cursor changes when user hovers on a Signature input, but no action happens when it's clicked. If there are no plans to support this feature, maybe at least print a warning message explaining as much? * Scrollable fields are not scrollable in either view or edit modes. Not sure if they should be "scrollable" in view mode (would they be actually scrollable or just have an image of a scroll bar?) ** Some frontends (e.g. Okular) give all multi-line inputs scroll bars in edit mode -- I think that makes sense.
Ref Okular bug: https://bugs.kde.org/show_bug.cgi?id=363091
Can someone go through and separate which ones might be the same bug and which ones need to be reported upstream to poppler?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/677.