calibre-devs team mailing list archive

[Kovid Goyal <kovid@xxxxxxxxxxxxxx>]

No real difference of opinion here. You basically want the transformation code 
modularized and called as need by the various input/output subsystems. That is 
fine by me, except that I don't want this to have a user interface. I think 
such an interface would just make everything unusable. And really the authors 
of the input/output subsystems can be the judges of how much of this 
functionality to expose for user modification. 

Co-incidentally, I'm in the middle of developing a plugin framework for 
calibre. See the code in calibre.customize (I've committed a partially working 
implementation). I'd initially envisaged this as a way of allowing 3rd party 
developers to easily add features to calibre, but there is no reason we cant 
use to to modularize the transformation code into plugins with well defined 
and documented interfaces. 

Kovid.


On Tuesday 23 December 2008 15:31:37 Marshall T. Vandegrift wrote:
>
> Ok, it looks like we have a fairly similar concept of how this could
> work.  I'd just modify it as follows:
>
>  - Layer 1: Consolidate existing metadata and structure from the source
>    content, producing at least an internally consistent OEB structure.
>
>  - Layer 2: Perform transformations.  I think the distinction between
>    format-neutral and format-specific transformations is artificial and
>    limits flexibility.  It creates artificial barriers for sharing of
>    highly similar "format-specific" transforms, and prevents a pipeline
>    from ordering any format-neutral transforms after format-specific
>    ones.  For example, "ugly-printing" HTML to remove extraneous
>    whitespace will be necessary for both LIT and Mobipocket, and is
>    best done after the markup structure is fully processed into the
>    form it will be serialized as.  Adding user-specified/-directed
>    metadata can also be done as a transform.
>
>  - Layer 3: Write to the output file, serializing the OEB content and
>    encapsulating the fully-transformed OEB structure in the
>    format-specific container.
>
> > So Layer 1 is common to all tools. Layers 2 and 3 will have well
> > defined interfaces behind which there will be format specific plugins.
>
> With my proposal, format-specific conversion tools would specify the set
> of transformations users can sensibly apply.  Even the most "generic"
> transforms don't make sense for every format; e.g., margins for LIT.  So
> they would share all of Layer 1, some of Layer 2, and have a
> well-defined interface between each layer.
>
> I also think it's important to carry a kind of "conversion context"
> through the transforms at Layer 2, providing them with device profiles
> for the source content and destination format.  This will allow them to
> correctly interpret profile-determined measurements, and to produce
> results in line with output-profile conventions.
>
> -Marshall
>
> _______________________________________________
> Mailing list: https://launchpad.net/~calibre-devs
> Post to     : calibre-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~calibre-devs
> More help   : https://help.launchpad.net/ListHelp
>
> !DSPAM:3,495174e075728024598463!

-- 
_____________________________________

Kovid Goyal  MC 452-48
California Institute of Technology
1200 E California Blvd
Pasadena, CA 91125

cell  : +01 626 390 8699
office: +01 626 395 6595 (449 Lauritsen)
email : kovid@xxxxxxxxxxxxxxxxxx
web   : http://www.kovidgoyal.net
_____________________________________