It's not so uncommon to have "Print to File" together with the actual printers (and it's kind of obsolete with all the export to PDF options). Besides, we need all space and adding a radio button for this is going the wrong direction. => NAB/WF.

(In reply to Heiko Tietze from comment #1)
> It's not so uncommon to have "Print to File" together with the actual
> printers (and it's kind of obsolete with all the export to PDF options).
> Besides, we need all space and adding a radio button for this is going the
> wrong direction. => NAB/WF.

That was surely not my point :-). Fine with both options in one dialog. Never pretended otherwise. 

There are two problems IMHO
1) The usage of the radio button way (to make it possible to set settings for either Printer or Print to file is atypical usage of radio button (on Windows, as far I know). And the radio button is even not used this way in LibreOffice that often. I'm more used to a drop down box. With disadvantage of 'hiding' to printer from sight

2) There is no visual supporting effect when picking one of both. So you don't notice you're in a 'different' dialog. Th


Yes, advantage of a radio button is both options are visible from the start. However it's but atypical usage of radio button (on Windows, as far I know). And not even the most common why used on LibreOffice either. 

Yes, it's surely a detail :-).

And show you surprising my every time :-). I often get a feeling of some kind of a "Reality distortion field"; I'm talking about A and I get not B or even C but Z. What the heck.

Hmm... I dislike both ways. One is the "Options->LibreOffice->Print" raised here, where the radio button is indeed used incorrectly: radio button designates one of a set of mutually exclusive options, and having it on the page looks as if one may only set up one set of options: e.g., either for Printer, or for Print to file, but not both (while in reality, the page is exactly to configure both, each set is configured when the relevant radio button is active).

However, the crop down box - as seen on Options->Load/Save->General, in "Document Type" that controls the "Always Save As" below, is also confusing, and does not suggest users that each of its position corresponds to relevant setting. I remember multiple questions of users like "I had set up format for text document, but how do I set up format for spreadsheet documents?"

In case of the simple options like "Document Type", it could be useful to use the conception like Application Colors has, with a list box with entries and corresponding drop down lists in each line. But for the print settings discussed here in this bug, a tabbed interface fits much better, with two tabs - for Printer, and for Print to File.

(In reply to Mike Kaganski from comment #3)
> In case of the simple options like "Document Type", it could be useful to
> use the conception like Application Colors has, with a list box with entries
> and corresponding drop down lists in each line. But for the print settings
> discussed here in this bug, a tabbed interface fits much better, with two
> tabs - for Printer, and for Print to File.

Why didn't I think of that ;-)

Stupid me, argued having the print dialog in mind where switching between printers and print to file is done per dropdown. But this is about Tools > Options > Print!

Switching to Print to File disables the "PDF as standard" checkbox, switches Reduce bitmaps/gradients on, transparency off, How about just removing the radio buttons? Is the use case to have of frequently switching between print on paper and print on file with different settings relevant enough to maintain this? The alternative is to change the settings in the print dialog.

Discussed this in the design meeting. Still believe we don't need extra options. Users typically don't print to file but export to PDF and it's unclear whether this applies to both.

Dear Telesto,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug