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:
3.in spool, look at the title
title in spool without extension
title in spool with extension
User Profile Reset: Yes
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
Code pointer: http://opengrok.libreoffice.org/xref/core/vcl/unx/generic/print/printerjob.cxx#361
I am lay in it yet. What do I do with this?
(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.
Ok, how to fix it?
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?
(In reply to tvallois from comment #5)
> 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.
(In reply to Samuel Mehrbrodt (CIB) from comment #1)
> Code pointer:
The problem seems to be on http://opengrok.libreoffice.org/xref/core/vcl/unx/generic/print/genprnpsp.cxx:1027 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?
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.
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 :'(
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.
Does the original bug reporter have any follow-up comment to my comment #8? Rodrigo, hello?
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?
I think you did not understand my comment #8. The file name extension is meaningless and arbitrary.
I understood your comment, but as I said, I wish the file extension would not be removed when the document was spooled
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.
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.
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.
Of course! I agree with you. But as I said, it's a third party system. Thank you.
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
http://dev-builds.libreoffice.org/daily/ 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.