calibre-devs team mailing list archive

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

On Fri, Dec 5, 2008 at 1:27 AM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:

> 1) Can you send me a test case, as far as I know that code should
> work.

Ah, I see what it's doing now.  It does work, just not how I expected
and need.  Calibre's `split.py` finds the page-breaks, splits at the
break in the middle of the set, then repeats recursively with the two
resultant trees until all trees are below the AdobeDE size maximum.
What I need is splitting the tree at /every/ page-break-*.

> 2) This is not going to change since as you point out, I want calibre
> to accept as wide a range of input as possible.

Yep, reasonable enough, although maybe there's room for selecting
different markup pre-processors?

> 3) Not sure I understand what you mean. calibre scales fonts
> proportionately, how is that different from a "music scale"?

I should have said musical keys -- much better analogy and less room for
confusion :-).  As with transposing a piece of music from one key to
another, what I want from font-size scaling is not a static scale or
shift applied to each source entity, but instead mapping the set of
source entities to a new set of destination entities.

For example, lets say that an input file uses the font sizes [7, 9, 10*,
12, 16, 18] (with the star indicating the "base" font size).  If I want
the base to be 12, using calibre's static proportional scaling factor on
all the fonts results in [8.4, 10.8, 12*, 14.4, 18.2*, 21.6].  This
"works" for the base font size, but fonts at especially the extreme
direction-shift-end (eg. largest fonts when larger) are distorted out of
proportion with the rest of the fonts.  Additionally, the line rhythm is
disrupted: so if the source document used a 10pt/12pt font-size/leading,
the destination will use 12pt/14.4pt, which is rather cramped, but if
the base leading is set to make the text e.g. 12pt/15pt then none of the
other font sizes and spacing are correct.

The alternative I use is to map the source font "key" to a different
"key" in the destination, such as [7, 9, 10*, 12, 16, 18] to [9, 10,
12*, 14, 16, 18], then force a default (and inherited) leading.  It's
rather more complicated, but I find results in much more pleasing
output.

> 4) Will happen in the future.

I figure most PRS-505/-700 users don't want it anyway, what with the
"src: res://..." solution keeping file sizes down.

> 5) a) That's what --override-css is for

I agree, but the 1pt margin between paragraphs is completely against
established typographic convention.  See [1], which is basically a
Web-oriented re-writing of the content of Robert Bringhurst's classic
/The Elements of Typographic Style/.

>    b) I'm willing to switch to using the body tag for side margins if it
> doesn't have any other side effects

None that I've seen in my conversions, and it's the way Hadrien is doing
it for feedbooks.

> In any case, I'm looking forward to oeb2lit

Getting it done last night was wiiiiildly optimistic, but hopefully by
sometime next week.  I still have several rough edges to sand off, and
spent some time chasing down a segfault in that lxzcomp code which
turned out to be a bug that only pops up on 64-bit machines.  Thank
goodness for valgrind :-).

[1] http://www.webtypography.net/Rhythm_and_Proportion/Vertical_Motion/2.2.1/

-Marshall