| <<<Back 1 day (to 2012/11/27) | 2012/11/28 |
Robin_Watts | mvrhel_laptop: Is the performance of the new version any better? | 00:23.57 |
mvrhel_laptop | Robin_Watts: downloading now to test | 01:19.07 |
| Robin_Watts: yes. it seems to be faster | 01:22.23 |
| speed now seems comparable to the build in viewer. built in viewer start up is slower and rescaling is a little odd so I think we are doing good in that department | 01:28.49 |
| Robin_Watts: what is the little chain link icon at the top | 01:30.10 |
| dinner time now. bbiaw | 01:30.15 |
Robin_Watts | paulgardiner, tor8: ping | 10:43.37 |
paulgardiner | pong | 10:43.43 |
Robin_Watts | mvrhel_laptop found a problem with the android app yesterday. | 10:43.55 |
| If he runs mupdf manually, and loads A.pdf (a 10 page file), then exits by hitting the home key (NOT the back button)... | 10:44.41 |
| so mupdf remains running in the background... | 10:44.49 |
| then he starts the file manager and opens a pdf from there (B.pdf, 2 pages)... | 10:45.16 |
| That starts a new mupdf instance, but it shows the first 2 pages from the old version (and eventually crashes) | 10:45.34 |
paulgardiner | Nasty. I guess that's because we have one static intance of the library. Probably we need to shutdown all other instances on start up | 10:47.13 |
| ... not that I know how to do that. | 10:47.21 |
Robin_Watts | paulgardiner: I am working on a solution here. | 10:47.32 |
| I've moved all the global variables from mupdf.c into a globals structure. | 10:47.47 |
paulgardiner | ah right. Magic | 10:47.48 |
Robin_Watts | We allocate the globals structure on startup. | 10:47.57 |
| And we write the pointer to the globals structure into private long globals; | 10:48.20 |
| so we need a bit of jni magic to get the globals structure back on each call. | 10:48.36 |
paulgardiner | So the MuPDFCore will need some sort of reference to its instance? | 10:48.54 |
Robin_Watts | thiz | 10:50.16 |
paulgardiner | Hmm, but all the native methods are declared static... I think I'm confused. Ignore me. | 10:52.05 |
Robin_Watts | All the native methods get passed a copy of their object, right? | 10:52.40 |
paulgardiner | I'm not sure. Typically in OO languages, a static method has no access to a particular object | 10:53.30 |
Robin_Watts | So the java side declarations might have to change? | 10:54.45 |
paulgardiner | But even if that's the case, it may just mean those methods have to be made non-static. | 10:55.28 |
Robin_Watts | I'm managing to write the globals back, and retrieving them successfully. | 10:55.40 |
| And I had this all working yesterday (as well as it ever was) with the globals in a static structure. | 10:56.00 |
| But it's crashing currently. I'll need to do some more debugging after my run. | 10:56.30 |
paulgardiner | Sounds fine then. | 10:56.31 |
| ah, not so fine. | 10:57.05 |
sebras | Robin_Watts: is this globals thing something recent? because I thought I had tested this... | 10:57.44 |
Robin_Watts | sebras: No, this would have been there since the year dot. | 11:03.06 |
paulgardiner | tor8, Robin_Watts: New commit on paulg/master | 11:55.12 |
tor8 | Robin_Watts: paulgardiner: hm, the mupdfcore ought to keep the "globals" as class members. I guess that's what robin's done. | 11:56.53 |
| or a complete redesign, the mupdf api changed a bit under your feet when you wrote MuPDFCore :) | 11:57.54 |
paulgardiner | Actually a lot of MuPDFCore predates me. | 12:01.36 |
| I think this poking a pointer into thiz that Robin_Watts has come up with should work, but it might require all the native methods to be class methods not static (if indeed that is allowed). | 12:02.33 |
| Or all the native methods could, other than open, could take the pointer as an argument, but that's uglier. | 12:03.29 |
tor8 | paulgardiner: I'm not fond of the MuPDFCore singleton stuff. I understand it was the easiest way to get something up and running for the original android demo... but I'd much rather see something based on mirroring the fz_document API (convenience wrapped for the device plugging, so renderPage and extractPageText, etc, instead of as in C having to plug and play with the various devices) | 12:20.48 |
paulgardiner | To be honest, this is my first use of JNI and I don't know that much about what the various options are. | 12:28.58 |
| I'm not quite understanding what you mean by "device plugging" and "plug and play" in the C. | 12:31.38 |
| One factor is that being an interface to the library isn't the only purpose of MuPDFCore. It is also where we control the threading atomicity of calls. If we modelled it's interface more on the library then we'd need another level at which to add synchronization... not that that is necessarily a bad thing. | 12:33.49 |
| Also there's an advantage in minimising the number of methods because each JNI method is some hassle in its own right. | 12:35.41 |
Robin_Watts | too bloody right. | 12:36.10 |
paulgardiner | That would be in reply to the "minimising the number of JNI methods", I'd imagine. :-) | 12:36.50 |
Robin_Watts | There may be something to be said for doing a java 'mirror' of the fz_document interface, but I suspect that most java programmers would rather have a 'give me a view with this document in it ,and you do all the panning/zooming/page turning/searching, k. thx, bai'. call. | 12:37.53 |
paulgardiner | I can also see it would be nice to have what would more or less be a java version of the library interface (especially if someone else had to write it. :-) ) | 12:38.03 |
| Yeah a java mirror. That's what I was trying to say. | 12:38.30 |
| Yes canonical PDFView would be attractive too. | 12:39.43 |
tor8 | an embeddable PDFView class would probably go a long way | 13:04.26 |
| I need to study android architecture more though, I'm still all fuzzy about the details around activities etc | 13:05.22 |
Robin_Watts | fuzzy is clearer than my understanding :) | 13:06.30 |
paulgardiner | Well they are sort of things that do stuff - that's my understanding. :-) | 13:11.51 |
Robin_Watts | Ok, so having the native methods as statics was indeed causing me problems. | 13:21.33 |
| Thanks for spotting that, or I'd have been confused all day long! | 13:21.51 |
| And it now all appears to work! Woo Hoo! | 13:22.36 |
| Let me tidy it up and then put it up for your comments. | 13:22.49 |
| OK. It's up for your comments. | 13:46.30 |
| tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=deac1b9b44977b9e8db758d01867bf8a3ca922ce <- That one went up yesterday. | 13:46.43 |
| The slowest file that I'd run across turned out to have a DeviceN image in it, and the conversion from DeviceN to rgb was hammering the hash table. | 13:47.46 |
| That commit adds a simple check to see if the pixel is the same as the last one before resorting to the hash, and helps a lot. | 13:48.13 |
tor8 | Robin_Watts: yes, I saw this morning. | 13:48.53 |
Robin_Watts | paulgardiner, tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=880c18202542b1edd234f3e172faae52727dbcd5 <- That's the android fix. | 13:48.55 |
tor8 | Robin_Watts: we could do a custom hash table for the memoization that justs nukes a slot if it collides and has a simpler hash function | 13:49.52 |
| (like use the last 4 bits of each color or something) | 13:50.34 |
Robin_Watts | tor8: We could, but with the simple check in place, hash drops right out of the profile. | 13:50.36 |
tor8 | right, well in that case :) | 13:50.52 |
Robin_Watts | fz_std_conv_pixmap is 25.5 % | 13:51.38 |
| fast_cmyk_to_rgb_ARM is 20% | 13:51.51 |
| scaling crap is 15% | 13:52.04 |
| everything else is sub 4%, and hash is down at 0.75 | 13:52.25 |
| I do wonder how much we'd save if we had the colour conversion functions all working from 0..255 -> 0.255 rather than from 0..1->0..1 | 13:55.52 |
| converting to float, doing the conversion, then converting back must hurt us. | 13:56.13 |
tor8 | Robin_Watts: work directly on unsigned chars? | 13:56.53 |
Robin_Watts | yeah. | 13:57.05 |
tor8 | Robin_Watts: it'd mean we have to convert floats to 0..255 and back in the non-pixmap uses | 13:57.28 |
| or change those to also use unsigned chars everywhere | 13:57.34 |
Robin_Watts | Or we have 2 copies of each routine. | 13:57.51 |
tor8 | nah. | 13:57.56 |
Robin_Watts | Another idea would be to have a way to lookup the function to use for a given conversion. | 13:58.20 |
tor8 | we've given up on ever having 16-bit render targets right? | 13:58.23 |
Robin_Watts | At the moment fz_convert_color goes through a nest of ifs to get to the code that deals with each conversion type. | 13:58.53 |
tor8 | that's the only case for keeping color values as floats as far as I can see | 13:58.53 |
Robin_Watts | Yeah, I think we've pretty much given up on 16bpc. | 13:59.09 |
tor8 | Robin_Watts: then let's make it all byte based everywhere | 13:59.23 |
| can go well with that fz_bbox wipeout I'm planning. introduce floats in one place, remove them from another :) | 13:59.43 |
paulgardiner | Robin_Watts: so you assign global_fid on every open call, but it wont harm other instances because it will always be the same value? | 14:00.17 |
tor8 | also, maybe reduce max colors to 4? | 14:00.28 |
Robin_Watts | paulgardiner: That's the hope. | 14:00.36 |
| Supposedly global_fid can't change for a given class. | 14:00.50 |
tor8 | not sure if we can get away with that, maybe with some trickery in the pdf interpreter | 14:00.59 |
paulgardiner | Sounds sensible | 14:01.04 |
tor8 | (to still support N colors for DeviceN in the interpreter) | 14:01.13 |
Robin_Watts | It would be a problem if 2 classes ever both called down to the same class. | 14:01.18 |
| tor8: I'm not sure max colors hurts us much. | 14:01.30 |
tor8 | Robin_Watts: only in the fz_shade lookup tables that are static (or did we rewrite those to be dynamically allocated?) | 14:01.52 |
| but no, it's fairly irrelevant | 14:02.03 |
paulgardiner | Robin_Watts: in openFile, I think you may be able to return without calling ReleaseStringUTFChars | 14:04.02 |
Robin_Watts | paulgardiner: That's unchanged. | 14:04.25 |
paulgardiner | Oh yeah, it is. :-) | 14:04.46 |
| Robin_Watts: yeah looks great. Maybe seems slightly odd that openFile returns the globals rather than poking them with SetLongField, but maybe that's just me. | 14:12.44 |
| openFile has to return something so why not the globals, I guess | 14:13.16 |
Robin_Watts | I had code there earlier for poking them in directly. | 14:26.59 |
| but I changed it to pass it back. | 14:27.10 |
| The jni stuff seems so clumsy that I prefer to minimise it. | 14:27.34 |
paulgardiner | Yeah. Makes sense | 14:35.57 |
Robin_Watts | So does that mean you're both happy with both those changes? (jni stuff and faster pixmap conversion) ? | 14:35.58 |
paulgardiner | I looked only at the jni stuff | 14:36.22 |
| but I was very happy | 14:36.34 |
Robin_Watts | If tor8 is happy then I'll push and build a new version for mvrhel. | 14:37.18 |
tor8 | Robin_Watts: I'm happy. | 14:37.39 |
Robin_Watts | Have either of you got any pending commits? | 14:37.52 |
paulgardiner | I have one. | 14:38.08 |
Robin_Watts | ooh, so you do. | 14:38.25 |
paulgardiner | and it involves mupdf.c :-( | 14:38.32 |
Robin_Watts | I'll merge it. | 14:39.05 |
paulgardiner | Thanks. Shouldn't be horrendous | 14:40.11 |
Robin_Watts | merged. building to test now. | 14:44.59 |
henrys | I was wondering when the scoundrels would switch to gmail addresses in bugzilla... | 15:00.35 |
kens | Second one we've seen | 15:06.10 |
[1]Roman | henrys: Remember my question about cutting rotating and "pasting" parts of PDF? I have asked it on StackOverflow as we discussed. One of the answers was to use CoherentPDF, which is a commecrial app, but does the job when combined with GS and PDFTK. The only problem, besides cost, is that something is wrong with the resulting PDF itself. | 15:33.02 |
| Only part of it gets printed. And I see no box limiting the printing. So basically, I am still stuck, it seems that there is no reliable method to achieve what I want. | 15:33.55 |
henrys | kens might be able to help if you refer him to the stackoverflow thread | 15:34.34 |
kens | I'm already on it | 15:34.50 |
[1]Roman | Thanks | 15:35.55 |
henrys | kens:I guess Coherent should be sent to scott for obligatory badgering also. | 15:39.20 |
kens | Maybe I missed them henrys | 15:39.41 |
henrys | [1]Roman just mentioned them above | 15:40.55 |
kens | Yes, I just read back a bit | 15:41.06 |
[1]Roman | The SO links if needed are: http://stackoverflow.com/questions/13586726/rotating-a-pdf-file-by-n-degrees-where-n-is-not-a-multiple-of-90/13601490#13601490 and http://stackoverflow.com/questions/13493559/ghostscript-postscript-pdf-cut-a-rectangle-from-a-ps-file-rotate-it-45-degree | 15:41.51 |
Robin_Watts | paulgardiner: Merged version pushed to my repo. | 15:46.11 |
paulgardiner | I'll have a look | 15:46.35 |
Robin_Watts | paulgardiner: When you're happy, I'll push it. | 15:53.51 |
paulgardiner | Robin_Watts: Looks fine to me | 15:55.09 |
Robin_Watts | paulgardiner, tor8: Can one of you nod sagely at http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=6c4834861eb9e685f74f45f0967744caabbd4c48 please? | 15:56.34 |
henrys | 5 minutes of the meeting | 15:56.43 |
tor8 | *nod* | 15:56.52 |
Robin_Watts | tor8: Thanks | 15:57.21 |
| Building a new apk for michael now. | 15:58.04 |
mvrhel_laptop | ok I am here | 15:59.01 |
henrys | so this meeting was to get mvrhel_laptop setup with the latest greatest and make sure he has nice demo pdfs. | 16:00.13 |
Robin_Watts | henrys: He has a build that's 24 hours out of date, at the moment, and has a selection of pdfs with forms in. | 16:01.05 |
mvrhel_laptop | the nexus 10 is going to be a nice device to demo. it is light weight and the size is perfect | 16:01.05 |
| I need to pull that one form off since it seems to have some issues | 16:01.33 |
Robin_Watts | He also found a problem with the android port of mupdf within seconds :) | 16:01.38 |
| mvrhel_laptop: Performance of the 2009_handbook should be a bit better now. | 16:01.53 |
mvrhel_laptop | Robin_Watts: oh ok great! | 16:02.01 |
henrys | huh wonder why I didn't see it on the nexus 7 | 16:02.11 |
Robin_Watts | It's still not the nippiest thing in the world, but... | 16:02.14 |
| henrys: none of us had seen it - it was to do with starting 2 copies of mupdf at once :) | 16:02.32 |
mvrhel_laptop | I was using it like a user would.... | 16:02.50 |
henrys | oh yes I read the commit message about that. | 16:02.52 |
Robin_Watts | mvrhel_laptop: Yeah. Damn users. :) | 16:03.15 |
henrys | if had a way to say this is the default pdf viewer for the device would that happen? | 16:04.06 |
| s/if/if we/ | 16:04.16 |
Robin_Watts | henrys: Yeah, the problem is that android can quite legally start 2 copies of an activity at the same time. | 16:04.46 |
mvrhel_laptop | oh can you change the default? the nexus just seems to ask me which one I want to use with each document | 16:04.47 |
Robin_Watts | mvrhel_laptop: When it asks you, does it not give you the option to say "always open like this in the future" ? | 16:05.16 |
mvrhel_laptop | let me check | 16:05.23 |
henrys | it should give you a "once" "always" choice, no? | 16:05.31 |
Robin_Watts | henrys: but the fix is in now, so it shouldn't be a problem. | 16:05.38 |
tor8 | you get an option to "remember this choice" for http links if you have multiple browsers | 16:05.40 |
Robin_Watts | I get the option on ES file browser on my phone with PDF files, so I'd imagine mvrhel_laptop should get it too. | 16:06.18 |
mvrhel_laptop | oh yes. there is a set as default app | 16:06.20 |
| but it still asks each time.... | 16:06.37 |
Robin_Watts | but I haven't set mine as default as I might want to compare and contrast. | 16:06.42 |
| oh, great. | 16:06.46 |
mvrhel_laptop | and I can't change the check box | 16:07.01 |
| that says Set as the default app | 16:07.11 |
| Is it worthwhile having any xps documents on there to show that we open those too? | 16:07.52 |
Robin_Watts | could be. | 16:08.09 |
tor8 | mvrhel_laptop: not at the moment, XPS causes the viewer to crash | 16:08.10 |
Robin_Watts | tor8: really? all the time? | 16:08.18 |
tor8 | Robin_Watts: yup. all the time. | 16:08.24 |
mvrhel_laptop | oops | 16:08.27 |
Robin_Watts | oh ass. I'm sure it's worked in the past. | 16:08.35 |
tor8 | Robin_Watts: and I can't get the damn debugger working to pinpoint it | 16:08.37 |
| it has worked in the past, but since nobody tests it regularly I'm sure it just bitrots :( | 16:09.24 |
mvrhel_laptop | If you are able to get it working, I think it would be good to have | 16:09.24 |
henrys | paulgardiner:is there something in the status report you want to discuss? | 16:09.31 |
Robin_Watts | Hmm. calc.pdf just died with the latest version :( | 16:09.36 |
henrys | how is saving coming along? | 16:09.38 |
mvrhel_laptop | I was going to ask about saving... | 16:10.08 |
paulgardiner | henrys: saving is done I believe. | 16:10.09 |
mvrhel_laptop | Also, what is the little chain icon in the upper right? | 16:10.41 |
Robin_Watts | yeah, calc.pdf dies as soon as I hit a button. | 16:10.42 |
| mvrhel_laptop: turns links on and off. | 16:10.56 |
paulgardiner | Robin_Watts: Eek! It does. | 16:11.02 |
mvrhel_laptop | ah ok | 16:11.02 |
| works fine on my version | 16:11.19 |
Robin_Watts | paulgardiner: Ah, good. I was worried I'd broken that in the merge. | 16:11.22 |
| mvrhel_laptop: Stick with your version and we'll find the problem. | 16:11.35 |
paulgardiner | Robin_Watts: I'm using the merged version | 16:11.38 |
mvrhel_laptop | ok | 16:11.39 |
Robin_Watts | paulgardiner: Ah, so that's still a possibility then. | 16:11.49 |
mvrhel_laptop | calc.pdf is a nice demo | 16:12.19 |
Robin_Watts | well, it was :) | 16:12.38 |
mvrhel_laptop | except we need an HP reverse polish version | 16:12.46 |
henrys | hmm I'd be surprised if we could really save on the droid. We can? I thought we'd run into permission problems. When you download an app from google play it asks you to okay to permission stuff, didn't think that would work for us. | 16:12.49 |
paulgardiner | Or it could be either of our commits individually. I didn't test calc.pdf since making it. I could now. | 16:12.53 |
Robin_Watts | paulgardiner: Go for it. | 16:13.33 |
mvrhel_laptop | It does ask me if I want to save but it doesnt really seem to save | 16:13.55 |
| oh I take that back | 16:14.47 |
| it does work | 16:14.49 |
henrys | wow great. | 16:15.00 |
| are you saving calc.pdf numbers. | 16:15.11 |
| ? | 16:15.12 |
mvrhel_laptop | no I was filling in a form | 16:15.23 |
| let me try the calc | 16:15.27 |
Robin_Watts | The apk manifest specifically says "we need access to the card for saving" (cos I added that for profiling) | 16:15.33 |
| but we also have permissions in there for the downloads directory, I believe. | 16:15.47 |
paulgardiner | Robin_Watts: Yeah, I thought it might have been that change of yours that permitted it | 16:16.00 |
henrys | ah I see. | 16:16.33 |
Robin_Watts | mvrhel_laptop: If you find any files that seem particularly slow, please tell me. | 16:17.19 |
mvrhel_laptop | when closing, calc asks if I want to save but it doesnt when reopened. but alumni-survey saved my data. so likely just something about the calc. form that really it doesnt have any storable data | 16:17.26 |
| Robin_Watts: ok. I will go through each of the forms today. I was just jumping around a bit yesterday | 16:17.51 |
| So, a couple questions | 16:18.09 |
Robin_Watts | paulgardiner: OK. If I revert to the commit before the merged one, calc works. | 16:18.16 |
paulgardiner | Robin_Watts: Yes and it is broken on paulg/master | 16:18.35 |
Robin_Watts | ah, fair enough then. | 16:18.46 |
| mvrhel_laptop: Go for it. | 16:18.54 |
henrys | mvrhel_laptop:check you can download a random pdf from the net and open it in mupdf. | 16:19.16 |
mvrhel_laptop | henrys: that was the first thing I did. That worked fine | 16:19.36 |
| Robin_Watts: so how hard is it to use a different Javascript engine | 16:19.55 |
henrys | oh okay great... somebody at the show might point you to a url they want to see output | 16:19.58 |
mvrhel_laptop | I see that mentioned in the notes | 16:20.24 |
Robin_Watts | mvrhel_laptop: Fairly easy, I believe. | 16:20.25 |
| There are no V8 specifics in the core. We have a thin shim layer that joins mupdf to v8, so people just replace that shim layer. | 16:20.47 |
mvrhel_laptop | ok that sounds great | 16:21.04 |
Robin_Watts | (paulgardiner: please correct me if I misrepresent stuff!) | 16:21.04 |
paulgardiner | Not so far/ | 16:21.33 |
mvrhel_laptop | are there any missing features or issues that I need to be aware of? | 16:22.05 |
Robin_Watts | With MuPDF in general, or with the android port in particular? | 16:22.28 |
mvrhel_laptop | well I was thinking in terms of the demo but since you opened it up.... | 16:22.55 |
Robin_Watts | In general: No color management. Android port: XPS doesn't work, and even if we fix that we don't support microsofts photo codec thing (the name of which escapes me) on android. | 16:24.14 |
paulgardiner | mvrhel_laptop: You cannot update choice fields at the moment... well you can, but it was that commit which broke calc.pdf | 16:24.19 |
henrys | That reminds me while demo'ing in chicago a customer of ours requested being able to annotate the pdf - like goodreader. I have been meaning to bring that up. | 16:24.26 |
Robin_Watts | No hardware acceleration yet either. | 16:24.45 |
| (at least, not in the rendering of the page - hardware acceleration is used to blit the page to the screen, I believe) | 16:25.02 |
| henrys: We have a customer of mupdf that is using mupdf + iText to do that, I think. | 16:25.20 |
| but yes, it would be nicer if we did it all. | 16:25.51 |
henrys | I told him the API was there and an OEM could easily implement that but I think our demo should have it. | 16:26.14 |
Robin_Watts | We have no API for adding annotations. | 16:26.50 |
| They would have to resort to direct manipulation of pdf objects. | 16:27.07 |
mvrhel_laptop | henrys: I do have another demo on windoze of an app that uses mupdf and allows annotations from one of our customers | 16:27.13 |
henrys | oh see that I'm getting more like Miles in my old age. | 16:27.16 |
| sell it before we have it. | 16:27.53 |
| I'm curious if Preview and other apps are using the XML stuff to implement that. | 16:28.16 |
Robin_Watts | has flashbacks... "I've sold video editing!" "but we only do video playback" "well, it's not much harder is it?" | 16:28.18 |
mvrhel_laptop | ha. that is funny | 16:28.30 |
| sounds like something I would say and do | 16:28.41 |
| I wonder if I should go ahead and see if I can actually build the apk myself | 16:29.30 |
| is it easier to get set up to do it on linux or windoze? | 16:29.46 |
| to do it on windoze I need wincyg? | 16:30.20 |
Robin_Watts | Yes. | 16:30.26 |
mvrhel_laptop | ok cross that off the list... | 16:30.38 |
| what about in linux | 16:30.50 |
| is it pretty straight forward? | 16:30.57 |
Robin_Watts | I believe so. | 16:31.02 |
mvrhel_laptop | if I follow a readme someplace | 16:31.05 |
Robin_Watts | I think I had it set up on the mac ages ago. | 16:31.09 |
| mupdf.git/android/ReadMe.txt | 16:31.17 |
mvrhel_laptop | ok | 16:31.20 |
henrys | It would be good to have XPS working for the demo, but we do a bisect? | 16:31.42 |
mvrhel_laptop | I agree. Having xps would be nice | 16:31.53 |
henrys | s/but/can | 16:31.55 |
Robin_Watts | henrys: I'll try and find why XPS doesn't work, as soon as we get calc.pdf working again. | 16:32.10 |
mvrhel_laptop | any features we can show that are above and beyond the native viewer's capabilities would be good. obviously form filling is huge | 16:32.37 |
tor8 | mvrhel_laptop: http://ghostscript.com/~tor/stuff/android-howto.html is a short version of the setup instructions | 16:32.50 |
mvrhel_laptop | tor8: great. thanks | 16:33.00 |
paulgardiner | Robin_Watts: I've fixed the calc.pdf crash. It's pushed. | 16:33.05 |
Robin_Watts | paulgardiner: Oh, excellent. | 16:33.23 |
mvrhel_laptop | great. another 10 minutes xps will be fixed too | 16:33.24 |
| at this rate | 16:33.29 |
tor8 | mvrhel_laptop: I use macosx, and I think the setup for linux is equally easy. just go for the "use my own ide, screw that eclipse crap" option when downloading | 16:33.35 |
mvrhel_laptop | ok | 16:33.46 |
| I will try this today | 16:34.02 |
tor8 | mvrhel_laptop: then it's just two tar balls you need to unpack, a few paths to set, and a quick trip through the "android" tool to download some additional stuff you need | 16:34.20 |
Robin_Watts | paulgardiner: pushed. | 16:37.25 |
| mvrhel_laptop: Oh, for sake of your sanity, download r8b, not r8c! | 16:37.42 |
| r8c has all the dependency checking broken, so every build builds everything... | 16:38.03 |
mvrhel_laptop | ah. ok. I saw you guys talking about that the other day | 16:38.20 |
paulgardiner | Great ta. Might be worth updating Michael with a new apk, because that now allows choice fields to be altered | 16:38.22 |
henrys | so should a bug be created for adding the annotation feature can that be added to paul's list? | 16:38.44 |
| I guess paulgardiner would do the ui and tor8 the plumbing | 16:39.38 |
paulgardiner | Fine with me, although probably a big chunk of work, so not necessarily quick | 16:39.44 |
tor8 | henrys: adding annotations is a big project. | 16:39.51 |
henrys | tor8:with our current direction of focusing on tablets and mobile users I don't see how you can skip over something like that. | 16:42.13 |
Robin_Watts | henrys: You want to be able to add text annotations? | 16:42.32 |
| OR graphics annotations? | 16:42.39 |
| Even with text, how do you choose the font? The font size? the wrapping, etc... | 16:42.54 |
henrys | what the customer in chicago showed me was graphics - highliting, ovals that kind of thing. | 16:43.20 |
| but we should probably do as well as goodread right? | 16:43.44 |
Robin_Watts | Right, so the UI for that is significant. | 16:43.53 |
henrys | I'm not saying we need it for beta | 16:46.07 |
| tor8:does sumatra support it? | 16:47.48 |
mvrhel_laptop | I can show our one customers app in windows for it | 16:47.55 |
| I thought I had it installed but I can't find it now | 16:48.17 |
tor8 | henrys: no. sumatra is strictly read only. | 16:48.20 |
henrys | tor8:certainly preview on mac os x does a nice job of supporting it, I haven't used other apps. | 16:49.06 |
mvrhel_laptop | Ch3rrryC0ke was the one | 16:50.29 |
tor8 | henrys: oh god that made me so angry the other day. it clobbers the damn file without asking for confirmation! | 16:50.35 |
mvrhel_laptop | http://apps.microsoft.com/webpdp/en-US/app/pdf-touch/c9d9c388-68ca-499b-ae0f-d829f19ad613 | 16:50.39 |
| this uses mupdf | 16:50.50 |
Robin_Watts | tor8: xps pages are numbered from 1, right ? | 16:50.56 |
tor8 | Robin_Watts: huh? | 16:51.13 |
| Robin_Watts: they should be using the same numbering as pdf, if not something's broken. | 16:51.26 |
Robin_Watts | I get: | 16:51.42 |
| I/libmupdf(15521): Drop page 0 | 16:52.09 |
| E/libmupdf(15521): Goto page 0... | 16:52.11 |
| I/libmupdf(15521): Load page 0 | 16:52.13 |
| E/libmupdf(15521): error: expected FixedPage element | 16:52.14 |
| E/libmupdf(15521): cannot make displaylist from page 0 | 16:52.16 |
henrys | mvrhel_laptop:right that just seems like a crucial feature for pdf's on a tablet. I don't see how we can ignore it. | 16:52.21 |
Robin_Watts | so the page load is failing. Is that what you see ? | 16:52.28 |
mvrhel_laptop | henrys: I agree | 16:53.00 |
kens | henrys, [1]Roman are you sure COherentPDF uses Ghostscript ? I can't see any evidence of it so far | 16:53.19 |
tor8 | Robin_Watts: expected fixedpage element may be a new regression, with the xml parser. I thought I fixed it. | 16:53.22 |
| Robin_Watts: but that just makes empty pages. I get segfaults. | 16:53.31 |
Robin_Watts | I absolutely agree that having an API in there to allow annotations to be added is a missing feature. | 16:53.35 |
tor8 | ECMA-388.xps | 16:53.38 |
Robin_Watts | I don't get seg faults at the moment. | 16:53.54 |
| I'm using mb01.xps | 16:54.04 |
tor8 | let me try that one | 16:54.15 |
henrys | paulgardiner:maybe you can add the annotations feature to your list | 16:55.44 |
paulgardiner | longterm list? Not for Feb presumably? | 16:57.00 |
henrys | paulgardiner:yes | 16:57.15 |
paulgardiner | Phew! Yeah great. | 16:57.28 |
henrys | so I guess we really don't need to continue the meeting - the main thing is mvrhel_laptop keep playing with release until he feels good about the demo and report problems as he goes along. | 16:59.02 |
mvrhel_laptop | sounds like a plan. I am going to see if I can build also. Robin_Watts let me know when I should grab any updates | 16:59.54 |
paulgardiner | I've run into one stupid problem: since last time I looked at submission, I've updated my server and lost fdfphp. I'm struggling to recall how I installed it, plus the server is now 64bit which may cause problems | 16:59.59 |
Robin_Watts | mvrhel_laptop: I can do a new build at any point, but I was hoping to get you one with XPS fixed. | 17:00.19 |
paulgardiner | Still, that's something for me to hack at here | 17:00.27 |
mvrhel_laptop | Robin_Watts: please go ahead and wait until xps | 17:00.35 |
| I will fool around with the build on linux here for a bit | 17:00.48 |
paulgardiner | Robin_Watts: one possibility with XPS is that I've somewhere called fz_interact and not checked the result is non-NULL before using it. | 17:01.23 |
mvrhel_laptop | I will also go ahead and grab some xps files for testing... | 17:02.12 |
kens | Well, I have a copy of WIndows 8 installed | 17:04.57 |
tor8 | Robin_Watts: XPS expecting FixedPage element commit on tor/master | 17:06.21 |
Robin_Watts | I get SEGVs with ECMS-388.pdf too | 17:06.49 |
| tor8: both commits look fine. | 17:07.54 |
tor8 | Robin_Watts: thanks. | 17:08.27 |
paulgardiner | Robin_Watts: I do seem to be passing the result of fz_interact to fz_update_page and fz_poll_changed_annot without testing for NULL in several places within mupdf.c | 17:08.33 |
Robin_Watts | pulling/pushing now. | 17:08.42 |
tor8 | jni/mupdf.c: In function 'get_globals': | 17:09.04 |
| jni/mupdf.c:225: warning: cast to pointer from integer of different size | 17:09.04 |
| jni/mupdf.c: In function 'Java_com_artifex_mupdf_MuPDFCore_openFile': | 17:09.05 |
| jni/mupdf.c:297: warning: cast from pointer to integer of different size | 17:09.06 |
Robin_Watts | tor8: Yes. java longs are 64bit. | 17:09.26 |
paulgardiner | Sorry, I have to leave for a bit, but I'll drop in and out as and when I can | 17:09.28 |
tor8 | Robin_Watts: right. just checking. | 17:09.37 |
Robin_Watts | and evidently android is 32bit. | 17:09.39 |
| paulgardiner: OK. I'll try to add checks for that. | 17:09.47 |
mvrhel_laptop | this is too funny | 17:13.27 |
| http://www.nytimes.com/2012/11/28/world/asia/chinese-news-site-cites-onion-piece-on-kim-jong-un.html | 17:13.28 |
kens | Was on the radio this morning :-) | 17:17.44 |
sebras | mvrhel_laptop: ehm... that WinRT app, where is the link for the source to that one? | 17:18.44 |
| mvrhel_laptop: and the mention of mupdf. | 17:18.51 |
| mvrhel_laptop: and the license. | 17:18.59 |
mvrhel_laptop | sebras: I think this person is a customer | 17:19.04 |
Robin_Watts | sebras: He's a paying customer, hence no source. | 17:19.16 |
sebras | mvrhel_laptop: aha! then it's completly different. :) | 17:19.23 |
henrys | marcosw:ping | 17:20.08 |
sebras | right... now I remember, microsoft doesn't allow GPL in its store... | 17:20.47 |
| sorry for the noise. :) | 17:21.08 |
kens | discovers how to get a command shell on Windows 8 :-) | 17:21.09 |
Robin_Watts | ok. I have xps working. | 17:24.18 |
| paulgardiner: was right. | 17:24.22 |
kens | bye everyone | 17:26.58 |
Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=90269f9a74af33f980f8ff055145a320e92608e9 | 17:29.12 |
paulgardiner | Robin_Watts: Yeah that looks fine to me. | 17:49.30 |
Robin_Watts | mvrhel_laptop: http://ghostscript.com/~robin/MuPDF-debug.apk | 17:49.40 |
| paulgardiner: Thanks. | 17:49.42 |
| mvrhel_laptop: That should fix everything we know about. | 17:51.03 |
mvrhel_laptop | Robin_Watts: great! let me try it out | 17:53.31 |
Robin_Watts | Stupid windows has lost my optical drives. gotta reboot. brb. | 17:54.55 |
mvrhel_laptop | things look much better Robin_Watts | 18:08.19 |
Robin_Watts | fab. | 18:08.51 |
| mvrhel_laptop: Oh. MuPDF supports transitions. The Android app doesn't. | 18:25.13 |
mvrhel_laptop | what do you mean transitions? | 18:25.32 |
Robin_Watts | So if people want to fade from page to page etc. | 18:25.35 |
| Using PDF as Powerpoint etc. | 18:25.48 |
mvrhel_laptop | ah ok | 18:26.10 |
| how do I set that option? | 18:26.47 |
Robin_Watts | On the desktop? | 18:26.57 |
mvrhel_laptop | no the app? | 18:27.03 |
Robin_Watts | You can't. | 18:27.15 |
mvrhel_laptop | oh sorry | 18:27.19 |
Robin_Watts | That's what I was saying. | 18:27.19 |
mvrhel_laptop | I am a little slow | 18:27.38 |
Robin_Watts | On the desktop, hit 'p' to go into presentation mode, then any page turns follows a random transition. | 18:27.46 |
mvrhel_laptop | ok | 18:27.55 |
Robin_Watts | And it may even auto progress from page to page every 10 seconds. | 18:27.57 |
mvrhel_laptop | Is this on the standard windows viewer in mupdf? | 18:28.15 |
Robin_Watts | yes. | 18:28.25 |
mvrhel_laptop | so it would be nice to have mupdf open the *.xps file type when selected in the file explorer | 18:32.17 |
Robin_Watts | mvrhel_laptop: It would, but when I tried it before, I could only make the activity respond to a single filetype. | 18:32.50 |
mvrhel_laptop | ok. | 18:33.20 |
Robin_Watts | In fact, it is set up to respond to *.xps | 18:33.36 |
| and application/vnd.ms-xpsdocument | 18:33.53 |
| mvrhel_laptop: It might be worth install ASTRO to see if that one works better? | 18:34.45 |
mvrhel_laptop | Robin_Watts: ok I will check that out | 18:35.51 |
| I need to head out for a bit. need to pick up my son at school early today | 18:36.16 |
Robin_Watts | ok. | 18:36.45 |
tor8 | Robin_Watts: yay, XPS works again! :) | 18:39.16 |
Robin_Watts | tor8: some tiny commits for review. | 18:45.45 |
| http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=9046411bcd6ec83002e5c23f3665b48a80973848 | 18:45.57 |
| http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=4344ce6ba5037eb4d1ac22bd7ebf87707864fb25 | 18:46.05 |
| http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=ed4c1a10463b1a6a6777b5685d4bab4a0f5d5068 | 18:46.14 |
tor8 | Robin_Watts: *nod* | 19:06.14 |
| x 3 | 19:06.17 |
Robin_Watts | Thanks. | 19:08.16 |
wart____ | hi folks. i noticed there is no comment on this: http://bugs.ghostscript.com/show_bug.cgi?id=693270 | 23:09.52 |
| i'm just about to go through the headache of installing kde just to get okular just to get the ability to annotate/highlight on my pdfs. any chance there's a preliminary version of this in mupdf? | 23:10.34 |
| absent that, what's the priority on it? | 23:10.52 |
| Forward 1 day (to 2012/11/29)>>> | |