View Single Post
Old 04-12-2011, 07:24 PM   #12
user_none
Sigil & calibre developer
user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.user_none ought to be getting tired of karma fortunes by now.
 
user_none's Avatar
 
Posts: 2,488
Karma: 1063785
Join Date: Jan 2009
Location: Florida, USA
Device: Nook STR
Quote:
Originally Posted by KevinH
It seems that .htmlz is not listed as an ebook extension
Fixed.

Quote:
Originally Posted by KevinH
TypeError: must be convertible to a buffer, not lxml.etree._Element
Fixed. I didn't realize SVG data would be returned in such a manner. Image writing now accounts for this.

Quote:
Originally Posted by KevinH
I looked at the debug output of the conversion and notices that the style.css that I am passing in seems to get converted into a .xhtml (wrapped with its own <html><head><body> etc even though it is a normal linked css (without any namespace declaration).
This is happening as part of the ZIP input stage. I even tried adding a namespace declaration and it doesn't make a difference. I'm not sure why this is happening I'm seeing this for the messages:

Code:
Flattening CSS and remapping font sizes...
style.css contains data in TXT format converting to HTML
Converting style.css ...
Parsing style.css ...
Forcing style.css into XHTML namespace
Stylesheet 'style.css' referenced by file 'book.html' is not CSS
However, it doesn't appear to be an issue in the final output. The CSS appears to be handled properly and is being written correctly in the HTMLZ output.

Since this is in the ZIP input stage it's going to happen no matter what output is used. Kovid will need to weigh in on this and say if it's an issue or not.

Quote:
Originally Posted by KevinH
And of course none of the metadata or cover were recognized upon import.
I have the metadata reading hardcoded to read from a file called metadata.opf. I will change this to use the first OPF file found instead. I will also add cover support to the metadata reader and writer.
user_none is offline   Reply With Quote