calibre-devs team mailing list archive

[Kovid Goyal <kovid@xxxxxxxxxxxxxx>]

On Sunday 21 December 2008 19:30:08 Marshall T. Vandegrift wrote:
> On Fri, Dec 19, 2008 at 1:47 PM, Kovid Goyal <kovid@xxxxxxxxxxxxxx> wrote:
> > Given the level of variability in input sources/viewers I doubt we'll
> > ever reach a universally satisfactory solution. I'm inclined to just
> > stick with the CSS spec, assume a default base font size of 12pt/16px
> > (96dpi) for all viewers and convert all specified font sizes into %
> > units.  This isn't likely to be much worse than any other solution and
> > is likely to be the most "future proof" going forward. This is what
> > html2epub does now.
>
> The more fine-grained solution I'm working towards actually does produce
> much higher-fidelity output.  Several commercial LIT books I have leave
> some body text as the base font-size, specify other body text as "small"
> (which in MSReader is the same as the base size), and specify the size
> of faux small-caps with a fixed point-size -- the output of the simpler
> solution doesn't really look much like the intended text.  I've got some
> CSS flattening code that I current have hard-wired to rescale from
> MSReader's font sizes to AdobeDE's, and the results are as good as I was
> getting with hand-tuning the stylesheets.
>

We can certainly make the rescaling algorithm input format aware. I'm more 
hesitant about making it output renderer aware, since the whole point of 
reflowable books is that they are supposed to be portable. 

> > The remaining question is how to improve font size rescaling.
>
> Indeed...  I think the solution is some sort of logarithmic scale
> shifted around the base font size.  The two many things we need to
> account for are (1) small point differences between small fonts are much
> more visible than for large fonts and (2) there is an upper limit to how
> large of a font devices can display.
>
> The solution I'm using right now is to map each font in the input
> document to a user-specified font "key."  The "key" accounts for
> property (1) by specifying a denser set of allowed sizes at the smaller
> end of the scale.  This means that the mapping function largely need
> only account for property (2).
>
> What I'm doing now is map each size in the input "key" to a logical
> value representing that size's relation to the base font size.  Then to
> scale a size I perform that same mapping for the input size vs. the
> source document's base font size, then convert that size to the size in
> the input key with the closest logical relation value.
>
> The relation function I'm using now I've reached using pretty much
> purely trial and error and is wholely unscientific in its purported
> properties for producing reasonable conversions:
>
>     def relate(size, base):
>         size = float(size)
>         base = float(base)
>         if size == base: return 0
>         sign = -1 if size < base else 1
>         endp = 0 if size < base else 36
>         diff = (abs(base - size) * 3) + ((36 - size) / 100)
>         logb = abs(base - endp)
>         return sign * math.log(diff, logb)
>
> It does a pretty good job for me, but a more rigorous approach would
> probably be a good idea, I imagine.
>

How large an input key do you need? Can you post an example?

Kovid.
-- 
_____________________________________

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
_____________________________________