Android viewer #179

Open
jflesch opened this Issue May 31, 2013 · 14 comments

Projects

None yet

4 participants

@jflesch
Owner
jflesch commented May 31, 2013 edited

I've won an Android tablet during a programming competition. Now I need something useful to do with it. I guess porting Paperwork is the logical choice.

  1. Gtk is not available on Android --> a specific frontend will have to be made
  2. Scanners and printers are not (yet) available on Android. So this will just be a viewer

The hard part: Getting the dependency to work on Android. Afaik, most Gobject introspection won't be avaible ... this won't be easy.

Update (2016/12/06): Would also be strongly wishable: encryption

@jflesch jflesch was assigned May 31, 2013
@jflesch
Owner
jflesch commented May 31, 2013

I have a feeling it would be easier to actually run Debian on my tablet ... :)

@Nodd
Nodd commented Jun 25, 2013

You could use the camera instead of a scanner. The quality will be worse, but it may not be a problem.
Kivy looks promising for a python UI, and is multiplateform.

@jflesch
Owner
jflesch commented Jun 25, 2013

Let's start with a viewer, and let's see later to add photo+OCR support.

@jflesch
Owner
jflesch commented Jul 2, 2013

Dependencies:

  • PIL/Pillow: There is already a recipe to compile PIL included in python-for-android
  • Whoosh : Whoosh is pure python. It shouldn't be much of a problem
  • Nltk : Nltk seems to be also pure python.
  • Libpoppler is the hardest : It is a C++ library. Currently it is accessed through Gobject introspection. However, GObject introspection depends on the Glib.

All the other dependencies can be made optional.

In the end, using Libpoppler on Android will probably end up being a big mess. It would probably be easier to make a recipe for http://www.mupdf.com/ + use ctypes

@bignaux
Contributor
bignaux commented Dec 7, 2013
  1. Gtk is not available on Android --> a specific frontend will have to be made
    we should not use Gobject/glib in backend, and use http://effbot.org/imagingbook/format-pdf.htm , anyway, we could have many format backend with smart depedancies.
  2. Scanners and printers are not (yet) available on Android. So this will just be a viewer
    => RESTful API #265 and js UI would solve both : you could have paperwork backend running on a host and connect it through webbrowser.
@jflesch
Owner
jflesch commented Dec 8, 2013

you could have paperwork backend running on a host and connect it through webbrowser.

Definitively not what I had in mind or even what I want. What I want here is a Paperwork instance running on Android, with all the data stored on the devices itself.

@Nodd
Nodd commented Dec 9, 2013

Some papers are received by mail, so paperwork on android should be able to import existing documents even without scanners or printers.

@jflesch
Owner
jflesch commented Dec 9, 2013

This ticket is about a viewer only. I'll see later to extend its functionalities.

@jflesch jflesch added this to the 0.3-unstable milestone May 19, 2014
@jflesch
Owner
jflesch commented Feb 4, 2015

Depends on #328

@jflesch
Owner
jflesch commented Feb 8, 2015

Kschwank has started working on one (Java): https://github.com/kschwank/paperwork-viewer

@jflesch jflesch modified the milestone: 0.4-unstable, 0.3-unstable Oct 9, 2015
@tYYGH
tYYGH commented Jan 21, 2016

In case someone is interested, I wrote a Web viewer, and I checked that it renders well on my Android phone:
http://yalis.fr/cms/index.php/post/2016/01/21/Command-line-and-Web-Interface-for-Paperwork
Cheers,

@jflesch jflesch modified the milestone: 0.5.0, 0.4.0 Feb 19, 2016
@jflesch jflesch modified the milestone: 2.0, 1.1.0 Dec 6, 2016
@jflesch
Owner
jflesch commented Dec 6, 2016 edited

@kschwank started to work on an Android viewer a while ago. However, I'm not sure if he still intend to work on it.

Also, it's pure Java and therefore cannot use paperwork-backend. If the backend part evolves, it would have to keep up.

I would really prefer an implementation made in Python as muh as possible (see Pyjinius and friends)

@jflesch
Owner
jflesch commented Dec 6, 2016

Support for encryption would also be a really good thing.
Android can encrypt all the data of the users, but it makes the devices really slow. Just having Paperwork's documents encrypted would be safe enough and good to have.

@jflesch jflesch removed their assignment Feb 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment