Historically, many people have proposed improvements to the pdf viewer. Many different versions of the viewer have been released, each with different features. To help solve this babel of versions, I propose that we create one centralized community version of the iPDF viewer, containing as many of the patches as can be comfortably combined together.

I'll volunteer to maintain this distribution, at least to start with. If you have comments, ideas, suggestions, or discussion, please post it here. Please post ONLY comments and discussion in this thread. Submit patches in the patch thread.

I started this thread for discussion about particular patches, the project as a whole, and feedback for released versions. There is a second thread specifically for patch submissions. When the a release version is ready, I will start a third thread specifically for releases.

What do you think?

Great idea. That would really make our lifes easier. Thanks for your work.

This is actually a follow up from the other thread where I proposed a 2 column view. This afternoon I took a look at the ipdf source and partially implemented it, where "partial" means it only works with portrait view and only split the view 4 ways (for 2-column) and move in a direction like |/|. I also changed the zoom level for A4 to 300 instead of 200.

It took me a while to figure out the coordinate system, but in the end I got it to work as I intended. But I don't think I'll submit the patch because:

1. it's more of a hack than a well thought-out and well organized patch;
2. ipdf is fundamentally flawed in its way of doing zooms, and I don't think it's a good foundation to start with;
3. ipdf itself is not well designed, and the division between portrait and landscape views is also flawed, and results in redundant code for all future patches.

Seriously, I suggest someone start writing a new PDF viewer for iLiad instead of patching ipdf. Given that the size of ipdf is relatively small, just fixing 2 and 3 is almost a rewrite. While I'm at it, it'll also be super to have anti-aliased sketching like in xournal (http://xournal.sourceforge.net/), which, by the way, allows loading and annotating PDFs, or maybe somebody like Adam should just port it to iliad :-)

I'm attaching my 2-column ipdf binary here just in case it might be useful to somebody else. Make sure you backup /usr/bin/ipdf binary before using this to replace it. Use uparrow (I re-used the same button from jharker's fullscreen patch, I'm lazy!) to toggle column view, use normal flip to go forward and backward.

Would it be feasible to allow users to pick the patches they want and apply them with some sort of patch management system, or would that just be asking for trouble?

The patches I'd particularly like are the comments/bookmarks and column browsing. The full-screen thing never really mattered to me, but it would be ok if the new version has that, too, if an individual patch system doesn't make sense.

Nice initiative Jharker, we might be interested to make it into an iRex Community Project. This would mean that we could integrated certain features into the stock viewer.

If you are interested let me know, we are happy to provide a development iLiad and support.

JHarker, excellent initiative!

First off though, do you need some of my patches again, or are you happy with them still? I guess it's really only quick erase and scribble toggles that are in at the moment.

I also agree with alanine, in that specially the landscape/portrait views are badly implemented. I do however believe it would be fairly simple to create a parent class with all but the x-y calculation humbo jumbo left out, then inherit from that one to create the specific views.

Maybe I should take a look at "evince", the Gnome document viewer. I believe it is largely a GTK app, with Gnome libs for printing (which we could manage fine without), and it supports some nice things like thumbnails, remembers last position , indexes and so on. Also, it supports more than just PDF, but you can google for evince by yourself. :-) It's a fast application, but would require integration with scribbles, hardware buttons and there is no rotate function. It does however have continous mode.

Does anyone know if xrandr is supported on the iLiad? If it was, we could just rotate the X display... The rest should be pretty automatic.

Edit: Karel, I believe you mentioned (someone at iRex at least) that you would provide a "community" SVN branch. It would be excellent to have access to the full community IPDF source in a proper environment.

Edit2: And evince can rotate documents, and it does so *very fast*. I'll se if I can figure out the dependencies and see if I can make it work.
/r

Excellent idea JHarker.

You might want ppl to post patches against the latest released community version as well as against the irex standard in order to minimize the integration work.

Apart from the portrait/landscape code overlaps I feel that the ipdf renderer needs some work:


The prerendering deleter is dumb: it routinely throws away rendered pages that are needed in a few seconds when memory is low, just because they are the oldest rendered pages.
The prerendering routines should be made to work with multiple zoom rates; this allows ppl to switch zooms on pages much faster. We could do all kinds of stuff with this; show ppl a tiny page at the top of the screen while panning, rapidly switch zoom if needed for a wider column in column mode, etc.
Wilder idea: the renderer/poppler could render to "Mono4", and store 2 pixels in every byte. This way prerendered bitmaps are much smaller, and we would be able to hold twice as much in memory. Display would be slower (have to test how expensive this is), unless we can find some shortcuts in the (not released) fb code.
And even wilder: allow ppl to use a server based renderer, and allow the ipdf renderer to talk to the server via wifi. No more memory restrictions on prerendering.


Also, there is a lot of non-functional whitespace in the irex code; not important in any sense but nice to remove if we are going to clean house anyway.

If you're going to be overhauling the pdf viewer, I'd like to see a thumbnail view page selector. I.e., display a 4x4 grid of page thumbnails with scribbles, and allow the user to tap one to go to that page. Page bar to view the next set of thumbs (which could probably be generated in the background while the user is scanning the first screen). This would allow quick navigation to places where we've made notes, as well as other easily recognizable pages. Often we can recognize pages by the general shape of the text, as well, so if we're looking for a page with a particular illustration or a long passage of dialog, we'd be able to get there more quickly. Page turning on the iLiad is a bit slow due in part to the e ink refresh rate -- I'm thinking this would help take the place of quickly fanning through a book or notebook to find a particular page.

Hi, everybody! Wow, lots and lots of great responses! Things have been really busy the past couple of days and I haven't had time to respond the way I'd like, but I wanted to let you know I'm still here!

Here's a somewhat abbreviated reply... If a patch has been posted elsewhere, or sent to me previously, I'd still like the author to post the patch specifically in the Community iPDF Patches thread. This will remove a lot of work for me in terms of finding, cleaning up, and documenting patches. It will also make everything available in one centralized place. Finally, it will hopefully make new authors think about the quality of their patches in the context of a larger project, hopefully leading to higher patch quality and fewer conflicts in general. That said, many people (rincewind, wpd, etc.) have made excellent patches that I expect to work with little or no modification. But please submit them in the patch thread so I don't have to! ;) I love the idea of this project being encouraged as an iRex Community Project. I don't know if my role warrants a whole development iLiad, although I wouldn't say no! Perhaps we should wait until the first release to gauge how much interest there is, before you decide if it's worth it? I don't want this to become a full-fledged fork of the iPDF software, at least not for now. However, I agree that there are lots of parts of iPDF that could be substantially improved by a large rewrite. If anyone submits a (large) patch to overhaul the rendering / pre-rendering system, the landscape/portrait split, or anything else, I would certainly consider it and it would be more than welcome. I might even eventually get around to writing one myself... I like the idea of a "feature selector", we'll have to get someone to write a patch for that... :D All the other ideas that have been proposed sound great, too! For now, I'm asking for patches to be based off of the latest svn. But in the future, as wpd suggested, this will change to either more recent svns, or possibly with reference to the current version of community ipdf.

While we're throwing out ideas, here's one aimed at Rincewind because you've done a lot with gestures, and I don't know what you've already done that I haven't seen... If some simple, easy-to-use gesture-based UI could take the place of the erase, pan, scribble, and zoom buttons, that would clear up a lot of toolbar space. I'm thinking of something as intuitive as the iPhone gestures...?

Regarding the portrait/landscape split, the two are even more alike than you might suspect. If you compare the differing math sections, you'll see that they LOOK different because they're written differently... however, if you actually do the math you'll see that many of the calculations do the same thing, just using different variable names or a slightly different order of calculations (i.e. in portrait it's foo = bar - x; and in landscape it's foo = bar; foo -= x; ). So I suspect that once these incongruities are ironed out there will be very few places where it's actually different.

As far as I know, iRex is still working on a modular viewer base that will eventually replace iPDF. Does anyone know if that's still in the works? And whether it will be open-sourced?

Okay, that's all for now, I have to get back to work! So far so good! Let's see those patches!

Very well, I'll get around to updating the patches for the svn version, and posting them. :-) Hopefully I'll have some more time to fiddle with this as I just finished my PhD the other day. :-D

As far as I know (this was the story some months ago at least), the new wunder-viewer from iRex will be closed source. So, if we do a massive clean-up of iPDF, I for one will keep using it even after the new viewer has been made...

When it comes to gestures, I have got some work to do. I'll either find some free library to recognize gestures, or create something myself. I really would like a map of gesture-to-function, making it possible for users to configure or customize them if they like. The iPhone is a multi-touch screen, meaning that for example zooming (drag two fingers away from each other) does of course not work on the iLiad. I hope to create/use something that allows me to specify gestures as right-downleft-right (for a Z) and map that to a function.

On a somewhat different note, I really would like to have a mode to let my iLiad control a presentation... I would then have the presentation (with some notes) on the iLiad, and when I press "next page", it would send a message to the computer doing the displaying... Anyone else in for something like this?

/R

On a somewhat different note, I really would like to have a mode to let my iLiad control a presentation... I would then have the presentation (with some notes) on the iLiad, and when I press "next page", it would send a message to the computer doing the displaying... Anyone else in for something like this?


So far only thing come to mind is to export DISPLAY to another Linux box that connects to a projector, though I've never tried it.

Excuse me. Could you please tell me how to install and simply add the column mode (made by WPD) function to my ipdf without cancelling the functions of bookmarks and fullscreen? Could one be so kind to make an installer? I am sorry for my ignorance. Thank you very much.

Hi, good153! At the moment, there's no way to do that until someone makes a version that includes all the improvements. But you came to the right place, because that's exactly what this project is about! As soon as those patches are submitted, I'll be releasing a version of ipdf that includes all those features.

Which reminds me, since I'm the author of the fullscreen patch, I guess I should submit it. :)

Theoretically one could make a content-lister runnable patch script with the ability to trigger patch application and a recompile, if there were a compiler ported to the iLiad itself... but that really seems like overkill (if doable at all).

I'd really like the multicolumn feature myself, though. I think I'd use it more than any other community-generated feature, with the possible exception of comments/bookmarks. However, from the description, I think the multicolumn feature as written would only work for text-based PDFs, not image-based (scanned) PDFs. Am I misinterpreting the patch description?

... from the description, I think the multicolumn feature as written would only work for text-based PDFs, not image-based (scanned) PDFs. Am I misinterpreting the patch description?

This is correct. It is based on text, so you would not benefit when reading scanned PDFs.

When I was using the fullscreen version of ipdf I would often find that I needed to activate the toolbar to get to a function (erase or zoom to full page or change the pen or something) and once that was done I'd want to go back to the fullscreen view. It occurs to me now that it would have been handy if the toolbar could have been activated for a second or so and then disappear again without me telling it to do so. Maybe 1 second after the last icon was activated would be the best.

And then extending that idea it occurred to me that perhaps it be possible to have different sets of toolbars that could be activated by different combinations of long or short presses of buttons. Or perhaps activated by different jestures. A squiggle in the bottom left corner could activate the current set of buttons; a squiggle in the bottom right corner could activate another set of buttons; etc.

I couldn't actually code any of this I'm afraid, and it is not even a wishlist, just throwing an idea out there.

I'm not a huge fan of hardware shortcut keys... while they may be okay for you and me, for wide use I think it's better to have a few really simple shortcuts. Originally the fullscreen patch had a "show/hide the toolbar" shortcut: pressing a hardware button toggled toolbar visibility without re-zooming the document view. But in the new version this was eschewed in favor of a simpler interface.

I think it would be very easy to make a series of shortcut gestures for commonly used toolbar buttons; in fact, Rincewind has already done lots of work on this. The difficulty is obviously that the gestured would have to be more easy to use and intuitive than assigning hardware shortcut buttons.

Here's one (too complicated?) idea for a gesture library. With all these gestures we could eliminate a bunch of the toolbar buttons. Link select: tapping the pen on the screen, on top of a link, automatically follows the link, no matter what. Scribble: Scribble is the default behavior. Every gesture draws a line on the screen. Line width varies according to pressure between the current line width +/- 1. If an Erase, Pan, or Zoom gesture is used, the line is automatically erased. Erase: Scribble a line, and at the end of the stroke, hold the pen steady for half a second. An the "erase" icon appears in a corner of the screen, and any scribbles the stroke intersects will be erased. Pan: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Move the pen to a new location and release. The document will be panned. Zoom In: Place the pen on the screen and hold for half a second. A "hand" icon appears in a corner of the screen. Draw a box or other shape with the pen, returning the pen to its original position, and hold at the final position for half a second. The "hand" icon changes to a "zoom" icon. On releasing the pen, the document zooms. Zoom Out: A double-tap zooms out 50% from that point. A triple-tap zooms to page.Some of these (especially zoom) are a little inelegant. I also thought about using a double-tap instead of "press-and-hold" to start a gesture. What do you think?

Nekokami, compiling at run-time is probably overkill (not to mention it would take forever!). You got me thinking, though...

A commonly used strategy is to implement command-line options for different features. We'd just have to augment whatever the current command-line interpreter is, which would be very easy. Then, when the command-line interpreter sees a command-line option "-useFullscreen" it sets a global variable value in the code, "useFullscreen = 1;". Everywhere within the code that the fullscreen fuctionality is implemented, it's in a wrapper likeif (!useFullscreen)
{
//do normal stuff
}
else
{
//do fulllscreen stuff
}
This way we can have a simple utility that runs with a bunch of checkboxes for different options. Running the utility makes a simple alias script for ipdf, so that when the contentLister calls /usr/bin/ipdf it's really calling a script that looks like#!/bin/sh
/path/to/real/ipdf -useFullscreen -useColumns -useGestures
I think this would do the job. Writing the GUI option selector utility would be fairly straightforward. I think even I could do it!

I certainly would not have wanted to compile every runtime! But your solution sounds much more elegant, anyway.

Oh, I forgot-- another reason not to compile on the iLiad is that it's not possible. Compiling requires having a huge stock of support libraries and tools which take up a lot of space. The Linux on the iLiad is a bare-bones, trimmed-down version with normal utilities and functionality, but there's no development environment and no space for one... :cry:

On the configuration and gestures...

There is a directory on the iLiad (don't remember where), where we can store user configuration data. These will not be overwritten on flashing. I suggest using an ipdf.conf file there (or .ipdfrc) to hold these settings. This would allow us to have a lot of settings (of we want), an editor for the settings and not have to fiddle around with any startup scripts. We should of course use default values for configuration, f.eks. fullscreen is on by default, if not noted in the config file as otherwise.

When it comes to gestures I have started to implement (getting close now) a framework that analyzes gestures for left-right-up-down movements. I'm also creating a function to map such movements to functions, which I believe I will read from a config file, as mentioned above. In this way, users can configure their own gestures for a set of pre-defined functions... For example, I believe a gesture "UP" could make the pen thicker, "DOWN" make it thinner, a Z or similar start zoom and so on. This would be more generalized than jharker's outlined solution above, but I believe it would give us more opportunities to experiment with what works and what doesn't. :-)

Any thoughts?

/R

Hey, Rincewind! I like all of that. I really like the idea of a generalized gestures framework. If you could add double-tap and tap-and-hold detection to the gestures framework, that would be great. That way, a user could customize virtually any sequence of gestures to mean something. And we could have a default set of gestures for users who don't want to define their own.

The current set of gesture definitions could be included in the .ipdfrc file and editable in the ipdf-config utility...

Maybe ipdf-config could have "simple" mode, where you associate functions with predefined gestures, and "advanced" mode, where you can create your own gesture definitions...

For now, maybe we can determine a good set of default gestures and implement those, then in the following version add customizability, and the release after that add "advanced" mode. That would maintain backwards compatibility but still be able to include gestures in one of the early releases...

What do you think?

I really like the gesture idea.

And what i would like to see, is a search and a oneklick dictionary lookup.
I have no clue about poppler and ipdf, so does anyone know, if this is possible without too much hassle? Does poppler support search? Can we use the mobipocket dictionary while using ipdf?

Hmm... well, for non-scanned pdfs (that is, pdfs with actual textual content) I would guess we can get the full text from poppler. But jumping from that to a usable search function will be more difficult, I would think...

Do you mean dictionary lookup as in, "click on a word and get its definition"?

Well, i was hoping, that poppler somehow offered some search algorithm, wich returns pagenumbers for a searchpattern. But it seems, nothing the like is available in that package.

Do you mean dictionary lookup as in, "click on a word and get its definition"?

Yes.

Hey, Rincewind! I like all of that. I really like the idea of a generalized gestures framework. If you could add double-tap and tap-and-hold detection to the gestures framework, that would be great. That way, a user could customize virtually any sequence of gestures to mean something. And we could have a default set of gestures for users who don't want to define their own.


Tap-and-hold is the way I detect gestures in the first place. :) I would hope that we, after some testing, will end up with a set of good gestures that covers most users needs. In that way, the iLiads can be "standardized" a bit, making it easier to create documentation and a well thought through interface. I do however like us "power users" to be able to fiddle around a bit, seeing what works and what doesn't. So I'll read an .ipdfrc file, or use default gestures if that does not exist. I do however guess giving the user feedback can be tricky due to the slow display, so we'll have to look into that. In your examples further up, you said "show a hand and drag" - now showing that hand will take more time than I'm willing to use. :-) Notice that I use drawing mode when using gestures (I can't remember if you HAVE to use draw mode), so you will actually see the gesture being drawn. Could be enough - I don't know.


The current set of gesture definitions could be included in the .ipdfrc file and editable in the ipdf-config utility...

Maybe ipdf-config could have "simple" mode, where you associate functions with predefined gestures, and "advanced" mode, where you can create your own gesture definitions...


I'm a Gnome kind of guy, so I would like gestures to keep everything as simple as possible. The .rc file will be very simple, e.g. each line contains one gesture, in the format "Right-Down:DecreasePenSize".


For now, maybe we can determine a good set of default gestures and implement those, then in the following version add customizability, and the release after that add "advanced" mode. That would maintain backwards compatibility but still be able to include gestures in one of the early releases...

I'll just make some that springs to mind, and we can easily add more. The only thing that would require some time is to add double-taps. Adding new functions and default gestures should be very simple, so we can all wrap our minds around that when the time comes. :-)

/R

Rincewind, I agree with pretty much everything.

Using tap-and-hold as a universal indication of the start of a gesture is perfect; I hadn't realized you included that as universal. Also, I like having all gestures produce the visual cue (a line on the screen).

I think that adding a little icon in the corner wouldn't be TOO hard to do, but I'll look into how to do that and implement it myself in v2 or v3. :) This is because, if the default behavior when NOT gesturing is to scribble, how would a user know whether they had successfully started "gesture mode" or not?

It occurs to me that there might be two paradigms for how gestures might work... one is, you make a gesture (i.e., draw a Z) to start zoom mode, then you actually draw the zoom box. The other paradigm is, the zoom box is part of the gesture (i.e., press and hold, draw a box, come back to where you started and hold, release and it zooms). It seems like enabling both paradigms would be more complicated...

If "tap-hold" is the universal start to gestures, that would be pretty easy to remember. If a line is going to be drawn when gestures are made, could it be a lighter shade of gray or a dotted line or something, just to add that visual difference from regular scribble mode? I know you can scribble in lighter shades, so I don't know if that would be enough of a visual difference, hence the dotted line suggestion. I don't scribble in lighter shades myself, though.

Well, I flash the LED when a gesture is being drawn. It does however only start to flash when you start to draw the gesture, as I don't get any events when the stylus is being held still...

I've completed the implementation, including config file today during a conference, but I haven't gotten around to test it yet - I needed it to get home on the plane. :-) I'll try to provide you with a binary when i've tested it a bit, and then I'll clean up the patch and document it before posting it. :-)

/R

IIRC, the LED flashes during scribbles, too. (I left my iLiad at home this morning and can't check.) So some other visual difference to indicate that the line isn't a scribble would still be helpful.

I'm fairly sure it doesn't, and I also think that I made the light stay on, not blink. However, you will see if you are performing a scribble on the LED, believe you me. :-)

I've tested this some now, and I think it looks pretty, pretty, pretty good, to quote Larry David. :-)

/R

Ok, I made the gesture patch available in the other thread. Patch post (http://www.mobileread.com/forums/showthread.php?p=111678#post111678)

It also contains some information about the functionality.

jharker, could you post your full-screen patch too, I really would like to run with both. :-)

/R

Rincewind, that totally rocks!

I've been up all night preparing a seminar, so I'll be crashing hard for the next couple of days. I'll post my fullscreen patch by Monday at the latest.

I think someone did a bookmarks patch, right? Who was it? My brain is mush right now... anyway, I'd love to see that submitted, too.

If anyone else wants to submit a patch for the first release, please submit it in the patch thread by Sunday Nov. 11. The first community ipdf release will be Tuesday Nov. 13.

Yay!

[...] I think someone did a bookmarks patch, right? Who was it? My brain is mush right now... anyway, I'd love to see that submitted, too.


Mike Kostousov did. Here's the thread: http://www.mobileread.com/forums/showthread.php?t=13914

Please please please include Mike's bookmarks patch.

And you've got the column-following one, right?

The only other thing we could really use is a manual column mode for scanned multi-column documents. Sort of a backwards-N pattern per page. That doesn't seem like it ought to be terribly hard....

I guess many people will agree that's more useful word highlighting than scribbling in a text pdf. Would be that possible? I think it would be a very nice feature to include.
By the way, thank you very much to everybody, community has speed up things dramaticly, Irex improvements to iLiad have been scarce since the beginning (from my customer point of view).
Keep the good work!

Hi all,

here is a binary "pre-release" of IPDF with both fullscreen and gestures. Just in case anyone wants to test gestures without loosing the precious fullscreen mode. :-) Also, applying both patches does require some manual interaction as they put code in the same place...

/R

How easy would it be to have ipdf read a password stored in the manifest file? I have started buying ebooks instead of pbooks. If the book is encrypted the keyboard comes up to allow me to enter the password. Typing on the keyboard can be error prone and because you can't see what you are typing it is hard to know if you have made a mistake. The first ebook I bought used my email address as the password and this was very long, longer than the visible space for entering the password and it became very frustrating trying to open it. It would be nice if the password could be stored in the manifest and read by ipdf. I have no problem using an editor to enter the password into the manifest because I would only need to do it once.

Hi

Thanks for all your work first!

A question: Will the link function be reactivated in a new release?
For me it is extremly useful to follow links in pdf (like footnotes, table of contents etc.) - and I am missing it in fullscreen pdf.

Thanks
Olivier

A question: Will the link function be reactivated in a new release?
For me it is extremly useful to follow links in pdf (like footnotes, table of contents etc.) - and I am missing it in fullscreen pdf.


The links are there, just not in "scribble" mode. They never were there in the iLiad ipdf either, it's just that the community version default goes into scribble mode. I'll think about adding link clicks to the scribble mode too, and just hope that nobody wants to write a "dot" on a link. :-) I'll se when I have time to investigate that further.

To follow links, disable the scribble mode (press the darkened pencil button), and you can follow links. Note that gestures depend on scribbles, so you will need to toggle scribble mode again before you get those back.

/R

I would greatly appreciate it if you could post the source to the patched ipdf somewhere. Or perhaps it is somewhere and I just don't know where to look?

Rincewind, thanks for your answer, but what is the "darkened pencil button"? uhm uhm :punk: Did I miss something?

Your idea to activate linking just over links and have scribbling 'around' is very nice IMHO.

Greetings
Olivier

Rincewind, thanks for your answer, but what is the "darkened pencil button"? uhm uhm :punk: Did I miss something?

Your idea to activate linking just over links and have scribbling 'around' is very nice IMHO.

Greetings
Olivier

On the toolbar there is a pencil. If it is dark (selected), you can scribble. If you press it, it will become light, and you cannot scribble. :-) On the other hand, you can follow links. This is the default operation in the official IPDF.

/R

I would greatly appreciate it if you could post the source to the patched ipdf somewhere. Or perhaps it is somewhere and I just don't know where to look?

The full source is not easily available yet, but the patches thread on this forum contains some patches. The fullscreen patch is available in the iRex forums.

Just to make it simpler for you, here you have the full source code with fullscreen and gestures/quick erase + some other small things. Note that this is only my own copy - I think the "community ipdf" jharker administers has a somewhat different keymapping (hardware keys), and of course the multi-column patch and any others have not been added. Because I don't use them. :-)

/R

The full source is not easily available yet, but the patches thread on this forum contains some patches. The fullscreen patch is available in the iRex forums.

Just to make it simpler for you, here you have the full source code with fullscreen and gestures/quick erase + some other small things. Note that this is only my own copy - I think the "community ipdf" jharker administers has a somewhat different keymapping (hardware keys), and of course the multi-column patch and any others have not been added. Because I don't use them. :-)

/R

thanks for the sources. For next time you can try the svn export command ;) It will copy all the sources to a new directory which you can pack and send without including the svn metadata.

Rincewind: Thank you very much for this hint!

I also like the idea doing gestures especially for zooming, because this is rather difficult when using fullscreen now (acivating toolbar, estimating zoom range, again fullscreen - oh there is missing a line, beginning with fist step).

The thing with the gestures could be developped further.

Olivier

Hi,
I replaced the ipdf-file in /usr/bin via emel2FM and use now Rincewinds with a size of 99.168, it opens a newspaper-pdf of 8 MB (normally zoomable) in scribble-mode, press and hold the pen produces the LED-lightning but - snif - none of the described gestures work.
Before Rincewinds ipdf i used the original one vom irex..

Somebody has a hint for me? :pray:

greets
nkelle

Hm, that sounds strange... Do you write quite straight lines and approximate 90% angles? If you get the LED on, you are drawing gestures... If you draw them very small, try making them bigger. Size shouldn't matter much, but each line has to be more than 10 pixels in one direction.

I'm thinking of some way to give feedback as to whether a gesture was recognized or not, but the slow eink makes it difficult to not "get in the way" of efficient operation.

Try drawing larger, and try to make the lines pretty even and at 90% angles - and tell me if you get it working! :-)

/R

I wonder if a "training" PDF would be helpful, a single page with an example of each gesture followed by a short explanation of what it does. If someone follows the example gesture exactly and doesn't get the correct response then there is something wrong.

It might even be possible to include some examples of what won't work (too small, wrong angles, etc.).

It does seem to me that if we have to make a manual, then the gestures are probably not intuitive enough. :) However, at the moment it's just cool that we have gestures at all, thanks to Rincewind. I expect that the interpreter will get more subtle, accurate, and intuitive in subsequent versions!

I guess many people will agree that's more useful word highlighting than scribbling in a text pdf. Would be that possible? I think it would be a very nice feature to include.
By the way, thank you very much to everybody, community has speed up things dramaticly, Irex improvements to iLiad have been scarce since the beginning (from my customer point of view).
Keep the good work!

I would love to be able to select text with the pen and copy it to the manifest (or other text file) along with the page number. I would also like to be able to scribble in the margins. A combination of these two functions would be perfect - I highlight text, and briefly note why in my scribble. I then integrate the manifest text notes into zotero (or bibtext or whatever), alongside the pdf in which I have merged the scribble. If I can't remember why I selected that particular section of text, I can go back through the PDF, using the page number of the selected notes to guide me.

Hi all,

here is a binary "pre-release" of IPDF with both fullscreen and gestures. Just in case anyone wants to test gestures without loosing the precious fullscreen mode. :-) Also, applying both patches does require some manual interaction as they put code in the same place...

/R

I've installed this version of the iPDF and the gestures work great (haven't tried them all though.) I really like the ability to draw a bounding box around the text and have it zoom in. However, I'm having trouble getting the toolbar to toggle back on (e.g. go out of full screen mode.) In the previous fullscreen/bookmarks patch that I used, clicking and briefly holding the 'up arrow' toggled it on and off. Now, when I hit the up arrow, the LED begins to blink, but the toolbar never appears. If I hit either of the arrows or the center button, the led stops blinking and the screen refreshes, but still no toolbar.

It's great fun playing around with this thing! It's almost 2:30 and I still haven't done any work!

thanks rincewind, for this patch.

best,

Matt

The fullscreen patch I used was the "official" one from the iRex forum. It's still jharker's excellent patch, but you must now press the "back" button (the one all the way at the top of the iLiad) - sort of "go back" to non-fullscreen.

Great to hear that the gestures seems to work for some at least. :-) I actually didn't ever adjust the core-implementation (that I performed during a conference), as I have never managed to mis-draw any gestures. If anyone are bothered, or have ideas of how to improve the implementation, please feel free to tinker. :-)

It works now by creating a box 10 pixels to each side of the pen point. When the pen leaves the box, the direction is noticed (only left-right-up-down for now), and a new box is created. When the direction changes, it is added to the gesture, so you don't get "right-right-right-right-down". :-) Should allow us to scribble as large gestures as we find useful. :-)

/R

There's been an ongoing discussion about how to reference ebooks in scholarly works. Many people think that we may end up going by paragraph number, since page number may vary so much between editions. Would it be possible to put a tool in ipdf that would allow the user to tap an icon, then tap a paragraph to get a popup with the paragraph index number (on text-based PDFs)? Or a gesture would be fine.

There's been an ongoing discussion about how to reference ebooks in scholarly works. Many people think that we may end up going by paragraph number, since page number may vary so much between editions. Would it be possible to put a tool in ipdf that would allow the user to tap an icon, then tap a paragraph to get a popup with the paragraph index number (on text-based PDFs)? Or a gesture would be fine.

Wouldn't it be easier if scholary works just used numbered multi-level paragraphs, like "§2.3.1 Other options"? Then it would be visible without any hassle. Lots of authors already use that. The others don't deserve to be referenced :)

Besides, this is already a problem with paper editions; you have to refer to page number on a specific edition, since the layout/paper size might vary. Mighty annoying if you have another edition and have to guess which page they mean.

Rincewind, I just had a thought: have you considered implementing the Graffiti input method as gestures? Or something similar? There is no handwriting recognition for Linux, as far as I've been able to determine. If you've got a general algorithm that could provide that, or at least a step towards it, you might be on your way to being extremely popular, and not just for iLiad users. :)

Or something like Quikwrite - already written in Java, perhaps easier to transport?
It needs some learning though ...

http://mrl.nyu.edu/~perlin/demos/Quikwrite2.html

Rincewind, I just had a thought: have you considered implementing the Graffiti input method as gestures? Or something similar? There is no handwriting recognition for Linux, as far as I've been able to determine. If you've got a general algorithm that could provide that, or at least a step towards it, you might be on your way to being extremely popular, and not just for iLiad users. :)

http://risujin.org/cellwriter/

This is hand-writing recognition for linux. I have not tried it, just happened to read about it the other day. It uses a specific entry panel, like the current hand writing input on the iliad, but it also has a way of training it which the iliad does not, AFAICT. I wonder if the guts of this could provide the general algorithm?

jharker, how is the "community release" coming along? Have you heard anything more from iRex in regards to SVN access? Should we host a repository ourselves? I have got a linux box (slow, but with plenty of bandwidth), if iRex is reluctant or slow. I also guess we could have a bug tracking thing going (I could host that one too), just to get things in place.

Any thoughts? Should we register a name for it? :-) I guess that between iRex creating the closed source "mother of all viewers", and ipdf really needing a real fix in the structure of the code, it is getting tempting to simply do a fork and start on our own...

/R

When it comes to handwriting recognition, I really believe that it is far too inefficient yet. I've tried several ones. The Ipaq (running windows mobile), is not that bad (when writing english), but it is still horrible. The thing is that there tends to be a lot of bad matches, combined with a slow writing speed. The "cellwriter" seems to be slow, as you must type every letter by itself, and there is only a small space to write. Also, the iLiad is so slow to update the display, that you'll not be aware of any errors for seconds after writing them.

Another issue is that the recognition is always at the bottom of the screen, which means that you're hand is not over the text, but also that you have horribly little support for the hand.

So I'll keep writing my shaky hand as scribbles for a long time.

Oh, and after two years with a Palm III, I still was utterly useless with Graffiti, so I'm not implementing that. :-) I also tried Familiar Linux on the iPaq, both the built in QT one, and "Rosetta" (with learning), and they worked out really horrible. My last experiment was with the Linux based Nokia 770, and even though it sort of worked, I could type on the on-screen keyboard 10 times faster.

Anyone else actually tried handwriting recognition software? I hear the post-processing one that iRex sells is supposedly quite ok, but that is run afterwards, and not real-time. Might be more sensible though. They have a free demo out I believe.

/R

[...] Anyone else actually tried handwriting recognition software? I hear the post-processing one that iRex sells is supposedly quite ok, but that is run afterwards, and not real-time. Might be more sensible though. They have a free demo out I believe.

/R

I tried the free demo once, without training it and I was pleasantly surprised at how well it worked. I haven't tried it since ... I need some spare time to play and have none these days.

Try drawing larger, and try to make the lines pretty even and at 90% angles - and tell me if you get it working! :-)
/R
Uff sometimes I should only do what someone else has written..
The pre-defined gestures are:
LEFT-UP: darker color
LEFT-DOWN: lighter color
RIGHT-UP: Thicker pen
RIGHT-DOWN: Thinner pen
RIGHT-DOWN-LEFT-UP (draw a box): Zoom in using the box (very cool!)
DOWN-UP: Refresh the screen
...seems I am a bad speller, interchanged left and right :smash: and retried to fast, don´t give ipdf a few seconds to do it´s work :smack:
Sorry!

CellWriter looks interesting. What I really want, of course, is what the Newton had. :( That was the best handwriting recognition I've ever personally experienced.

I trained myself to use graffiti by playing Adventure on my Palm Pilot. :D But real HWR of some kind would be better.

I'm just glad you got it working. :-)

/R

Hi, all! Quick update. I'm still out of town, so the first community ipdf release will be delayed a couple of days. The floor is still open for patch submissions.

Mike Kostousov, I would love to add your bookmarks feature! Any chance you can submit a patch in the next few days?

Will there be a search feature included in the first or future release?

Mike Kostousov, I would love to add your bookmarks feature! Any chance you can submit a patch in the next few days?
I hope you also sent him a PM and/or email -- this is the primary enhancement I need....

I trained myself to use graffiti by playing Adventure on my Palm Pilot. :D But real HWR of some kind would be better.
I trained my "off" hand to write graffiti. For some reason, although I do everything else right-sided (scissors, archery, racquet sports, kicking), I write left-handed, so when I got a Palm Vx I taught my right hand Graffiti. It was quick and easy because that hand was dextrous and "wired in right", but didn't have any training for "normal" handwriting.
Even now after not using my Palm for 12 months or so, if I pick up a pen in my right hand and a pad in my left and start writing, it will come out in Graffiti.

Hi!
University exams are coming :)
I can try to add bookmarks patch, but it will take time. I hope to spend some time in next few days.