Download it now!
Bug 104008 - Extension removed from document title in print
Summary: Extension removed from document title in print
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
(earliest affected)
Hardware: All All
: medium trivial
Assignee: tvallois
Whiteboard: target:5.4.0
Keywords: difficultyBeginner, easyHack, skillCpp, topicUI
Depends on:
Reported: 2016-11-18 11:30 UTC by RMA3
Modified: 2017-02-14 08:57 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

spool do windows (6.07 KB, image/png)
2017-01-03 11:09 UTC, RMA3

Note You need to log in before you can comment on or make changes to this bug.
Description RMA3 2016-11-18 11:30:06 UTC
Extension removed from document title in print.
To identify the application used in print auditing systems some "tags" are used in the document title, for example the extension. When printing from LibreOffice, the document title extension is removed making it difficult to identify the application.

Steps to Reproduce: document;
2.print document; spool, look at the title

Actual Results:  
title in spool without extension

Expected Results:
title in spool with extension

Reproducible: Always

User Profile Reset: Yes

Additional Info:
Happens on Windows and Linux, untested MAC

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Comment 1 Samuel Mehrbrodt (CIB) 2016-11-18 12:19:51 UTC
Code pointer:
Comment 2 RMA3 2016-11-18 13:07:04 UTC
I am lay in it yet. What do I do with this?
Comment 3 Samuel Mehrbrodt (CIB) 2016-11-18 14:03:03 UTC
(In reply to RMA3 from comment #2)
> I am lay in it yet. What do I do with this?

Nothing, except you want to fix it.
Comment 4 RMA3 2016-11-18 15:29:05 UTC
Ok, how to fix it?
Comment 5 tvallois 2016-12-22 10:56:34 UTC

I'm new to LO debug. I'm working on this bug but i have some problem to debug this with gdb. Can you give me more information about the process to do to debug this?

Moreover, are the comments from line 361 to 369 linked to this bug? If yes, can i have more explanation?

Thanks !
Comment 6 jani 2016-12-23 07:46:34 UTC
(In reply to tvallois from comment #5)
> Hi
> I'm new to LO debug. I'm working on this bug but i have some problem to
> debug this with gdb. Can you give me more information about the process to
> do to debug this?
If you work on this bug, you should assign it to yourself, so it is removed from the list of open easy hacks.

For debugging have a look at:

you might also take a look at:

> Moreover, are the comments from line 361 to 369 linked to this bug? If yes,
> can i have more explanation?
No, that looks quite unrelated.

have fun.
Comment 7 tvallois 2016-12-27 11:19:36 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #1)
> Code pointer:
> cxx#361


The problem seems to be on where i_rJobname dosen't have any extension. I suppose this is a normal behaviour. Should I add the extension on the function StartJob or should I add it on i_rJobname directly?
Comment 8 Tor Lillqvist 2016-12-28 22:05:58 UTC
Note that the basic expectations in the initial comment seem wrong in a scary way to me.

If some "auditing" is involved at some site, presumably that then means some workflows will be "prohibited". (Like, "you are not allowed to print files called 'secret-report- *.doc'".) That then will automatically mean there will sooner or later be an incentives for some people to "work around" the auditing/limitation.

LibreOffice does not rely on the file name extension of a document to load it correctly. You can for instance rename a file with the extension .odt to have the extension .xls instead, and LibreOffice will open it just fine, as a Writer document.

Thus any "auditing" based on what the document file name extension happens to be will be unsafe and easily worked around. And trust me, people will figure it out. In general users are always more clever than what system admins and bureaucrats expect when it comes to working around annoying limitations.
Comment 9 tvallois 2016-12-31 19:07:08 UTC
I have some problem to analyse where PspSalPrinter::StartJob's parameters are setted. Gdb say that i'm already on the top of the stack...
Need help :'(
Comment 10 jani 2016-12-31 19:11:06 UTC
you are aware that you need to run twice in gdb, first time to load symbols, sencond time to hit your breakpoint ?

hint: come on IRC ask ask.
Comment 11 jani 2016-12-31 19:11:16 UTC Comment hidden (obsolete)
Comment 12 Thibault.vallois2661 2017-01-03 01:15:35 UTC
Comment 13 Tor Lillqvist 2017-01-03 08:22:52 UTC
Does the original bug reporter have any follow-up comment to my comment #8? Rodrigo, hello?
Comment 14 RMA3 2017-01-03 11:09:20 UTC
Created attachment 130107 [details]
spool do windows

@Tor Lillqvist, hello and sorry for the delay in answering.
About your comment #8, I know all this but this system of audit of impression is of third and looks for information in the own operating system.
Attached is an image with two prints, the "test" is an ods file and "test2" is an xlsx (Excell) file. There it shows that the impression of ods has no extension and this is necessary.
Can you put in to show the extension?
Comment 15 Tor Lillqvist 2017-01-04 08:41:51 UTC
I think you did not understand my comment #8. The file name extension is meaningless and arbitrary.
Comment 16 RMA3 2017-01-04 10:09:39 UTC
I understood your comment, but as I said, I wish the file extension would not be removed when the document was spooled
Comment 17 Tor Lillqvist 2017-01-04 11:03:25 UTC
But a document being edited inside LibreOffice does not have any inherent format (and thus, nominal file extension). Once a document has been loaded into LibreOffice, its "file name" (and file name extension) and "format" are just ancillary information, there is nothing in the document data structure as such that would be of a specific format.

And what if one creates a new document, and pastes into it content from one or several documents, but never saves it. That document has no file name association in any way.
Comment 18 RMA3 2017-01-04 11:25:32 UTC
Ok, I understand but can you leave the file extension when sending it to print? I added an attachment showing how a printout of LibreOffice Calc and Office Excel is in the spooler.
Comment 19 Tor Lillqvist 2017-01-04 11:43:00 UTC
I am not opposed to the patch; I just am afraid that people will next then start screaming that "LibreOffice enables users to cheat our printing auditing system by claiming text documents are spreadsheets" etc.

But as long as everybody understands that the file name extension told to the print spooler is in no way guaranteed to indicate what kind of document it actually is, fine.
Comment 20 RMA3 2017-01-04 11:44:46 UTC
Of course! I agree with you. But as I said, it's a third party system. Thank you.
Comment 21 Commit Notification 2017-01-09 07:14:42 UTC
thvallois committed a patch related to this issue.
It has been pushed to "master":

tdf#104008: whole file name (file extension) for print job

It will be available in 5.4.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.