View Single Post
Old 04-12-2011, 08:19 PM   #15
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,809
Karma: 6000000
Join Date: Nov 2009
Device: many
Hi user_none,

Thanks for taking the time to look at and fix this!

KevinH


Quote:
Originally Posted by user_none View Post
Fixed.



Fixed. I didn't realize SVG data would be returned in such a manner. Image writing now accounts for this.



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.



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.
KevinH is online now   Reply With Quote