<html>
<head>
<base href="https://bugs.documentfoundation.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_UNCONFIRMED "
title="UNCONFIRMED - Print to File writes to incorrect file"
href="https://bugs.documentfoundation.org/show_bug.cgi?id=122075">122075</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Print to File writes to incorrect file
</td>
</tr>
<tr>
<th>Product</th>
<td>LibreOffice
</td>
</tr>
<tr>
<th>Version</th>
<td>6.1.2.1 release
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>UNCONFIRMED
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Printing and PDF export
</td>
</tr>
<tr>
<th>Assignee</th>
<td>libreoffice-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>karllinuxtest.relton@ntlworld.com
</td>
</tr></table>
<p>
<div>
<pre>Description:
This bug only occurs when using the GTK3 dialogues (libreoffice-gtk3
installed), and when PDF is the print-job language.
Under certain conditions print to file over-writes an existing pdf file in the
chosen folder which doesn't match the name chosen by the user (and without any
warning or confirmation dialog).
Steps to Reproduce:
Steps to reproduce are:
1) Create an empty directory (folder)
2) Put in directory a dummy pdf (e.g. touch sample.pdf)
3) Open libreoffice and create a writer document with a few words
4) Save the libreoffice document to the directory as a regular writer doc (e.g.
'test.odt')
5) Do 'File -> Print' and choose 'Print to File'
6) In the (gtk3) File-chooser dialog:
6a) navigate to the folder created in step 2
6b) select 'Any Type' in the 'types of file shown' selector
6c) click on the file name 'test.odt'
6d) in the 'Name' text field, then edit the name from 'test.odt' to
'test_2.pdf'
6e) then press 'Enter' (or click on 'Select')
7) Observe that in the folder there is no file 'test_2.pdf'. However the dummy
file 'sample.pdf' has been over-written and contains the pdf that resulted from
the 'print to file' operation
Actual Results:
Observe that in the folder there is no file 'test_2.pdf'. However the dummy
file 'sample.pdf' has been over-written and contains the pdf that resulted from
the 'print to file' operation
Expected Results:
What should of happened is that the file 'test_2.pdf' should have been created
as a pdf of the writer document.
Reproducible: Always
User Profile Reset: No
Additional Info:
The bug appears to be a problem with the 'File Type selector' button. If
(having done steps 1 to 6d above) you then manually change the file type
selector back to 'Portable Document Format' you will see:
a) it loses your modified name in the Name type-in field
b) it chooses a name in the list of pdf files in the folder, and selects that
That shouldn't happen, because it means the user loses his/her file name they
entered.
I suspect that when 'Save' is pressed, the file type selector is being
triggered to change automatically to 'Portable Document Format' which is then
changing the selected file name ... as a race again the 'Save' operation
actually happening.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>