calibre-devs team mailing list archive

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

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.

> 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.

-Marshall