I am using ubuntu 10.04 (i386), and the bug is present in both OpenOffice-3.2 and LibreOffice-3.3rc1 How to reproduce: 1. create a document named "test [en].odt" 2. inside the document, insert the field "File name" -> "File name" 3. the field displayed is "test %5Ben%5D.odt" Note: there are no bugs for the other fields under "File name" - "File name" -> "File name without extension" returns correctly "test [en]" - "File name" -> "File name path" returns the correct path* "/home/xxx/Desktop" - "File name" -> "Path/File name" returns the correct full path* "/home/xxx/Desktop/test [en].odt" * even if the path contains "[" or "]"
I suppose this might fit the 'EasyHacks' category - worth checking in the code, if it is only missing the conversion back from URL into a 'readable' filename.
Created attachment 41512 [details] [review] A first attempt at fixing this bug. I have seen that all other fields eventually end up calling INetURLObject::decode with INetURLObject::DECODE_WITH_CHARSET. I have changed the code to use INetURLObject::DECODE_WITH_CHARSET for FF_NAME too. I have tested it and it works as expected. A review will be appreciated.
Seems perfectly reasonable to me, especially given the behaviour of the field entry which returns the name without the suffix
Checked in your fix now, and added a cppunit test case in sw/qa/core for those SwFileNameFields
EasyHack tags unification: only allowed in Whiteboard to make queries more easy and reliable
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.