calibre-devs team mailing list archive

["Marshall T. Vandegrift" <llasram@xxxxxxxxx>]

Forwarding messages I accidentally didn't send to the list, just in
case anyone else is/starts paying attention...

Does launchpad have an option to set the Reply-To header for list messages?

---------- Forwarded message ----------
From: Marshall T. Vandegrift <llasram@xxxxxxxxx>
Date: Tue, Dec 23, 2008 at 1:40 PM
Subject: Re: [Calibre-devs] Unified conversion tool
To: Kovid Goyal <kovid@xxxxxxxxxxxxxx>


On Tue, Dec 23, 2008 at 12:36 PM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:

> Let me stop you right there and ask, why?

Flexibility and ease of extension.

> The way I envison all future converters working is:
>
> They call any2epub, and then convert the resulting EPUB to whatever
> format.  That means all content manipulation modules are automatically
> reused (as part of any2epub), and can be controlled by any2epub's
> options (which all of them will share).

The main issues I have with this approach are that it tightly couples
transforms with the infrastructure and artificially distinguishes
"general" transforms and "format-specific" transforms.  For example,
right now I'm working on CSS flattening for LIT generation.  If I add it
to just the LIT-generation code, it isn't available when generating
other formats for which it might be useful (it's much easier while
flattening to scale fonts and correct from renderer-specific CSS quirks,
and flattening produces CSS optimized to minimize complexity, which can
improve rendering speed).  Adding it to any2epub means yet another
any2epub option which is manually linked to yet another decision branch
in the any2epub logic.

The approach I'm proposing separates independent parts of conversion
logic into independent modules.  This makes it easier to reason about
the system as a whole, and easier to add new and/or custom steps to a
conversion process or generation pipeline.

> I'd really rather not end up with a completely unusable mess like the
> CLI to the various video encoders.

Ok, perhaps mplayer was a bad example.  What I want from the interface
is something which allows completely independent logic like "font
embedding" or "margin setting" to be referenced in a way which doesn't
require hard-coded references to them in the conversion logics.

But there's no reason the current command-line interfaces couldn't be
used to access a more modular, flexible infrastructure under the hood.

> We can certainly make the transformation modules output format
> independent, but I don't think we need a CLI for them, since
> presumably each output format converter knows what transformations it
> needs.

I think what I'm getting toward is a good idea, and I'm going to try to
work it out in parallel with Mobipocket-generation support, although
I'll make sure they're independent.  I think some concrete code will be
more convincing than my insane ramblings. :-)

-Marshall