gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS homebrew announcements > Ands-pdf -- The first and only PDF viewer for the DS!

#166906 - albinofrenchy - Mon Feb 23, 2009 9:56 pm

I've made a significant release to the ands-pdf project over here.

For all those following it, the new features in short are a document preview window that lets you pan and zoom, the ability to reopen another file, and faster rendering. Also, almost any PDF should render correctly now, save those with large images.

For anyone new to it, go to the blog to see all the features :). If you want to view pdf's on your NDS, this is for you though.

Please please please either post here or on the blog telling me how things went for you, or how it could be better, etc. I'll be checking both. If it doesn't work for you especially please send me the file, as always. [/url]

#166970 - Kilos - Wed Feb 25, 2009 12:34 am

Was going to post this as a blog comment (I've commented before as 'Steve'), but the comment system was being wacky so...
Quote:

Meant to reply yesterday but got sidetracked...

First off, you're doing a fine job on this (I know it's not built from scratch, but still. A PDF reader has been a popular wanted app for awhile).

Second, I may not know how to program, but at least I can make suggestions:

The red and green background combo is visually unappealing...

It'd be nice if it only showed .pdf files and folders.

Long filenames extend to the side over the vertical scroller. If you choose to address this (not a huge problem though. You can still tell what file it is by the first few words), I would prefer a horizontal scroller instead of a wraparound.

What's with the little 'm' before some files?

Screen brightness adjustment within the app.

When opening a new file (after having one open), the console spits out "warning: someone forgot to empty the store before freeing xref!". Don't think that's a big deal though.

I think the preview should be shown upon document loading. It's confusing when you load the document and get a blank white screen (actually the top right of the document, but still).

You forgot to state that 'X' changes the page orientation and the shoulder buttons go forward and back a page. The shoulder buttons for page changing doesn't work well with book-style orientation. Maybe the top unused screen should have the instructions? At least before opening a file anyways.

For the line-drawing-to-select-section function, there should be a visual line also so you can see what part is going to be displayed. I don't really like that function though, tbh. Maybe the D-pad could be used for page navigation? Right, x--; up, y--; left, x++; down y++; (Idk if that's right on the DS, but you know what I mean)

I'd really like to see it like the Opera browser though, with the full page rendered on the touchscreen and a little zoom box which can be moved via d-pad or stylus.
Example: http://www.slashgear.com/gallery/data_files/7/4/Nintendo_DS_Opera_Browser.jpg
An option to adjust zoom would be required in that case. Also, D-pad movements would have to be changed with the page orientation.

Of course a "currentpage/total pages" would be nice. You could fit it on the yellow bar too.

I think an EXRAM build is required for documents with images...

Lastly (for now), the document I viewed had fuzzy text, but of course that could've been the documents fault.

Hope I gave you some helpful suggestions. :P


Oh, and hello everyone at Gbadev. I've been wanting to make homebrew apps but only know Python and PHP and haven't gotten around to learning C. =d

#167007 - Maturion - Thu Feb 26, 2009 12:48 pm

Wow, this is really awesome! Keep the good work up!

But I assume I can only open small-sized PDFs... the DS RAM may just be not enough to display bigger files.

#167019 - albinofrenchy - Thu Feb 26, 2009 5:33 pm

@Kilos: Thank you for the great feedback! I've done line-item responses below. It is actually really helpful to get someone who has less of an idea about the implementation details of coding the DS; that distance gives a certain type of objectivity.

Quote:
The red and green background combo is visually unappealing...


The scheme was chosen as test patterns and just kind of stuck. It is a good point though, it is ugly so next release they'll just both be either solid black or solid white.

Quote:
It'd be nice if it only showed .pdf files and folders.


That is a really good idea, i wish i'd thought of it! I'll make it display only pdf files for the next release. My experience with doing that kind of thing with files is that its jarring to the user to not see folders they expect to be there, even if they wouldn't go in them.

Quote:
Long filenames extend to the side over the vertical scroller. If you choose to address this (not a huge problem though. You can still tell what file it is by the first few words), I would prefer a horizontal scroller instead of a wraparound.


The wraparound is buggy, and so I will find some way to not let that happen. The horizontal scroller might not happen for a while though; that seems considerably more difficult and ideally I'll replace this file chooser at some point.

Quote:
Screen brightness adjustment within the app.


I like this idea! I just looked up how to do it too, expect it in the next release.

Quote:
You forgot to state that 'X' changes the page orientation and the shoulder buttons go forward and back a page. The shoulder buttons for page changing doesn't work well with book-style orientation. Maybe the top unused screen should have the instructions? At least before opening a file anyways.


You are right; I should have put the new list of commands on the blog. For the next release I'll either include a PDF file that opens by default with the instructions; or I'll put a help button that spits instructions out to the console. For book style orientation, any ideas on better keys to map to? I agree the left shoulder button is hard to hit.

Quote:
For the line-drawing-to-select-section function, there should be a visual line also so you can see what part is going to be displayed. I don't really like that function though, tbh. Maybe the D-pad could be used for page navigation? Right, x--; up, y--; left, x++; down y++; (Idk if that's right on the DS, but you know what I mean)


I'm def. going to have the key pad mapped to the panning; its one of the most common requests.

So the zoom feature is broken UI wise; I've heard this from many people. For short term development, here is what I've distilled as a good idea from a variety of sources: Do the mini-doc like how it is now, maybe bigger, and display a rectangle showing what is displayed on the screen. Let the user enlarge that rectangle by grabbing a side and dragging (zoom), and let the user move that rectangle by grabbing the center and moving it. Would this be a better experience? Would you expect that mini-view to disappear after you do one change or persist tell you tell it to leave?

Quote:
Of course a "currentpage/total pages" would be nice. You could fit it on the yellow bar too.


I'll have this in the next release. I was getting lazy in this one and just didnt include it. When you go to book-style orientation, would you expect those numbers to rotate?

Quote:
I think an EXRAM build is required for documents with images...

I'm actually surprised by how many people want this. How many people have the EXRAM carts?

Quote:
Lastly (for now), the document I viewed had fuzzy text, but of course that could've been the documents fault.

If its not a personal document, can you send it my way? I haven't noticed any fuzzy-test on other documents really, but we do go from a 24 bit to an 8 bit color map; so it wouldn't be the most surprising thing.

@Maturion:
Quote:
But I assume I can only open small-sized PDFs... the DS RAM may just be not enough to display bigger files.


In PDF files there is a kind of table of contents for document assets. As long as that stream fits into memory right now, it only matters the assets that appear on the page. When I nail down the GUI more, i'm going to circle around and figure out ways to optimize that process to fit more. There is no reason quite large PDF files shouldn't be able to render though.

#167033 - Kilos - Fri Feb 27, 2009 2:47 am

Big post, here we go~!

Quote:
For book style orientation, any ideas on better keys to map to?


This is tricky because of the variations such as right handed, left handed, one handed holding, two handed holding. I'm thinking for one handed left hand holding (where your left hand is wrapped around the DS body), it'd be easy to have 'right shoulder + up d-pad' and 'right shoulder + down d-pad' because the left thumb is already on the right shoulder and a key combination would be required if the d-pad is used for the zoom box navigation.
I think it would be more convenient to have the buttons remapped depending on which orientation is being used.


Quote:

Do the mini-doc like how it is now, maybe bigger, and display a rectangle showing what is displayed on the screen. Let the user enlarge that rectangle by grabbing a side and dragging (zoom), and let the user move that rectangle by grabbing the center and moving it. Would this be a better experience? Would you expect that mini-view to disappear after you do one change or persist tell you tell it to leave?


I didn't even thinking about resizing the the zoom box with the stylus; that's a good idea. My personal preference though is least amount of touchscreen used the better, for this type of application anyways. Not sure about how other people feel about touchscreen usage on reader apps. As for the miniview...hmm...
I would expect it to remain on the bottom screen, but after examination, just one screen for the actual reading may prove tiresome. Perhaps a button on the yellow tool bar for toggling between bottom-screen-miniview and both-screens-document viewing? Then after setting the preferred zoom level, the user could toggle the miniview option off for dual screen viewing where he could then navigate via stylus (as you have now) or D-pad (=P).


Quote:

I'll have this in the next release. I was getting lazy in this one and just didnt include it. When you go to book-style orientation, would you expect those numbers to rotate?


Actually, I'm not quite sure. It would feel more polished if the numbers rotated, but it seems a bit unnecessary as you should be able to read the page number with it sideways anyways.


Quote:
How many people have the EXRAM carts?


I got a 3in1 for GBA support and to utilize homebrew that takes advantage of it (such as DSQuake and DSLinux). Since there is no GBA emulator for the DS, many people get 3in1s for that purpose, so there's a large segment of people that can use an EXRAM build right there. A regular build should be maintained though for people without slot2 ram (perhaps incorporate a check system during boot somehow? Seems tricky)
Maybe you could run a poll on GBAtemp (large community of average users as opposed to here, a community of mostly devs)?


Quote:

If its not a personal document, can you send it my way? I haven't noticed any fuzzy-test on other documents really


I believe it's the antialiasing that creates the fuzzy effect, I haven't been able to test any other documents yet so I do not know if it's just this one or not. Looks fine when zoomed in a good amount (50%- of the page width), but less readable when zoomed out. I am visually impaired though, so this may just be me.
Is there any way to change the font within PDF files or would that require more than Fitz/MuPDF can do? Because I had an idea of something like regular fonts at a certain zoom level, then a good pixel font when zoomed out enough. That way you could have regular text when zoomed in, but when zoomed out you could still make out the text due to the pixel font (also, more zoom outward -> more readable text on screen -> less fumbling with moving the page around and whatnot).

I know some stuff I'm saying might be difficult to implement, but I'm more or less just rambling my thoughts while attempting to keep them reasonable.

EDIT: Also, options/settings screen. Checkboxes for all the toggleable options suggested instead of cluttering the yellow toolbar or mapping insane key combinations.

#167039 - elwing - Fri Feb 27, 2009 12:11 pm

I got:
M3 perfect mini SD
M3 perfect lite
SuperCard MiniSD

yes, I definately have some slot2 memory... that said you are right, there is no reason why a 100kb pdf would run out of memory... EXRAM seems important to me, but there's prolly some optimisation to reduce memory use before adding EXRAM

you've done a great work that said...

#167224 - albinofrenchy - Fri Mar 06, 2009 3:27 am

I've been meaning to reply to this thread for about a week, but I was sidetracked with school. Sorry for the late replies:

@elwing:

You might have earned some nagging from me for testing with that information :-D.

I'm keeping my ear to the ground on this EXRAM stuff. I know a little more about it now, and I think if the right person points me in a direction it might be an easy thing to implement.

@kilos:

Quote:
This is tricky because of the variations such as right handed, left handed, one handed holding, two handed holding. I'm thinking for one handed left hand holding (where your left hand is wrapped around the DS body), it'd be easy to have 'right shoulder + up d-pad' and 'right shoulder + down d-pad' because the left thumb is already on the right shoulder and a key combination would be required if the d-pad is used for the zoom box navigation.
I think it would be more convenient to have the buttons remapped depending on which orientation is being used.


Right now I'm leaning towards just making it all customizable because you are right, everyone is going to hold this thing different. I think also that changing the mapping based on orientation is a double edged sword -- it will confuse many people who are new to the program, but people who know whats up will find it convenient.


Quote:
I didn't even thinking about resizing the the zoom box with the stylus; that's a good idea. My personal preference though is least amount of touchscreen used the better...


When I read this, I was a bit astounded! I thought it would go the other way with users; the more touch screen the better.

I thought very much about adding the D-pad feature in you talked about but I want to get more input on it. How much should it change the screen? With the render rate as it is, something like 1 px at a time is obviously too small. Ten is a bit tiresome too. Maybe it should go half the screen? What do you think? I also thought about making it wrap around -- if you hit 'right' when you are already at the far right of the page, it goes down some amount and starts over at the beginning. Would this be your preferred use case?

I've also considerably changed the mini-document view. If you still think it should be a toggleable thing as opposed to just existing till they click it, please tell me. The reason its not like that now is based on it being harder to achieve that effect and with this new release the mini-document view has evolved into something much more about zoom then about viewing or panning.


Quote:
Actually, I'm not quite sure. It would feel more polished if the numbers rotated, but it seems a bit unnecessary as you should be able to read the page number with it sideways anyways.


Yeah, this is a tough one to me too. I put them in, but didn't rotate them because I'm just not sure what to do with them.

About the exram stuff: I've looked into it a bit and its feasible. I should be able to automatically detect how much memory and all that is available and maintain only one build. The problem is I don't know how to make newlib's memory manager aware of the extra ram. The RAM intensive code is all a port from C code, so it all uses malloc and such. I've left a post on my blog as kind of a line in the water for this issue. I have a few large features I want to check off my list but then I think I'll circle back to this problem. If someone gets me going in the right track though and its an easy fix, I'll def. implement it though.

On the fuzzy text: The way it works now is that each file either uses a font built in to the pdf, or the program provides one of its 9 or so built in ones. Changing the used font while the page is open like that would be difficult and I'd probably break alot of things.


Quote:
Also, options/settings screen. Checkboxes for all the toggleable options suggested instead of cluttering the yellow toolbar or mapping insane key combinations.


An options/setting screen is something definitely on my list. I don't want more than 4-5 things ever on that bottom bar at once. Its in the pipeline, but I want to push out the reader mode before I move on to that.

Oh! The screen brightness: I looked up how to do that tonight, and expect that functionality to be in the next build (1.4). Its not hard, but I want to get this release out sooner rather than later. Its a good suggestion though, and will get done.

#167225 - albinofrenchy - Fri Mar 06, 2009 3:30 am

Sorry to double post, but I wanted to also put in a quick point that v1.3 is now available at the site.

Its got a load of new features and some bug fixes, the post about it over there has more info.

#167231 - samel - Fri Mar 06, 2009 9:47 am

one word ... GREAT!

#167302 - foxw - Sun Mar 08, 2009 4:02 pm

Your doing awesome man. Keep up the work.

I was going to just post this on your blog, but it's being wiggy and won't let me.

Few things i think would really rock on this thing.

1. Access to the embedded table of contents/bookmarks some pdf's have.
2. as another said, a popup move to page feature would be nice.

Over all, this just keeps getting better n better man.

Watching this project with great enthusiasm.

#167331 - albinofrenchy - Mon Mar 09, 2009 9:42 am

I put a poll on the blog about GUI's, specifically what the hell to do with the d-pad.

I want to ask everyone to go ahead and vote if you care, and also give me more ideas for GUI polls...

Thanks![/url]

#167372 - foxw - Tue Mar 10, 2009 11:27 am

Saw the poll Albino.

Personally, what i think would feel the most intuitive would be as one of your options is.

D-pad for on page movement, utilizing 2 abxy buttons to forward, back buttons.

leave the L & R shoulders out of it least for basic things as unless your holding it horizontally, (not like a book) it's counter intuitive and rather clunky.

a easy to do control scheme that would feel natural might be

Dpad for movement in page, and two next, prev buttons on your empty tool bar

#167374 - samel - Tue Mar 10, 2009 11:58 am

Why not:
hold like a book,
stylus scroll,
d-pad left and right for prev/next page.

#167543 - albinofrenchy - Tue Mar 17, 2009 9:15 pm

Version 1.4 has been released!

My internet connection is shaky so I must keep this quick. From the page:

Quote:
Changelog from 1.3 to 1.4:

Features:

* New viewing mode. This is the 'reader' mode. More on that later.
* D-pad now pans the screen. I got alot of requests for this one!
* File browser is now filtered; will only show PDF files. Note that it will show folders that don't have PDF files in them.
* You can now adjust the backlit brightness by holding down Select + Up/Down arrows.
* You can now cancel out of the file browser with 'B', or by clicking the file browser button again.
* Rendering is getting progressively faster.
* Mini-help screen and info screen on startup.
* Added splash screen. If you find this annoying, remove the splash files in the FONTS folder, and it will bypass this step.
* Fonts are external now. This gives us alot more memory to play with at the expense of higher load times on certain PDF's. (Note: I took out the dingbats font. If anyone as a PDF that has dingbats, I will hand out that file too... It is much larger though).

Bug Fixes:

* You can no longer scroll off the bottom of the file browser.
* Some memory issues resolved that led to instability.
* The zoom-tool used to mess up if you clicked it more than once. Doesn't anymore.
* Tons of other stuff I'm sure...


Enjoy...

#167597 - amchacon - Thu Mar 19, 2009 4:32 pm

Hi, I am spanish

I love your project, thank you

I have an idea on memory, When the program opens a pdf. He just load the first page, when you change the page the memory RAM is cleared and the next page is loaded. So no problem with the limited memory

Greetings

#167600 - Ludo6431 - Thu Mar 19, 2009 6:30 pm

I think this is already done ;)
_________________
Sorry for my poor english, I'm french.

#168535 - AbyssalNuclei - Sun May 03, 2009 12:25 pm

[Images not permitted - Click here to view it]

Please click. My thoughts on this :D

#170480 - sverx - Tue Sep 29, 2009 9:54 am

Hi! Thanks for making this program.
I would like to use it for reading a newspaper I subscribed recently, but the size of the PDF they're distributing is about 7.5 MB and contains pictures and images... I had no luck opening it.

Is it because of its size or because of the images? I could try to separate the PDF pages to distinct files if the problem is the size... but can I deactivate images?

Thanks for your help. The PDF of the first issue is here (it's freely accessible) if you need to check it.

#170491 - KillerMapper - Tue Sep 29, 2009 4:16 pm

Too big and too much images I think. I had myself difficulties about opening a pdf with a few little pictures, some pages can't be loaded.
_________________
www.mariokartsource.com