search

lizadaly / threepress

Automatically exported from code.google.com/p/threepress
Other
0 stars 0 forks source link

epub contents: xhtml file names with spaces causes epub upload to fail #164

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. create an epub where the internal files have spaces in the names
2. try and upload the epub

What is the expected output? What do you see instead?
The the /upload request fails (well, actually it's the models.py:_get_content 
routine that fails), 
saying "Could not find file test%201.html in archive even though it was listed 
in the OPF file"

By unquote_plus'ing the href attributes of the contents file, this issue can be 
avoided and epub 
files that hold items with spaces in their names can be loaded and viewed 
correctly. I've added a 
patch from svn ref 863 for reference.

Note: not sure if files with spaces in names are allowed in the epub spec, or 
if the epub validator 
passes them. I did notice that library/models.py:_get_images (approx line 507) 
uses 
unquote_plus, so I think this might be ok to put straight in.

ps: I'll start acting like a contributor and less like a user soon :) this was 
the last thing on my 
current list to knock off.

Original issue reported on code.google.com by steven.m...@gmail.com on 27 Aug 2009 at 8:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Definitely a Bookworm bug.  Thanks.  I'll apply the patch ASAP.

Original comment by liza31337@gmail.com on 27 Aug 2009 at 3:59

GoogleCodeExporter commented 9 years ago 
I was going to apply this patch (sorry so belated) but I can't actually 
reproduce the
bug. I'd tried to create a test case with file listed below, which has a 
filename
with spaces in it as the first OPS content document, and it uploads fine.

$ svn commit -m "Test for spaces in filenames"
Adding  (bin)  library/test-data/data/space-in-filenames.epub
Sending        library/tests.py
Transmitting file data ..
Committed revision 893.

I believe there's probably a bug -- can you check the test case against your 
document
and see if there's something different there?

Original comment by liza31337@gmail.com on 30 Oct 2009 at 2:13