| Thread Previous • Date Previous • Date Next • Thread Next |
1) Actually, adding a --split-on-page-breaks option is on my TODO list, since this is important when creating epub files that are viewed on viewers that don't support the css page-break property (calibre's viewer being a prime example) 2) Sure, patches are welcome :) 3) Interesting, how do you compute the new "key" form the old one? I'm willing to add alternative font rescaling algorithm as an option. Patches are welcome :) 4) Yeah, but calibre doesn't just produce epub files to be used on the SONY readers, so this will definitely happen. 5) OK, I've removed the 1pt and switched to using body for the size margins. Let's see if it produces complaints from other people :) Take your time with oeb2lit, I wont integrate it into the GUI before 0.5.0 in any case (which should happen sometime over the course of the holidays) Kovid. On Friday 05 December 2008 12:11:40 Marshall T. Vandegrift wrote: > 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 > > _______________________________________________ > 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,49398b0875727511420151! -- _____________________________________ 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 _____________________________________
| Thread Previous • Date Previous • Date Next • Thread Next |
