| | <<<Back 1 day (to 2015/01/05) | 20150106 |
| rayjj | guess I'm a bit early for the meeting ;-) | 07:15.39 |
| Robin_Watts | http://www.spacex.com/webcast/ | 11:11.06 |
| | They plan to land the boosters on a platform in the sea after use so they can be reused. | 11:11.34 |
| | 11:20 take off. | 11:12.32 |
| paulgardiner | Houstan we have a problem | 11:20.34 |
| sebras | paulgardiner: hold, hold, hold. come back maybe on friday. | 11:38.12 |
| henrys | wow the /tmp file bug resolved fixed, good start to the new year, rayjj | 15:30.50 |
| | so we have a light staff today so a short meeting. | 15:32.13 |
| | please welcome fredross-perry to the regular part time staff! | 15:33.02 |
| Robin_Watts | fredross-perry: welcome! | 15:33.10 |
| paulgardiner | hi fredross-perry | 15:33.28 |
| Robin_Watts | Please proceed to the manacle fitting station... | 15:33.28 |
| fredross-perry | :-) | 15:33.35 |
| marcosw | hello fredross-perry | 15:34.00 |
| fredross-perry | I enjoy a good manacle-ing | 15:34.07 |
| jogux | welcome fredross-perry :) | 15:34.24 |
| pedro_mac | hi fredross-perry | 15:34.40 |
| mvrhel_ | oh wow. hi fredross-perry | 15:34.44 |
| marcosw | what you do in your spare time is none of our concern | 15:34.50 |
| fredross-perry | hi mvrhel | 15:35.58 |
| mvrhel_ | fredross-perry: so I still owe you a screen shot of my print dialog | 15:35.59 |
| henrys | to refresh our memories fredross-perry torture uh project started to take form here: http://ghostscript.com/irclogs/2014/12/19.html about halfway down the log. | 15:36.09 |
| fredross-perry | yes, please | 15:36.22 |
| mvrhel_ | I will get that you. I have been busy working on getting xpswrite working better for gsview printing on windows. just about done with that | 15:36.41 |
| henrys | mvrhel_: I have clipping fixes for xpswrite but I thought I'd wait for your checkin and not create a conflict to be merged. | 15:37.26 |
| mvrhel_ | henrys: ok great. I have a pretty large commit to do . I am hoping to have it in my tomorrow. I may have you and rayjj review it. | 15:38.19 |
| henrys | marcosw: I wanted to wait for ken before answering the pcl->pdf bug. I know the pcl fix will stand in any release but not sure about the required pdfwrite changes. | 15:39.01 |
| mvrhel_ | It has some changes in clist stuff due to some shared code that the two have (color monitoring in images in the clist and conversion to tiff image in xps) | 15:39.12 |
| marcosw | henrys: my preliminary look into it suggests it's not going to be easy, but I was going to ask ken what he thought. | 15:39.44 |
| Robin_Watts | henrys: I can see various things in that discussion. 1) Turning MuPDF into a 'framework' that ios users can easily drop into their own apps (I hope 'framework' is the right word). | 15:40.07 |
| henrys | rayjj: you had problems with xpwrite on the macpro? Can you tell me which files and marcos or I will havea look. | 15:40.23 |
| fredross-perry | So I looked at that discussion, thanks. | 15:40.26 |
| | yes, there are a few, perhaps separate, issues. | 15:40.39 |
| Robin_Watts | Essentially we want to make it easy for ios app writers to take our app and to roll it into their own. | 15:40.47 |
| rayjj | mvrhel_: I fixed the irritating xpswrite behaviour on Windoze (that left the temp files laying around). I thought that would be important before releasing gsview more widely | 15:40.57 |
| Robin_Watts | 2) Maybe doing the same thing for macosx too? Not sure that there is a huge market there. | 15:41.08 |
| fredross-perry | I think devs are going to want a component that does display, panning and zooming, and not much else. That can come with a sample app with UI that they can modify/use, or toss. | 15:41.39 |
| mvrhel_ | rayjj: oh ok. yes I did see it was doing that. | 15:41.49 |
| Robin_Watts | 3) Finishing the JNI work to expose (something very similar to) the C API into java, and updating our android app to call that rather than the current 'custom' JNI code. | 15:42.30 |
| fredross-perry | (2) not sure about that. (3) yes. | 15:43.07 |
| rayjj | henrys: not xpswrite, but gxps. I'll send the list via email of the "ERROR" pages/files | 15:43.10 |
| Robin_Watts | fredross-perry: When I say UI, I broadly mean the display, panning, zooming behaviour. | 15:43.17 |
| | app writers will probably want a 'thing' they can stick into their code to display documents/navigate through them etc. | 15:43.51 |
| fredross-perry | robin: yes | 15:44.13 |
| Robin_Watts | To be able to include/exclude things like searching/annotation/printing etc is extra credit :) | 15:44.24 |
| henrys | other than fredross-perry project I didn't have other topics for the meeting. Anybody have anything before we focus on fredross-perry's stuff? | 15:45.04 |
| Robin_Watts | App authors basically want stuff to be lego. Shiny plastic blocks they can clip together without thinking about it too much. | 15:45.13 |
| fredross-perry | So then we have two components, one for iOS (C) and one for Android (Java). Does it make sense to have these two APIs be more or less the same, to the extent thatâs possible? | 15:45.20 |
| paulgardiner | That's a difficult question to answer | 15:46.17 |
| Robin_Watts | fredross-perry: We already have a C level API that we're quite comfortable with. Having people be able to code at that level is really nice as it's suitably powerful. | 15:46.36 |
| paulgardiner | The more integrated with the OS the less similar I would have thought | 15:46.45 |
| jogux | I would hope that part of the iOS API involves a UIView and/or a UIViewController... so, yeah, what paul says. | 15:46.54 |
| Robin_Watts | But that's a different kind of 'API' than most app authors want. | 15:46.54 |
| paulgardiner | Yes I was wondering about a UIView and UIViewController | 15:47.21 |
| Robin_Watts | Most authors are going to want something that fits in with the native OS UI way of working. | 15:47.23 |
| | (I'm agreeing with Paul and Jogu here - I just can't type as fast or as concisely) | 15:47.40 |
| fredross-perry | One thought I have is that devs are probably making both (iOS and Android). o the extent that the concepts of the two APIs are the same, that makes it easier. | 15:47.44 |
| Robin_Watts | fredross-perry: Except Android and iOS have different ways of working, right? | 15:48.19 |
| | Having something that's broadly similar between both OS sounds vaguely attractive, but I can't help have the feeling that app devs would rather have 2 different things that fit exactly into the worlds of the different OS. | 15:49.22 |
| fredross-perry | I have to research. But it would seem that each probably has some sort of âViewâ thingy that you would instance and size/position, and some sort of event/messaging system. | 15:49.27 |
| Robin_Watts | i.e. in this case matching the underlying OS is more important than having a single thing that works identically on both. If you see what I mean. | 15:49.47 |
| fredross-perry | I see what you mean. Am I correct in saying that workâs been partly done for Android, and nothing yet for iOS? | 15:50.51 |
| Robin_Watts | We have both ios apps and android apps. | 15:51.18 |
| | both are completely separate currently. | 15:51.34 |
| jogux | I see stage one as taking what already exists on iOS and packaging it so that it's trivial to add a 'pdf view' to the developers existing app. | 15:51.42 |
| Robin_Watts | jogux: Yes, 1) above. | 15:51.54 |
| fredross-perry | yes, but in terms of component-izing? JNI? | 15:51.57 |
| paulgardiner | What we haven't achieved in the current apps is separation between what is specific to our particular app from what devs are likely to want in any app | 15:52.38 |
| jogux | fredross-perry: there's no JNI layer or need for one on iOS. ObjC can directly call C. or I've misunderstood the question. | 15:52.44 |
| Robin_Watts | Both the apps are some 'OS specific code' (Objective C on ios, java + some crufty JNI code on android) wrapped around the main C library. | 15:52.50 |
| | The ios code is (AIUI) designed to be an app, not really to be a component that can be easily integrated into anyone elses app. | 15:53.39 |
| paulgardiner | There's been some attempts in both apps to make reusable components, but it was never the main driving force | 15:53.48 |
| fredross-perry | paulgardiner: my point. Is it worth doing any packaging if youâre not moving toward that goal? | 15:53.56 |
| Robin_Watts | It's probably just a refactoring job to get the ios stuff out. | 15:54.06 |
| | fredross-perry: repackaging is the goal we would like you to move towards :) | 15:54.28 |
| | Once we have a repackaged version on ios, we should be in good shape to address the 2 potential classes of developers. | 15:55.11 |
| paulgardiner | fredross-perry: sorry, which goal? | 15:55.14 |
| fredross-perry | âseparation between what is specific to our particular app from what devs are likely to want in any appâ | 15:55.34 |
| Robin_Watts | The first class that wants a component that they can drop in and use and be nicely free of having to know anything about pdf/mupdf specifics. | 15:55.47 |
| paulgardiner | Yeah, you're probably right: repackaging is worth while only if it addresses that | 15:56.22 |
| Robin_Watts | The second class are developers that might want to drive the mupdf library to do cleverer things themselves - doing that at the C level is already possible because Objective C can call C. | 15:56.54 |
| fredross-perry | SO maybe I should start by studying the iOS code, and then make a proposal as to what I think the division should be. What say you all? | 15:57.38 |
| Robin_Watts | fredross-perry: Ideally I think we'd like our app to be a very simple use of the packaged component, right? | 15:57.47 |
| | fredross-perry: That sounds good to me. | 15:58.04 |
| paulgardiner | Yeah as Robin says, in Android there is probably two levels, one for devs that want to do all sorts of complicated stuff but via Java not C, and another level for devs who just want an easy route to display | 15:58.26 |
| | fredross-perry: yeah sounds good | 15:58.43 |
| fredross-perry | OK then. | 15:58.50 |
| Robin_Watts | paulgardiner: I think there are the same 2 classes in both ios and android - just in ios the complexity of the JNI level isn't there to complicate things. | 15:59.09 |
| fredross-perry | robin: yes. | 15:59.21 |
| Robin_Watts | fredross-perry: I have done a bit/some/most of the JNI work. But it's untested and on a branch. | 15:59.54 |
| | When you get to the stage of wanting to look at that, I'll sort you out with a copy. | 16:00.12 |
| fredross-perry | Robin, point me there so I can have a look. | 16:00.28 |
| | ok, not right away then, but soon. | 16:00.29 |
| paulgardiner | Robin_Watts: on iOS though there is no barrier to calling C | 16:00.34 |
| Robin_Watts | (and for the rest of your life...) | 16:00.55 |
| fredross-perry | ;-) | 16:01.16 |
| Robin_Watts | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=shortlog;h=refs/heads/jni2 | 16:01.35 |
| | I may have newer stuff on the macbook. Will need to check. | 16:01.56 |
| fredross-perry | thanks | 16:02.04 |
| jogux | did we ARC the iOS mupdf code yet? If not at least the outer layers should really have that done. | 16:04.49 |
| fredross-perry | Cheers then. heading out for a bit. | 16:07.00 |
| Robin_Watts | ttyl. | 16:07.14 |
| paulgardiner | cyl | 16:07.56 |
| Robin_Watts | paulgardiner: Could you review: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=72f19305bef51c48acf91a380fb08cc4da5b8ea2 please? | 16:39.07 |
| | That gets us back to full speed. | 16:39.17 |
| paulgardiner | Excellent. Just looking | 16:39.38 |
| Robin_Watts | When are tor/chris due back ? | 16:49.38 |
| rayjj | marcosw: BTW, I was able to reproduce the problem for bug 695771. My regression run with extras="-dBGPrint=true" didn't turn this up because, apparently, it only fails with -dNumRenderingThreads > 0, although on Windoze I get different failures with different NRT values | 17:11.24 |
| malc_ | Robin_Watts: speed is back with that commit | 17:14.08 |
| Robin_Watts | malc_: Yeah, that's what I found too. Thanks for checking. | 17:15.07 |
| | paulgardiner spotted a mistake, so I'm tweaking it a bit now (not in a way that will affect the speed) | 17:16.33 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=90c560641d9b459a658029eefc4cbb02fdbca0b5 | 17:18.08 |
| | Better version. | 17:18.10 |
| rayjj | henrys: have you (or someone) taken care of getting fredross-perry on the appropriate mailing lists, and/or getting him an @artifex email ??? | 17:23.54 |
| henrys | rayjj: it's on my list. | 17:24.28 |
| rayjj | henrys: OK. Just thought I'd mention it | 17:24.55 |
| henrys | rayjj: I've reproduced an xps crash with the first file on your list on the mac. | 17:25.37 |
| | rayjj: looks like a continue after malloc fail type of bug. | 17:26.32 |
| | bbiam | 17:27.04 |
| rayjj | henrys: oh, wonder why it only fails on the macpro ? I fixed a bunch of those, but I haven't yet run MEMENTO_SQUEEZE on gxps | 17:28.06 |
| henrys | rayjj: and why is this coming up now? | 17:38.48 |
| Robin_Watts | rayjj: odd. It didn't read to me as a crash... | 17:41.01 |
| | http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?log=log&machine=macpro&report=ray | 17:45.51 |
| | Search for _1803_ in that, and you find the top 2 jobs. Neither of those are crashes. | 17:46.11 |
| malc_ | mupdf doesn't like this jpeg http://boblycat.org/~malc/P0000005.JPG.jpg (it doesn't like it on a x86_64, and likes it on ppc32) weird | 17:46.38 |
| Robin_Watts | It's a 768x512 image, and yet we try to malloc 36864x221184 bytes. Odd. | 17:51.10 |
| henrys | Robin_Watts: I am running a debug build ... | 17:51.14 |
| malc_ | Robin_Watts: aye | 17:51.24 |
| Robin_Watts | malc: OK. so that image claims to be 1 dpi. | 17:57.20 |
| malc_ | a large one | 17:59.31 |
| Robin_Watts | it goes wrong on windows too. | 17:59.58 |
| | on ppc32, the malloc succeeds? | 18:00.07 |
| malc_ | Robin_Watts: no, probably tested something else, sorry | 18:01.16 |
| Robin_Watts | ok, so I can probably put in a fudge to say "disbelieve any resolution < 72dpi" or something. | 18:02.14 |
| | malc_: Proposed fix: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=4001f44c9309eb175fa3211cd6a12ba8c0bb5071 | 18:22.37 |
| malc_ | Robin_Watts: i'm not in any position to judge it :( | 18:23.52 |
| Robin_Watts | malc_: No worries. It seems to fix it here. I'll get it reviewed and committed tomorrow. | 18:25.43 |
| malc_ | Robin_Watts: all of this begs the question, what density has to do with the picture dimensions.. it should only "modify" the way the produced picture is displayed | 18:26.34 |
| | or something | 18:26.34 |
| | Robin_Watts: thanks | 18:26.34 |
| Robin_Watts | malc_: For the image handler, we attempt to respect the dpi of the images. | 18:27.22 |
| | The idea is that people call mupdf and tell it to render the 'content' to an output of a given dpi. | 18:28.22 |
| | This means that if they change the dpi, they can reasonably expect the content to get bigger/get smaller as they do so. | 18:29.02 |
| malc_ | Robin_Watts: what it has to do with loader_jpeg though | 18:29.36 |
| Robin_Watts | As such, if someone has a 300 dpi JPEG, we use the width of the JPEG plus the given xres/yres of the JPEG to figure out the physical size of the jpeg (in inches) | 18:30.02 |
| | That gives us the bounds of the page, and we render the image to fill those bounds. | 18:30.31 |
| malc_ | Robin_Watts: things are getting stranger.. with mupdf i hit the issue with my own viewer (which uses mupdf) i don't.. wonder where i fscked up | 18:38.48 |
| Robin_Watts | malc_: Possibly you call bound_page and then scale it down automatically? | 18:43.17 |
| malc_ | Robin_Watts: image_load_page, image_bound_page is what i do - yes (just to get mediabox) | 18:51.43 |
| Robin_Watts | malc_: Right, and we'll return a huge mediabox. | 18:52.08 |
| | I suspect you then scale it to fit on the screen or something? | 18:52.16 |
| malc_ | Robin_Watts: yep | 18:53.04 |
| mvrhel_laptop | bbiaw | 20:30.04 |
| | lunch time | 20:30.08 |
| henrys | this code signing gdb on mac os x is nuts. what a hassle | 22:30.29 |
| | and gdb is flakey on mac osx wonderful... | 22:45.34 |
| | Forward 1 day (to 2015/01/07)>>> | |
IRC Logs
