PDF Viewer 0.3.0 pre-release

[rhari79]

Originally Posted by pruss

Scrolling with the volume keys helps with this issue. How do you think the interface for locking the panning would work?
..
The priority is the crashing--so please send me the problematic pdf (arpruss@gmail.com).

Hi, Been busy for a while. Looks like you have more interested people and kudos for your work!!

For the pan, it could be a simple menu option to disable horizontal scrolling(for the current orientation) and keeping the current zoom or any new zoom level.

I tried recreating the Force close. I couldnt find the orginal pdf that caused this.
But I use a Mac and this creates a lot of Dot prefixed empty .pdf files when i copy to the usb mount drive. The reader crashed when by mistake i opened this file. Am not sure if this caused the issue initially too. I will keep looking to find a more valid pdf.

[pruss]

Originally Posted by rhari79

Hi, Been busy for a while. Looks like you have more interested people and kudos for your work!!

For the pan, it could be a simple menu option to disable horizontal scrolling(for the current orientation) and keeping the current zoom or any new zoom level.

The zoom should keep between loads of the same pdf file, but there is some intermittent bug that is causing it to change zoom levels when loading a document. I think somehow the bookmarks database is getting corrupted.

No disrespect, but I think a menu option to disable horizontal scrolling would be a kludgy solution. It would requires several three taps to toggle, since it would have to go in the "More" section of the menu. (I'm trained by the PalmOS development guidelines: for commonly used features, like this one would be, one must minimize the number of taps.)

Here's a thought: have a menu option to lock to vertical scrolling, but include have a temporary horizontal scroll unlock. The temporary unlock is triggered by moving horizontally about 1/8 of the screen width and is active until the user releases the finger/stylus. Maybe a tiny fading message could show up, too. How does that sound? The big advantage is that you could keep this feature always active, even when setting up the positioning of a new document.

Any other creative solutions?

I tried recreating the Force close. I couldnt find the orginal pdf that caused this.
But I use a Mac and this creates a lot of Dot prefixed empty .pdf files when i copy to the usb mount drive. The reader crashed when by mistake i opened this file. Am not sure if this caused the issue initially too. I will keep looking to find a more valid pdf.

A well-written app shouldn't crash when fed an invalid external file. Are these empty .pdf zero-length, or do they have some content? If they have some content, please send me one.

[sherbs]

Originally Posted by pruss

I've generally optimized it for scrolling vertically downward, not horizontally side-to-side or vertically upward. On limited-memory devices, there are some real trade-offs, and not to waste memory the app needs to guess the direction of the next scroll. And so I have it guess that you're going to go down. This works well if you're reading a book and all the pages are vertically arranged, one after the next. You just scroll down and each successive page is waiting for you.

I think in your usage situation we would see a benefit from increasing the tile cache size (the tiles are the areas which you see getting rendered), and maybe pre-rendering tiles to the left and right. If you email me, I can send you some test versions with different tweaks. Or if any of the magazines you are viewing have a free sample copy online, you can point me to a pdf.

Just to be clear, I have only used the app in portrait mode and have been scrolling vertically. I'm set to full screen and fit width so there is no sideways movement anyway.

One thing I've noticed is that speed and smoothness is best with rendering ahead disabled, which surprised me.

The mag I'm using for testing is from a subscription but I could send you a copy if it would help. It's 113MB though.

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

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

Any example pdfs you can send me? I saw some remarks in our issue tracker that there is more than one way of measuring page size, and that could be related. I know very little about the pdf format myself--I've been optimizing around the edges of the pdf rendering, leaving the actual pdf rendering to the underlying muPDF code.

[pruss]

Originally Posted by sherbs

Just to be clear, I have only used the app in portrait mode and have been scrolling vertically. I'm set to full screen and fit width so there is no sideways movement anyway.

One thing I've noticed is that speed and smoothness is best with rendering ahead disabled, which surprised me.

The mag I'm using for testing is from a subscription but I could send you a copy if it would help. It's 113MB though.

Thanks, but it probably wouldn't be that different from the photography magazine I was looking at, and there might be copyright issues.

But I do have some thoughts on why rendering ahead might make scrolling smoothness worse under some circumstances, especially if you're scrolling forward quickly.

Do you scroll by sliding the display with your finger or stylus, or do you scroll by whole screens with the volume buttons? (I normally do the latter.)

[sherbs]

Do you scroll by sliding the display with your finger or stylus, or do you scroll by whole screens with the volume buttons? (I normally do the latter.)

Finger scrolling only. Tried the volume button briefly but what tends to happen there, because the size of the page doesn't fully fit the screen vertically, is that the full page view gets very quickly out of sync with the button and you have to use your finger to readjust anyway.

Scrolling action is generally - wipe finger up, wait a couple of seconds then the pdf moves. Usually, when a page has loaded fully I can press my finger on the screen, move up and down slowly and the page will follow my finger, but only to the top/bottom of that page. Any further though and I have to wait for it to react again.

[pruss]

What you describe is much worse performance than what I see on my A43. I had no idea it was THIS slow. In none of my testing is it this slow. Refreshing a single page on my A43 takes at most a second, and with render-ahead enabled, the next page is always waiting for me.

I think I know what the problem is. The problem is that not enough memory has been allocated for the render-ahead option to work on a screen resolution as high as yours. For your screen, we'd need to allocate at least 5mb, maybe as much as 6mb, while we are only allocating 4mb.

To test this hypothesis, could you try switching APV's color rendering mode to "Normal black and white"? This will reduce memory usage by half, hopefully fitting everything into the internal cache. Then see what performance is like.

If it turns out that the cache memory is the issue, I can increase the cache to 6mb, and then have a 4mb fall-back in low memory conditions.

[pruss]

The vertical scroll lock option (Menu | Options) is now in place (pre11).

[sherbs]

Have spent some time messing around with the colour settings and not finding much difference between b/w and colour, still pretty much unusable. But, I just downloaded pre11 and it's a vast improvement.

What I'm seeing on my screen now is that if I keep my finger pressed down and drag up slowly, the page will follow my finger (although jerkily). As I'm scrolling I can see black space underneath getting filled in by quarters and by the time my finger is at the top of the screen, the following page is finished rendering and I can carry on in the same fashion. This is in colour! Normal black doesn't improve usable scrolling speed much, just that the following page renders a little quicker.

I'm using vertical scroll lock and render ahead.

[pruss]

Originally Posted by sherbs

Have spent some time messing around with the colour settings and not finding much difference between b/w and colour, still pretty much unusable. But, I just downloaded pre11 and it's a vast improvement.

What I'm seeing on my screen now is that if I keep my finger pressed down and drag up slowly, the page will follow my finger (although jerkily). As I'm scrolling I can see black space underneath getting filled in by quarters and by the time my finger is at the top of the screen, the following page is finished rendering and I can carry on in the same fashion. This is in colour! Normal black doesn't improve usable scrolling speed much, just that the following page renders a little quicker.

I'm using vertical scroll lock and render ahead.

Glad to hear this. Can you give me an idea how far zoomed in you are relative to the page edges? Is your visible width 90% of the page? 75%?

If you email me (arpruss@gmail.com), I can send you a special version with extra cache memory allocation. You can then tell me if that makes any difference.

[sherbs]

Glad to hear this. Can you give me an idea how far zoomed in you are relative to the page edges? Is your visible width 90% of the page? 75%?

If you email me (arpruss@gmail.com), I can send you a special version with extra cache memory allocation. You can then tell me if that makes any difference.

I've sent you an email.

In answer to your question, my pages take up pretty much the whole of the width.

[=X=]

Originally Posted by pruss

Any example pdfs you can send me? I saw some remarks in our issue tracker that there is more than one way of measuring page size, and that could be related. I know very little about the pdf format myself--I've been optimizing around the edges of the pdf rendering, leaving the actual pdf rendering to the underlying muPDF code.

Sure several of my books have this problem. I'll send you a PM with a dropbox link when I get a chance.


On an aside the app is moving along nicely. The first build was near impossible to use. It was very choppy and the refresh was very slow. I really like the scrolling feature.

One thing though on both ezPDF and Repligo have is a zoom to margins on a double tap and a double tap goes back to the last zoom. I much prefer this to the current implementation of PDF viewer.



=X=

[pruss]

Originally Posted by =X=

One thing though on both ezPDF and Repligo have is a zoom to margins on a double tap and a double tap goes back to the last zoom. I much prefer this to the current implementation of PDF viewer.

The usual function of a double tap in Android apps is to zoom in, and I don't like the idea of including non-standard uses of gestures. That makes for an inconsistent user experience. UI inconsistency is a serious problem on the Android platform. (I also think it's bad for a developer make their own UI widgets instead of using the standard ones, unless the standard ones cannot possibly do the job, even if the new ones are much prettier.) Plus I like the idea of being able to zoom in on a particular point.

One possibility, however, would be if the fit-to-width button were to return to the previous zoom left if you tapped it again. I am not sure, though, how this would work in the case of a long-tap of fit-to-width (which does fit-to-page). Would a normal tap restore? But what if you want to move from fit-to-page to fit-to-width? Maybe then to restore from fit-to-page, you do another long-tap, and to restore from fit-to-width, you do another short-tap?

[=X=]

Originally Posted by pruss

The usual function of a double tap in Android apps is to zoom in, and I don't like the idea of including non-standard uses of gestures. That makes for an inconsistent user experience.

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

The drill down makes more sense for apps like Maps that obscure detail from a birds eye view and continue to provide more detail as one zooms in.

Originally Posted by pruss

..... Maybe then to restore from fit-to-page, you do another long-tap, and to restore from fit-to-width, you do another short-tap?

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.


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.

=X=