calibre-devs team mailing list archive

[Kovid Goyal <kovid@xxxxxxxxxxxxxx>]

On Sun, Apr 12, 2009 at 07:01:35PM -0400, Marshall T. Vandegrift wrote:
> On Fri, Apr 10, 2009 at 7:23 PM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:
> 
> > 1) OEBBook assumes that the OPF is at the top level of the directory structure.
> 
> > The other possible solution is to require InputPlugins to ensure that their OPF
> > files are at the top level. For most input plugins this is (I believe) automatically the
> > case, however it will require extra work for the HTML and EPUB input plugins.
> > I think this is the best solution.
> 
> I think a hybrid solution would be easiest / most sensible.  Because
> Windows drives are actualy disjoint namespaces, we can't ensure that
> all filesystem references ultimately share a common root directory to
> begin with.  I think it should be the responsibility of input plugins
> to ensure that all filenames are within a single filesystem namespace,
> then the OEBBook can normalize the book-internal absolute paths to a
> common root directory.
> 

I've fixed the HTML/OPF input plugin to both ensure all files are "packaged"
with the OPF file at the top of the tree. You get normalization to a common root
free as part of this, but feel free to implement the code in OEBBook to ensure a
common root directory with the OPF/NCX in that directory. 

If you don't want to do that I'll just go ahead and fix the EPUB input plugin 
to move the OPF/NCX to the root directory. I wont do this using the OEBBook 
infrastructure since I want the input plugins to be as fast as possible 
(they're used in ebook-viewer) and using OEBBook means the overhead of parsing 
everything. (I realize the parsing can be made on demand but I worry that once 
we allow OEBBook into the InputPlugins, the demand will arise :-). 

> > 2) OEBBook actually writes out *everything* if the input OPF does not specify a
> > cover (in order to render the "first page" as a cover).
> 
> I intended that a placeholder for implementing a
> QtAbstractFilesystemHandler which would allow all the Qt voodoo to
> operate directly on the contents of an OEBBook.  That IMHO is the
> right solution (as long as we're using Qt for HTML and SVG rendering).
> 

That would be cool in principle, but it would still mean an extra couple of
serializations, which would slow things down (cssutils in particular is slooow).
I'd also rather not tie the code even more firmly to Qt. 
And for things like Savoury more Qt dependence would be bad news. 

Having the EPUB input plugin render the cover is simpler to implement,
though less flexible. I doubt there will be many new ebook formats in the
near future, so hopefully this code will not be duplicated. 

Having said that, I operate on the principle of the Do-ocracy, so if you want to
go ahead and implement the AbstractFileSystemHandler, just say so :)

Kovid.
-- 
_____________________________________

Kovid Goyal 
http://www.kovidgoyal.net
http://calibre.kovidgoyal.net
_____________________________________

Attachment: pgpABsQNtI3lZ.pgp
Description: PGP signature