Quote:
Originally Posted by llasram
Is the @font-face rule with a 'res://' src insufficient for you, or would you like to see specific support for that?
|
The problem is that I would have to include that with every book, which means extra 200+ KB which must be included in the file AND processed by the Reader. It has some legal ramifications, too - even if I could distribute the book itself (copyright expired, the author gave his permission, or whatever), the font may be a different issue - plus I don't like forcing my fonts on other users.
Quote:
|
I can see how this might be an issue, as Adobe doesn't seem to cache any pagination information to help it jump into a flow more easily. I admit that I'm not sure what could be done here on Calibre's part.
|
AFAIK, nothing. That's why I would rather like to see a fix in LRF engine, which is something Calibre CAN do.
Quote:
|
Originally Posted by kovidgoyal
The LRF converter has a separate parser from all the other conversion engines.
|
I assume that's because LRF support is the oldest and doesn't share the framework of all other engines.
Still, wouldn't it make sense to update the LRF engine to the current framework? I was under the impression that the converters are written in such a way as to make it quite easy to add new formats - is there anything that prevents LRF from being considered a new format? Other than the time you are willing to spend on such efforts, obviously. (I would be happy to write the converter myself, but unfortunately Python is completely unknown to me.)