PDF Viewer 0.3.0 pre-release

[pruss]

Originally Posted by =X=

It's a standard feature for most web browsers(Android stock browser, Opera, Dolphin, FireFox) and PDF readers (including Google Books).

In the stock browser, double tapping the first time zooms in, though the second time it zooms back out. I thought you wanted double-tap to zoom out to full-width the first time. I may have misunderstood your suggestion.

I'm not so much asking for a feature that "returning to the previous zoom" but really zoom to crop the margins. I just mentioned the "retuning" because that is the standard behavior.

Margin cropping would be nice. I'll see if I can figure out how to do it. If I figure it out, it should replace the current zoom-to-width functionality.

One question: Often there are headers and footers and other markings in the margins. On the PDF viewers that do crop margins, do they crop away these marginal markings too?

Last comment is it would be a BIG BOON for this app is to add pinch to zoom support. It's very hard to read PDFs without it.

Pinch to zoom is not so easy to implement, and I have no device I can test it on. Maybe another one of the APV developers can do it, but I expect it's a finicky feature that is hard to get exactly right without actually having a device you can test it on.

I do dispute that it's hard to read PDFs without it. :-) I don't find it hard at all. I set APV's zoom to go by 10% at a time, using long-hold on the zoom button for a bigger zoom as needed, and can get the right size quite quickly.

[=X=]

Originally Posted by pruss

One question: Often there are headers and footers and other markings in the margins. On the PDF viewers that do crop margins, do they crop away these marginal markings too?

I've seen two implementations, one that crops only the margins and the other that crops on the paragraph doubled tapped on.

In the former's case it would crop around the footer/header, the latter would crop off the footer/header and fit the paragraph.

For books with single columns the former works fine, but is useless for complex PDF layouts. The latter works for the complex layouts as well as the standard book format. The only drawback is sometimes on complex PDF the zoom creates large fonts because the columns are so small.

Originally Posted by pruss

Pinch to zoom is not so easy to implement,

I figured that is why you omitted that feature in the first place.

Originally Posted by pruss

I do dispute that it's hard to read PDFs without it. :-) I don't find it hard at all. I set APV's zoom to go by 10% at a time, using long-hold on the zoom button for a bigger zoom as needed, and can get the right size quite quickly.

Ha Ha fair enough, I guess it's just a matter of opinion. I'm so use to pinch to zoom it's hard for me to navigate without it. I keep on sliding my fingers expecting it to resize, with no avail.

=X=

[pruss]

Originally Posted by =X=

I've seen two implementations, one that crops only the margins and the other that crops on the paragraph doubled tapped on.

The first is probably easier to implement.

But I really like the second. It fits with my feel for the double tap as a zoom gesture. I suppose how it works in practice depends on the shape of the paragraph, etc. And if you double tap on an image, I suppose it will fill the image?

I wonder how it would work on a pdf where the text is implemented in images (e.g., some scanned books). I suppose it would zoom in to wherever the boundaries of the whole image are? One question to ask is this: In pdfs where the text is implemented in images, are the images all one piece, or are they tiled? If tiled, we might get wrong behavior if we zoom in on the current image. Some experimenting is worthwhile.

I fear that implementing this will require us to get under the hood on the muPDF code that is used for rendering, and modify that code. Currently, we use the muPDF code unmodified, which is great since we can easily upgrade the render engine as new muPDF code comes in (only changing it a little if the exposed API changes).

Maybe the changes would be just a matter of adding a new dummy fitz rendering device, akin to the render-to-text device. Nevermind: just thinking out loud.

Ha Ha fair enough, I guess it's just a matter of opinion. I'm so use to pinch to zoom it's hard for me to navigate without it. I keep on sliding my fingers expecting it to resize, with no avail.

I can imagine how one could get used to it.

There are also possible patent issues. My understanding is that Apple's patent doesn't apply to a simple pinch zoom, but only to more complicated pairs of gestures, but I am not a patent lawyer. There would also be the issue of making sure that we're OK patent-wise globally, since some of the APV developers may be in other countries.

There may also be technical issues. Our rendering is still sort of slow and we achieve acceptable downward scrolling only by pre-rendering forward. That won't work for zooming. I suppose that for zooming in, we could simply blow up the tiles we have rendered, and then replace them with fresh tiles as soon as these become available. The effect might be really ugly. Zooming out would be even more problematic.


In any case, I may wait for the zoom enhancements until we have the render speed and memory use issues under control, and so these UI things might not make it into 0.3.0.


I should note that for all the texts I read, there isn't much of a zoom issue. I just zoom in past the page margins, and can read the whole page just fine in portrait on my 480x854 4.3" screen. I can imagine that if a book used particularly small font, or my eyesight were not as sharp (and one day it won't be), this wouldn't be so easy.

[pruss]

Originally Posted by =X=

Bug: The app is not respecting the cropped areas. As a result some PDF are showing a very large page with only text on the top left corner down to the middle of the page.

0.3.0pre12 is by default using CropBox, but this can be configured in the options. See if this fixes it.

[sherbs]

I can send you a special version with extra cache memory allocation. You can then tell me if that makes any difference.

Thanks for sending me the experimental versions.

My observations:
So little difference between any version that I tested using the 6, 9 and 12 versions.

1)Scrolling continously as pages render: same, slow speed allowed by each version.
2)Page rendering: tested by wating till a page has loaded then scrolling a whole page length quickly into black space and timing the render. In all cases 4-5 seconds (roughly a second per quarter).
3)Flinging: not sure this is much use but was the only thing that changed radically between versions. After scrolling down through a number of pages I try flinging the pdf back and forth. Version 6 allows about 3 pages while version 12 will comfortably do 6.

Rendering occurs only with what's visible on screen. That is if a sliver of the top of the following page is showing as I read a page, when I scoll down, half the next page will be rendered (the two top quarters).

I've come to the conclusion that the mag I'm using for testing is seriously heavy. ezPDF takes a few seconds to turn the pages with the same mag and other, similarily graphic intense mags in your app are a lot quicker, rendering as I'm scolling in 1-2 seconds.

For a test I tried the Skip Images setting which resulted in blank, white pages. Although I could scroll down pretty fast, after a few pages, I could still see the individual quarter pages being rendered.

[pruss]

Could you try this in the 6mb and 12mb versions? Take your heavy image pdf. Turn to some page. Wait ten seconds, to simulate reading the page. Then press the volume-down button to go to the next page. How long does that next page take to draw?

[=X=]

Originally Posted by pruss

....I suppose how it works in practice depends on the shape of the paragraph, etc. And if you double tap on an image, I suppose it will fill the image?

I wonder how it would work on a pdf where the text is implemented in images (e.g., some scanned books). I suppose it would zoom in to wherever the boundaries of the whole image are? One question to ask is this: In pdfs where the text is implemented in images, are the images all one piece, or are they tiled? If tiled, we might get wrong behavior if we zoom in on the current image. Some experimenting is worthwhile.

Love your thought process purss, very thorough. I actually couldn't answer you off the top of my head I had to run some experiments on the different types of PDF one might run into the results are below. I ran these test on ezPDF and Repligo. They both had the same behavior.


Thre are four types of PDF's a user most likely use.
1) Text base PDF
2) Text base PDF with embedded images
3) Image based PDF
4) Image based PDF with Scanned OCR below/above image.

Double tapping on text
For all except type 3 double tapping on the paragraph would zoom in the text to fill the screen. Type 3 would always zoom in to a default value.

Double tapping on images
Only type 2 would zoom the image to fill the screen. Type 3 & 4 always zoomed in to a the same default value. Type 1 was omitted for obvious reasons.

The file used for type 3 & 4 was the same file. One was scanned from a book and saved as an images based PDF. Type 4 was then scanned with Finereader where the text was stored underneath the image.

Originally Posted by pruss

I can imagine how one could get used to it.

There are also possible patent issues.

Baby steps I think you need to first worry about being able to zoom, before worrying about Apple coming after you for pinch to zoom PDF

Originally Posted by pruss

I should note that for all the texts I read, there isn't much of a zoom issue. I just zoom in past the page margins, and can read the whole page just fine in portrait on my 480x854 4.3" screen. I can imagine that if a book used particularly small font, or my eyesight were not as sharp (and one day it won't be), this wouldn't be so easy.

True I would say for me it is a little more than half my books can be read without fussing with zoom. However mostly those books I just enable the reflow.

Originally Posted by pruss

0.3.0pre12 is by default using CropBox, but this can be configured in the options. See if this fixes it.

I tried this program this morning and the CropBox setting is working. I played with the config options and set the app to "trim". This however was not working.

If you look at the PDF I sent you, see your PM. You'll see that PDF has 4 crosshairs, one on each corner. Those are the trim settings. Most PDF readers truncate on those crosshairs.



=X=

[sherbs]

Could you try this in the 6mb and 12mb versions? Take your heavy image pdf. Turn to some page. Wait ten seconds, to simulate reading the page. Then press the volume-down button to go to the next page. How long does that next page take to draw?

About 4-5 secs for both.

It's basically a second per quarter rectangle whatever the version. If, while I am reading a page, the top part of the next page is showing on screen, paging down with the volume button would only take two seconds because there are only two quarters left to load. Hope I'm making sense.

[pruss]

Originally Posted by sherbs

About 4-5 secs for both.

It's basically a second per quarter rectangle whatever the version. If, while I am reading a page, the top part of the next page is showing on screen, paging down with the volume button would only take two seconds because there are only two quarters left to load. Hope I'm making sense.

Interesting. Something is not working with the render-ahead. How does turning render-ahead off affect things?

Do you have adb installed? You could send me a log.

[sherbs]

Interesting. Something is not working with the render-ahead. How does turning render-ahead off affect things?

Do you have adb installed? You could send me a log.

Disabling render-ahead appears to make no difference.

What is adb?

[pruss]

Originally Posted by sherbs

Disabling render-ahead appears to make no difference.

What is adb?

Android Debug Bridge.

I haven't tried it myself, but there may be a simpler solution: http://code.google.com/p/android-log...downloads/list

It is supposed to allow you to send me a log. If you're willing to do this, here's what I'd like you to do. Load in one of your files. Page down a couple of pages. Then wait thirty seconds. Then page down one more page. Then exit, go to Android log collector, and send me the log. Best if you do it with the 12mb version.

That's assuming Android log collector works--I haven't tried it yet.

Something isn't working in APV: renderahead should make the next page down near instantaneous. There should be no tile-by-tile rendering.

[sherbs]

Installed the app. No documentation, don't even know where it is on my device. I'll have a look at it tomorrow.

[sherbs]

I've sent a log to you. Hope it arrives as my wifi was off as I hit the send button. Quickly switched it on and the message appears in my sent box but if not I'll resend.

[pruss]

I've just posted 0.3.0 pre 13. This unfortunately has a new bookmark database, not compatible with previous versions, so people will lose their per-document settings. I am hoping this is the last such loss--the new format will make code maintenance easier and is easily upward expandable.

New features/fixes in pre 13:
- store horizontal offset in per-document settings
- better restore of zoom if orientation has changed
- fix round-off error which resulted in occasional horizontal one-pixel-width errors

[pruss]

I posted a release candidate for 0.3.0. We're basically ready. The problem with smooth forward scrolling on large screens has been fixed. An option to increase cache size has been added. The long-tap context menu has been improved. Unicode searching has been fixed.

There are two features that I'd like to implement but that aren't going to make it into 0.3.0: (1) export to text file and launch an ebook reader to view; (2) double tap on paragraph to fit the paragraph to width. (These two features are actually closely related--they both require paragraph detection logic.)