Bug 61736 - Form controls "List Box" and "Combo Box" have no down arrows on PDF export
Summary: Form controls "List Box" and "Combo Box" have no down arrows on PDF export
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 61746 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-03-03 13:56 UTC by Norbert X
Modified: 2013-04-15 06:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT file with all form controls (14.78 KB, application/vnd.oasis.opendocument.text)
2013-03-03 13:56 UTC, Norbert X
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert X 2013-03-03 13:56:11 UTC
Created attachment 75833 [details]
ODT file with all form controls

Hello!

I was going to create a simple web-form, which contain some Labels, Text boxes, Checkboxes etc.
I created new ODT document, opened "Form Controls" Toolbar, and found needed form elements here.

I discovered that if I save a document (it is in attachment) as a PDF without "Create PDF Form" mark I get no pull-down arrows for "List Box" and "Combo Box" controls.
If I set "Create PDF Form" mark all form elements in PDF look normally.

For PDF viewing I use Evince 2.32.0 and Adobe Reader 9.5.4.

This bug exists in 4.0.0.3 (Gentoo 13 amd64).
Comment 1 Norbert X 2013-03-03 14:18:12 UTC
This bug exists in 3.5.7.2 (Ubuntu 12.04 LTS).
Comment 2 Rainer Bielefeld Retired 2013-03-03 15:20:12 UTC
User error. 

@nrbrtx:
Of course these functions only are available in a PDF form, not in a normal PDF export. Also you can't input texts, set checkmarks, activate options buttons ...
Comment 3 Norbert X 2013-03-03 15:42:54 UTC
Hello, Rainer!
As far I can understand 'Export as PDF' must work exactly as if I print document with virtual PDF printer (PDF Creator or something on Window$, CUPS in Linux).

I expect that output PDF will look like in Print preview (otherwise WYSIWYG conception is broken and I will get unexpected result).

So I reopen the bug. It's not my error, it's developer's.
Comment 4 Rainer Bielefeld Retired 2013-03-03 16:20:08 UTC
@nrbrtx (In reply to comment #3):
Please do not reopen a bug for any wrong and/or unproved expectation. If you expect a different behavior than you see always cite Help, Manuals, technical rules or similar with a link.

It seems  you do not completely understand the concept of Form Fields. For what should it be useful that the recipient of a letter can see a pulldown arrow behind "Dear Sir", because sender's .odt template contains a form field with additional "Dear Friend", Dear Friends", "Dear Madam" and so on? 

And BTW, of course printouts do not show those pulldown arrows. 

But we should think about view in Page Preview. In Print Preview (in Print Dialog) the correct final view is shown, but in page preview those elements still are shown, what might be worrying, and currently I can't see any good reason for the current behavior.

Please subscribe <libreoffice-ux-advise@lists.freedesktop.org>, what will be the right place for a discussion.
Comment 5 Norbert X 2013-03-03 16:45:56 UTC
I reported a bug about print preview too (https://bugs.freedesktop.org/show_bug.cgi?id=61742).
And I still think that WYSIWYG breakage is not a good idea.

Do you see a pull-down arrows on print preview (or PDF/paper) of this web-page (in Firefox, Opera, Chrome, MSIE, whatever)? Of course yes, it is normal and expected behavior for web forms.


I have 15 years of web-programming experience, so I completely understand Form Fields theory. 
And I think you can not say your users 'do not use LibreOffice Writer and Draw for web-form sketching'. 
If you understand this scenario, you (and other LibreOffice developers) will save pull-down arrows in Print preview and PDF/paper out. That's all.
Comment 6 A (Andy) 2013-04-10 20:51:56 UTC
*** Bug 61746 has been marked as a duplicate of this bug. ***
Comment 7 Joel Madero 2013-04-15 00:45:16 UTC
Rainer - any more feedback on this one?
Comment 8 Rainer Bielefeld Retired 2013-04-15 05:47:15 UTC
(In reply to comment #7)
NOTABUG, see below

I think there are (at least) 2 possible uses for form controls such a Combobox

a) In a Standard text you have a sentence where 2 possibilities can be selected, for example a quotation standard text with
"Without any warranty"
"2 years warranty"
Or "Mr." / Mrs. / Miss."
Of course, Author does not want to have a selector in the final printed or PDF exported text

b) questionnaires with poll results
There were several selectors, for example age of responder
"Less than 20 years " 
"21 ... 50 years"
"more than 50 years"
and similar.

It will ease to understand the contents of the document if it is visible that there was a choice (and it was not a poll only for people "21 ... 50 years"). Because the document may not be changed after it has been sent by responder, "PDF Form" is not an option. And so here a behavior different from "a" would be useful.

My conclusion:
Currently "a" is supported by LibO, "b" is not. If someone thinks that "b" (or even a different "c", "d", ...) might be useful he can submit an Enhancement Request for an additional option/function/whatever, but not to replace the existing behavior.

@nrbrtx:
If you can contribute a conclusive scenario showing that typical users of an office suite (NOT web page designers!) need such a different behavior please submit an enhancement request.
And pleas do not mix up "Print Preview" and "Page Preview" in your argumentation.

And a dentist and a plumber both might know a lot about tongs, but the experiences are not transferable. In a similar way I think web design has some needs and habits different from those in office world for what LibO is. But of course, LibO is open for good new ideas what are related to office use.
Comment 9 Rainer Bielefeld Retired 2013-04-15 06:00:48 UTC
*** Bug 61746 has been marked as a duplicate of this bug. ***