Bug 73462 - Libre Office SDK not able to convert files having special character #,$
Summary: Libre Office SDK not able to convert files having special character #,$
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-10 05:46 UTC by Vikram
Modified: 2015-07-18 17:27 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vikram 2014-01-10 05:46:13 UTC
Hello All,

Libre Office SDK 4.1 is not able to convert the files to PDF having # and $ in their file names. It fails at following point when using SDK API, 
Reference <XComponent> xOfficeComponent :: loadComponentFromURL.

Urgent help is really appreciated.

Regards
Viks
Comment 1 Stephan Bergmann 2014-01-10 12:57:13 UTC
loadComponentFromURL takes a URL as input, not a file system pathname, and "#" has special meaning in URLs, and must thus be escaped ("%23").  Not sure without looking further into it what the problem with "$" would be, maybe there's some code somewhere inside loadComponentFromURL that wants to expand "$"-prefixed macro names in the passed-in URL; quickfix would likely be to also esacpe "$" ("%24").
Comment 2 vicky 2014-01-12 11:18:17 UTC
Hi

I have escaped the # and $ with %23 and %24, but if i have something like test%23#, test%24$, or test%23$%24$, it fails at following point when using SDK API, Reference <XComponent> xOfficeComponent :: loadComponentFromURL.

Regards
Viks
Comment 3 Stephan Bergmann 2014-01-13 07:47:04 UTC
(In reply to comment #2)
> I have escaped the # and $ with %23 and %24, but if i have something like
> test%23#, test%24$, or test%23$%24$, it fails at following point when using
> SDK API, Reference <XComponent> xOfficeComponent :: loadComponentFromURL.

So what exactly is your file system pathname, and what URL are you feeding into loadComponentFromURL?  If your (Unix-style, say) pathname is

  /home/me/somewhere/test#.odt

then the corresponding URL is

  file:///home/me/somewhere/test%23.odt
Comment 4 Vikram 2014-02-02 15:43:05 UTC
Hello

It is diffcult to add %23, as there can be user name file also test%23#.doc. In that case it is difficult to maintain this kind of analogy. Lots of permudation can be possible in file name.

Regards
Vikram
Comment 5 Stephan Bergmann 2014-02-03 11:00:06 UTC
(In reply to comment #4)
> It is diffcult to add %23, as there can be user name file also test%23#.doc.

Please read up on how URIs in general and file URLs in particular work.  (A filename test%23#.doc would end up encoded as test%2523%23.doc in a file URL.)
Comment 6 Vikram 2014-02-20 09:23:10 UTC
Hello

File name having url test#.doc was renamed as test%23.doc, test###.doc to test%23%23%23.doc, test#$.doc to test%23%24.doc
On converting these documents to PDF, corrupt files gets genearetd which do not have any extension

Libre Office should have produce PDFs:test#.pdf, test###.pdf and test#$.pdf respectivrly but it forms file with name 'test' in each case with no file type.

Regards
Vikram
Comment 7 Stephan Bergmann 2014-02-20 09:26:50 UTC
(In reply to comment #6)
> File name having url test#.doc was renamed as test%23.doc, test###.doc to
> test%23%23%23.doc, test#$.doc to test%23%24.doc
> On converting these documents to PDF, corrupt files gets genearetd which do
> not have any extension

Hard to comment on this without seeing your code.
Comment 8 Vikram 2014-02-20 09:37:18 UTC
Hello

APIs calls made are:
1. loadComponentFromURL
2. storeToURL

are being use for conerting docuemnt to PDF. If file name does not have '#', '$', then pdf is formed correctly otherwise corrupt file is forming.

Regards
Vikram
Comment 9 Stephan Bergmann 2014-02-20 09:45:41 UTC
(In reply to comment #8)
> APIs calls made are:
> 1. loadComponentFromURL
> 2. storeToURL
> 
> are being use for conerting docuemnt to PDF. If file name does not have '#',
> '$', then pdf is formed correctly otherwise corrupt file is forming.

Attaching a minimal, working reproducer here would make it much more likely that somebody will actually look at the problem.
Comment 10 Vikram 2014-02-20 10:00:38 UTC
Hello

Similar iisue is oberved while converting files to  PDF with libre office SDK/Editor.

Reg
Comment 11 Vikram 2014-02-20 10:37:59 UTC
In reply to comment
>> Hard to comment on this without seeing your code.
>>Attaching a minimal, working reproducer here would make it much more likely >>that somebody will actually look at the problem.

Prblem with API storeToURL, is not converting files with special characters is generating corrupt files, if files is not having specail characters is not converting to pdf properly.

If API is able to convert all the possible character to pdf and not special characters file names then above comments are strange observations
Comment 12 Joel Madero 2014-06-02 20:12:59 UTC
This is not a critical bug - critical means data loss/crashes/etc... this is just a normal bug. Marking accordingly. Please do not set to critical again. For more information feel free to email the QA list about priorities.
Comment 13 Robinson Tryon (qubit) 2014-11-13 00:36:05 UTC
(In reply to Stephan Bergmann from comment #9)
> (In reply to comment #8)
> > APIs calls made are:
> > 1. loadComponentFromURL
> > 2. storeToURL
> > 
> > are being use for conerting docuemnt to PDF. If file name does not have '#',
> > '$', then pdf is formed correctly otherwise corrupt file is forming.
> 
> Attaching a minimal, working reproducer here would make it much more likely
> that somebody will actually look at the problem.

Vikram: Please attach some example code here (or give a pointer to a repo online).

After you've done that, please change the status back to 'UNCONFIRMED'. Thanks!

Status -> NEEDINFO
Comment 14 QA Administrators 2015-06-08 14:28:46 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INVALID
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

This NEEDINFO Message was generated on: 2015-06-08

Warm Regards,
QA Team
Comment 15 QA Administrators 2015-07-18 17:27:23 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO

Message generated on: 2015-07-18