not sure this is duable or relevant for most of you. what about adding an index of readability tool like ms word? <br><br><div class="gmail_quote">On Mon, Sep 26, 2011 at 2:34 AM, Charlie Sharpsteen <span dir="ltr"><<a href="mailto:chuck@sharpsteen.net">chuck@sharpsteen.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Sun, Sep 25, 2011 at 4:31 PM, Charlie Sharpsteen <span dir="ltr"><<a href="mailto:chuck@sharpsteen.net" target="_blank">chuck@sharpsteen.net</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div>The amount of memory the new viewer consumes at high zoom levels is pretty appalling---it will eat gigabytes once the zoom level gets over 1000%. We'll need to figure out how to cut this down via smart caching of pixmaps and perhaps tiling out the page renders at high zoom. Splash didn't seem to be capable of partial page renders as it renders the whole page and then crops the result.</div>



<div><br></div><div>If Cairo can do a partial pages, it would make a very strong argument for using it as our render backend.</div><div><br></div><font color="#888888"><div>-Charlie </div></font></div>
</blockquote></div><br></div><div>Bad news on the partial render front---looks like Poppler just can't do it---at least not in an efficient manner. Every page render request, regardless of the backend that is used, causes Poppler to re-parse the entire page rather than parsing once and then working off of some sort of cache. The parsing requires the most time and processor power so splitting a large pixmap up into tiles basically multiplies the rendering time by the number of tiles that are used.</div>


<div><br></div><div>Discussions and bug reports in other projects:</div><div><ul><li>Evince: <a href="https://bugzilla.gnome.org/show_bug.cgi?id=303365" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=303365</a></li>
<li>Okular: <a href="https://bugs.kde.org/show_bug.cgi?id=148527" target="_blank">https://bugs.kde.org/show_bug.cgi?id=148527</a></li>

</ul><div>I think Okular's method of dealing with the problem makes the best of a bad situation--once the amount of pixels in a rendering request exceeds a certain value, they just ignore it. So the user can zoom in as much as they like, but after a point things just stay fuzzy. This would be pretty easy to implement in our current rendering setup.</div>


</div><div><br></div><div><br></div><div>If only there was an open source PDF library that provided threadsafe partial rendering...</div><div><br></div><font color="#888888"><div>-Charlie</div>
</font></blockquote></div><br>