On Wednesday, July 2, 2003, at 1:44 PM, Matthew T. Russotto wrote:
Maybe using WebCore directly is a better idea... but there's no
stable API for that, is there?
WebCore has no public API, and in general it's not a good idea to
link to it directly. Maybe if you tell us a bit more about your
specific requirements, we can help you figure out ways to do what you
want with WebKit.
Basically what I'm up to is an ebook browser (for OEB ebooks, which
are basically XHTML). There are two basic difficulties that I know
of. One is that you want page at a time scrolling, at least as an
option.
How are the page boundaries determined? Is it a fixed number of pixels,
or based on the position of a specific element? Once you know the size
of a page, you can use something like:
This also means that anchor links should go to a page boundary which
contains the anchor.
OK. We don't have a clean DOM API to find out where an anchor element
is on the page, but again you can achieve this through JavaScript:
// only need to define helper functions once:
[[view mainFrame] stringByEvaluatingJavaScriptFromString:@"function
elementTop (e) { var top = 0; while (e) { top += e.offsetTop; e =
e.offsetParent; }}; function elementLeft (e) { var top = 0; while (e) {
top += e.offsetLeft; e = e.offsetParent; }};"];
Then you can parse the strings yourself. I know this is kind of ugly,
but it's all we have available right now.
The other is that you do not want to have to read in and render your
entire potentially huge book just to start reading at a particular
point. I have some ideas about that second one, but they all involve
finding out where elements are.
Perhaps the suggestions above will help; but I don't think you'll be
able to find out where elements are without rendering them all. A
layout is required to determine element positions. Have you checked the
performance of loading a whole book at once? Maybe WebKit is fast
enough to handle it.
