← Back to team overview

calibre-devs team mailing list archive

Re: Branch lp:~llasram/calibre/oeb2lit

 

On Wednesday 10 December 2008 12:32:50 Marshall T. Vandegrift wrote:
> On Wed, Dec 10, 2008 at 2:52 PM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:
> > 1) Why have you chosen to not use the cssselector function from lxml
> > instead of writing your own stylizer class?
>
> Well, it's not quite so simple as cssselector vs. stylizer.  It's more
> that I need to update stylizer to use cssselector.  Just cssselector
> doesn't get the inheritance voodoo, default values, instantiating
> proportional values, etc stylizer provides.  I originally wrote stylizer
> for BeautifulSoup, and even though I've updated it for lxml, it's such a
> different mode of operation to use cssselector (iterating over the
> styles and applying each one to affected nodes vs. iterating over the
> nodes and appyling each relevant style) that I just haven't gotten
> around to it yet.  It shouldn't change the interface though once I do.
>

The way I would have done it (and I'm not necessarily implying it's better), 
is to add the declared style information for each element to the element 
itself in a special attribute, like I do for the EPUB splitting code. Then, 
when parsing the element, use getparent() to resolve inheritance. This has the 
advantage of making flattening of the CSS contextual selectors trivial and 
obviates the necessity of maintaining a CSS selector parser. On the other 
hand, it's probably slower than your method. 

> > 2) Have you tested lzxcomp.py on windows? You might need to set
> > Structure._pack_ = 1 on windows.
>
> No, I have not, but I'm still intending to ditch the ctypes anyway.
>

In that case, ignore windows :)

> > 3) Do you really need a PRS505 profile since it is (and will remain)
> > identical to the PRS500?
>
> Well, perhaps not.  And really I should probably just hook that into
> calibre's central profile system.
>

Actually, calibre doesn't have a central profile system. I have yet to figure 
out how to do this and keep enough granularity in information while not 
overwhelming the user with too many obscure choices. 

> > 4) IIRC, you said that MSReader doesn't make use of the TOC. Is it
> > worthwhile inserting a TOC into the book as HTML?
>
> It might make sense as an off-by-default option at some layer...  Even
> though most commercial LIT books with in-content TOCs have a @type="toc"
> //guide/reference, some don't. Oh, and I discovered that it just doesn't
> make very /good/ use of a //tour TOC -- it lets you skip forward and
> back by chapters.  Hooray!
>
> > 5) I'm guessing you have still to flesh out the command line
> > interface? Or are there no options controlling oeb2lit? I'm assuming
> > the code correctly handles covers specified in the OPF file (via the
> > guide element)?
>
> Covers: I do still need to add support for generating the
> //guide/reference elements MSReader uses, if they aren't present.  A LIT
> book can actually have several different cover images for e.g. the
> full-sized cover image vs. a thumbnail.  I was planning to just do basic
> cover detection via checking for an //metadata//meta[@name="cover"] or
> //guide/reference[@type="other.ms-coverimage-standard"] and generating
> the others from there.  I figured adding a detectable cover would be the
> job of the OEB-generating layer.
>

Hmm I'm still planning to pass input books to any2epub first and then to 
oeb2lit, that will automatically take care of covers, making them the first 
element in the spine. Thumbnails will be missing, but no great loss. 

> For actual generation options, I don't think there are many which make
> much sense...  The optional HTML ToC-generation; and the stylesheet
> could be processed as for EPUB to change the base font-size, I suppose.
> I kind of see both of those as "any2lit" options though -- permutations
> to the OEB which happen before the LitWriter gets ahold of it.
>
> > 6) Please rename the class Toc to TOC, to be consistent with calibre
> > naming conventions.
>
> I could have sworn PEP-8 said to CamelCase abbreviations the way I was
> doing it, but I just checked and I'm wrong.  You win this time, Kovid!
> I'll change all my mis-cameling. I do think I'll leave LIT as "Lit"
> though, what with it not being an acronym.
>

Hah!

> > 7) Please remove the /usr/bin/python2.5 header from the .py files (or
> > atleast use python instead of python2.5, I just spent 3 days migrating
> > calibre to python 2.6 :-).  You should also add __license__ and
> > __copyright__ declarations.
>
> I'll definitely do those prior to declaring the code merge-ready.
>
> -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,4940277a75721024436230!

-- 
_____________________________________

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
_____________________________________




References