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.