1. File - Print 2. Print to file, multiple copies Observe created PDF: it has only a single copy. For comparison, Microsoft PDF Printer produces multiple copies in a single PDF. First mentioned in bug 128032. Seems to have always been like this.
I cannot imagine a situation that would justify this bug request, when would you need multiple copies inside PDF. If you need multiple copies, you print them from PDF. So, this would be "I reproduce what you say, but you didn't explain why it's a bug". Repro from OO. With 6.0 we would get multiple Save As windows (also makes not sense). Repro again with 6.2.8 and 7.0+. Also reproduced with MSO printing to virtual PDF printer PDFill and PDFcreator. I don't have Microsoft Print to PDF to test. So I have doubts that this is a bug and if it's NotOurBug.
(In reply to Timur from comment #1) > Repro from OO. With 6.0 we would get multiple Save As windows (also makes > not sense). Repro again with 6.2.8 and 7.0+. > Also reproduced with MSO printing to virtual PDF printer PDFill and > PDFcreator. I don't have Microsoft Print to PDF to test. MS Print to PDF comes with Win 10.
Dear Buovjaga, 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
Use case was not explained, not independently confirmed.
(In reply to Timur from comment #4) > Use case was not explained, not independently confirmed. Use case was to harmonise behaviour with Microsoft PDF Printer and the confirmation is inherited from bug 128032.
I agree it's possible to workaround by printing n times the pdf, but I think it's up to the user to decide. It's not as if there was additional code for this, it's rather a limit that's been added (I'm still searching where in the code). If you really don't want the user choose a number more than one, we should disable the option then when "print to file" is selected. As it is, it's unexpected (and so buggy) to be able to choose n>1 with print to file and LO doesn't apply it. => let's ask UX eval to know what would be the more appropriate here: 1) disable the "number of copies" option when printing to file 2) let it enabled but apply it 3) Other idea?
For sake of simplicity I'd disable the option. Don't see a good use case to create multiple files.
(In reply to Heiko Tietze from comment #7) > For sake of simplicity I'd disable the option. Don't see a good use case to > create multiple files. Ok for me but just to be sure here, it's not about creating multiple files but to generate a pdf (not several ones) containing n times (the number of copies) the content of a file.
(In reply to Julien Nabet from comment #8) > Ok for me but just to be sure here, it's not about creating multiple files > but to generate a pdf (not several ones) containing n times (the number of > copies) the content of a file. Good point. Do you have an use case for this?
(In reply to Heiko Tietze from comment #9) > (In reply to Julien Nabet from comment #8) > > Ok for me but just to be sure here, it's not about creating multiple files > > but to generate a pdf (not several ones) containing n times (the number of > > copies) the content of a file. > > Good point. Do you have an use case for this? Personally no, but sometimes users have needings we don't think about. If we really think it's useless, let's disable number of copies when PDF printer chosen at least that's clear. I really see it as the principle of least astonishment. If you let this option with PDF printer, LO should just apply what's demanded.
I'm afraid of this band aid to be a source of trouble later. Like the state not being updated correctly. Talked to Ilmari and we maybe close this non-issue until a user comes with a clear use case.
(In reply to Heiko Tietze from comment #11) > I'm afraid of this band aid to be a source of trouble later. Like the state > not being updated correctly. Talked to Ilmari and we maybe close this > non-issue until a user comes with a clear use case. I'm strongly disagree here. If you think since there's no use case LO shouldn't use n copies in a pdf file, why not disabling the option instead of letting this as it is?
(In reply to Julien Nabet from comment #12) > why not disabling the option instead of letting this as it is? It's a rather academic topic with no clear issue from users. A solution adds complexity, think of a people who see the code to disable the number of copies in 10 years, and has the danger of being not perfect, for example the state is not updated correctly. But feel free to reopen.
(In reply to Heiko Tietze from comment #13) > (In reply to Julien Nabet from comment #12) > > why not disabling the option instead of letting this as it is? > > It's a rather academic topic with no clear issue from users. A solution adds > complexity, think of a people who see the code to disable the number of > copies in 10 years, and has the danger of being not perfect, for example the > state is not updated correctly. But feel free to reopen. Ok let's not annoy people who may be disturb by this. In this case, there's already a complexity here since LO specifically doesn't respect "n copy entries" for pdf output. So let's follow KISS principle, we should just let a user choose to put n times the same content on the pdf without wondering if it's sensible or not so no need to search a use case here.
Agree with Buovjaga and Julien here: to make it consistent and to keep it simple. Furthermore, two use cases: 1) PDF needs to be sent to be printed via an interface that does not offer many options. My University had such a service: a website to send a job to networked printers, in which it wasn't possible to, for example, have several pages per sheet (imagine you're printing A6 flyers). One would have to prepare the PDF beforehand. 2) QA usecase: we can't keep printing paper to test issues, for obvious reasons. Therefore, we need Print to File to be as close as possible to Print to Paper.