20:34:30 <popey> #startmeeting Ubuntu Documentation Viewer App meeting
20:34:30 <meetingology> Meeting started Thu Mar 21 20:34:30 2013 UTC.  The chair is popey. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
20:34:30 <meetingology> 
20:34:30 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
20:34:59 <Robin_Watts> Documentation viewer? I had understood that this was a Document viewer meeting.
20:35:13 <mhall119> Robin_Watts: yes, document viewer
20:35:21 <Robin_Watts> ok, sorry.
20:35:26 <popey> I am having a bad day, sorry ㋛
20:35:40 <Robin_Watts> No worries ;-p
20:35:59 <mhall119> so the blueprint for this project is a little bit sparse: https://blueprints.launchpad.net/ubuntu-docviewer-app/+spec/initial-docviewer-development
20:36:02 <mhall119> only 4 work items
20:36:08 <mhall119> and I'm sure there's more work to be done than that
20:36:17 <popey> Agreed.
20:36:57 <mhall119> do we need to add more, or breakup the ones we have into smaller tasks?
20:37:00 <mhall119> or both?
20:37:24 <popey> i think both
20:37:40 <popey> the first UI layout, could probably do with being split for different file types at least
20:38:02 <popey> we also need some backend to open/render these common file types
20:38:13 <mhall119> how are we planning on loading files, will they be passed into the app when it's launched?  Will it need to browse for them?
20:39:04 <popey> the former AIUI
20:39:12 <popey> we have a file manager app
20:39:17 <Robin_Watts> popey: Myself and other developers here were interested in suggesting that MuPDF could be useful as a technology for opening/rendering PDF files.
20:39:22 <tkamppeter> And we also need to take care that the document viewer and the printing stack use the same rendering backends, especially for the complex PDF format.
20:39:55 <popey> what does MuPDF give us (in a nutshell) ?
20:40:14 <Robin_Watts> Due to the design of MuPDF it wouldn't be much work to have it handle bmp's, jpg's, pngs etc. It already does XPS and CBZ.
20:40:30 <Robin_Watts> OK, here goes my standard core spiel...
20:40:50 <Robin_Watts> MuPDF is a set of libraries for opening/rendering/interacting with PDF/XPS/other files.
20:41:40 <Robin_Watts> We also provide various tools etc build as thin layers on top of these libraries, including viewers for many different platforms (android, ios, windows, linux).
20:41:59 <Robin_Watts> Other people have ported it to many other systems too (qnx, webos, even I believe amigaos etc).
20:42:33 <Robin_Watts> It's designed to be small and fast and portable, but it's still pretty complete.
20:43:10 <popey> what license is it under?
20:43:26 <Robin_Watts> The basic design of the system is that we have routines for handling PDF files (or XPS files), and these render by calling a defined interface. this interface then produces bitmaps.
20:43:46 <popey> and is it already packaged up and builds for armhf on debian/ubuntu?
20:43:52 <Robin_Watts> it would be dead simple to add new readers that took a JPEG or PNG file and called the same interface.
20:44:07 <Robin_Watts> It's dual licensed under the GNU AGPL and the Artifex commercial license.
20:44:13 <Robin_Watts> (same licenses as ghostscript).
20:44:35 <Robin_Watts> Yes, I believe it's packaged for ubuntu (though we don't package it ourselves)
20:44:52 <popey> alan@deep-thought:~$ apt-cache search mupdf
20:44:52 <popey> libmupdf-dev - development files for the MuPDF viewer
20:44:52 <popey> mupdf - lightweight PDF viewer
20:44:53 <popey> mupdf-tools - commmand line tools for the MuPDF viewer
20:44:55 <popey> looks good
20:45:01 <Robin_Watts> Building for ARM platforms shouldn't be a problem (in fact it has ARM optimisations in there).
20:45:18 <tkamppeter> Yes, it is packaged for Ubuntu. Installing ...
20:45:24 <Robin_Watts> The viewer you get on linux is a dead simple X11 one. IF you want to see what the lib is capable of, you're better off using the Android build.
20:45:52 <Robin_Watts> It's available from Google Play (as MuPDF) or I can give you a link to a newer development version that supports reflow.
20:46:04 <ray_work> do we want to mention form filling ? (I just did)
20:46:18 <Robin_Watts> The android version has the hooks in for form filling, and the javascript integration that requires.
20:46:31 <Robin_Watts> the linux version doesn't currently.
20:46:56 <ray_work> it uses (currently) the v8 JS
20:47:28 <tkamppeter> ray_work, and I tested on Android, it actually saves the filled form, which evince under Ubuntu does not.
20:48:00 <mhall119> Robin_Watts: so currently the desktop apps all use poppler, I believe
20:48:19 <Robin_Watts> The choice of javascript engine is not tightly constrained - currently we have a veneer that allows us to call into V8, but it's deliberately done so that other engines can be used.
20:48:23 <mhall119> having two separate PDF libraries might make for inconsistencies
20:48:31 <Robin_Watts> mhall119: So they can adopt mupdf too :)
20:48:53 <mhall119> Robin_Watts: we don't control them, you'd have to convince upstream to switch
20:48:54 <tkamppeter> Yes, on the Ubuntu desktop there are both Poppler and GS as PDF renderers, Poppler principally for the screen, GS principally for printing.
20:49:03 <Robin_Watts> I believe the desktop is in the position of using poppler for the default PDF viewer, but it uses gs for printing
20:49:14 <Robin_Watts> (tkamppeter types faster than me :) )
20:49:47 <ray_work> I doubt Poppler is tested as thoroughly (Artifex uses the Quality Logic FTS and ATS suites as well as LOTS of files from years of Ghostscript bug fixing)
20:50:09 <tkamppeter> I would suggest MuPDF as the only one on Mobile. I will open some GSoC projects, for example to make cups-filters support MuPDF.
20:50:29 <mhall119> is MuPDF used by any of the default Ubuntu apps currently?
20:50:40 <Robin_Watts> mhall119: Well, I spoke to people on #ubuntu-desktop yesterday, and they suggested that we might get into this "you need to talk to them" circle.
20:50:53 <Robin_Watts> Not as far as I know.
20:51:11 <mhall119> heh
20:51:13 <tkamppeter> mhall119, not to my knowledge, but I know Artifex' great testing infrastructure.
20:51:20 <mhall119> that's what happens when you have a lot of stakeholders
20:52:13 <Robin_Watts> Using MuPDF would give you the option of handling XPS files as well as PDF files.
20:52:16 <mhall119> Robin_Watts: did anybody in -desktop give you their position on using MuPDF for a default app?
20:52:36 <Robin_Watts> I believe the desktop people currently use evince.
20:52:45 <mhall119> which uses poppler, IIRC
20:52:52 <Robin_Watts> evince calls out to various different backends, one of which is poppler.
20:53:02 <mhall119> but other apps too, like LibreOffice, have PDF support
20:53:11 <Robin_Watts> In theory, someone could hook MuPDF in there instead.
20:53:50 <ray_work> I wonder if the desktop side has any interest in handling XPS
20:54:01 <Robin_Watts> mhall119: I wasn't trying to persuade them to change - and even if I had been I wasn't sure I was actually talking to the right people.
20:54:08 <mhall119> I'm not against using MuPDF, I just want to make sure we have agreement from these other teams so we don't get half-way through building the doc viewer and then be told to change
20:55:13 <tkamppeter> Yesterday they told on #ubuntu-desktop that Touch will have a completely different docviewer, as desktop uses GTK and Touch uses Qt/QML.
20:55:15 <mhall119> popey: one of us should get an action item to do that, talk to desktop and security teams about what impact this might have on the distro as a whole
20:55:18 <Robin_Watts> mhall119: The impression I got was that they thought that you were building a new doc viewer from scratch, and therefore were free to choose, and that they'd be interested to see what you came up with - but as I say, there is no guarantee that that was authorative.
20:55:28 <popey> mhall119: I'll do that
20:55:33 <mhall119> tkamppeter: for now they will, in the future it would make sense for us to have only one
20:55:45 <popey> #action discuss mupdf with desktop and security teams
20:55:45 * meetingology discuss mupdf with desktop and security teams
20:55:55 <popey> #action popey discuss mupdf with desktop and security teams
20:55:55 * meetingology popey discuss mupdf with desktop and security teams
20:55:59 <popey> I'm failing with the bot today
20:56:22 <mhall119> as long as nobody there has a problem with it, and as long as the ubuntu-docviewer-devs like the library and it's API, I'm happy with it being used
20:56:29 <Robin_Watts> mhall119: I completely understand your desire to standardise.
20:56:34 <mhall119> popey: not too late to #startmeeting
20:56:45 <popey> :p
20:56:52 <mhall119> well, it almost is
20:56:58 <mhall119> but not quite
20:57:09 <mhall119> oh wiat, it was working
20:57:11 <mhall119> nvm
20:57:14 <popey> ☺
20:57:16 * mhall119 goes back to his corner
20:57:25 <popey> we're low on time...
20:57:29 <popey> anything else we need to bring up?
20:57:33 <mhall119> do we have a list of file types to support by alpha-1?
20:57:38 <tkamppeter> Switching printing is ratther easy as the printing stack uses simple filters and one can easily make a wrapper for MuPDF.
20:58:14 <mhall119> tkamppeter: coding is usually easy, finding somebody to write the code usually isn't :)
20:58:42 <tkamppeter> mhall119, that's true, it made projects like the Common Printing Dialog fail.
20:59:14 <Robin_Watts> mhall119: As MuPDF is a dual licensed free/commercial thing, the core library has full time developers on it.
21:00:04 <tkamppeter> mhall119, MuPDF is as well supported upstream as Ghostscript, but much more lightweight.
21:00:05 <mhall119> Robin_Watts: I meant for doing these wrappers that tkamppeter was talking about
21:00:25 <Robin_Watts> mhall119: right.
21:00:38 <mhall119> ok, I think time is up, and I don't have anything more to add
21:01:00 <popey> ok. thanks for the input guys. I'll get back to you when I have some feedback from desktop / security
21:01:14 <popey> #endmeeting