| | <<<Back 1 day (to 2013/09/24) | 2013/09/25 |
| sebras2 | Happy belated birthday mupdf! September 24th 9 years ago was the earliest mupdf commit I could find in any of my ancient repos. I assume that tor might know more. :) | 01:53.12 |
| paulgardiner | tor7: ping | 09:05.11 |
| tor7 | paulgardiner: morning. | 09:05.59 |
| | paulgardiner: yes, your patches from last night are good to commit. | 09:06.11 |
| paulgardiner | Magic. Thank you. | 09:06.24 |
| | Glad you prompted me to remove the factory madness :-) | 09:06.46 |
| Robin_Watts | I'm sure there is a "Paul == Mrs Thatcher" joke in there somewhere. | 09:07.15 |
| paulgardiner | In my case it was just the one factory | 09:09.16 |
| | tor7: just put up one more tiny commit | 09:19.27 |
| tor7 | paulgardiner: "race" condition with pages being rendered in the background while zooming? | 09:20.40 |
| paulgardiner | I think I have that handled: MuPageViewReflow, in addition to acting on the scale factor, also stores it and applies it to the page in webVewDidFinishLoad | 09:22.51 |
| | ... assuming that's the sort of race condition you were thinking of. | 09:23.10 |
| tor7 | paulgardiner: more like wondering what the tiny commit was for | 09:27.50 |
| paulgardiner | Makes the adjustment using pinch 3x less lumpy | 09:28.35 |
| | I was adjusting all 3 pages on every step of the gesture | 09:28.59 |
| | I think I may be doing the same in Android, so I'll see if I can do the same speed up there | 09:29.27 |
| tor7 | paulgardiner: oh, right. | 09:38.39 |
| | shouldn't have a visible effect (given that the other two are off screen) but I guess it means less work so better performance? | 09:39.14 |
| Robin_Watts | So I mailed a set of questions to the customer last night at 9pm (2pm their time). And they haven't bothered to respond. So that's a day lost. Jeez. | 09:39.31 |
| | And if I run the same file twice through their code, I get different output files. So it's not easy for me to blindly try optimising bits of code. | 09:40.25 |
| chrisl | Robin_Watts: is this 532? | 09:41.22 |
| Robin_Watts | Len and co. | 09:42.29 |
| chrisl | Yeh, that's not unusual, from my experience....... | 09:42.51 |
| | "Urgent" can be a very fluid term, whose definition depends on whether they are waiting on stuff from us, or vice versa :-( | 09:44.56 |
| Robin_Watts | chrisl: Any idea what CPU is in their target device? | 09:45.41 |
| chrisl | IIRC, it's PPC603 | 09:46.12 |
| Robin_Watts | Ah, thanks. | 09:46.19 |
| paulgardiner | tor7: It seems UIWebView reacts to it whether on or off screen. | 09:50.30 |
| tor7 | paulgardiner: ah, yes. and resizing a UIWebView is bound to be hideously more CPU-intensive than a simple image-based view | 09:51.11 |
| | paulgardiner: go ahead and push that one too. | 09:51.21 |
| paulgardiner | ta | 09:52.32 |
| Vardis | Hello I hawe a qusetion . Do mupdf support searching pdf with cyrillic? | 10:20.42 |
| | Or is possible some how enable it? | 10:22.53 |
| | /names | 10:23.07 |
| tor7 | Vardis: it should work out of the box with the android app | 10:26.48 |
| | Vardis: are you using the windows or linux viewer? in that case, there are some issue with the input text field only supporting latin-1 | 10:27.21 |
| Vardis | tor7 Using linux current git | 10:28.02 |
| tor7 | Vardis: right. so there's the latin-1 limit for you :( | 10:32.23 |
| | sebras has an experimental branch to add some proper text editing with unicode support, but that's not ready yet. the core library in mupdf can search with unicode, but the X11 gui doesn't. | 10:33.09 |
| paulgardiner | tor7: Another little commit. Same as last one, but for Android, plus a fix for the race condition you thought might be in the iOS app, and was in fact in the Android app! | 11:32.25 |
| tor7 | paulgardiner: s/laoding/loading/ | 11:40.27 |
| paulgardiner | tor7: Ta. Sorted. | 11:41.31 |
| Robin_Watts | paulgardiner: So... suppose I scroll a view half off the screen, so I can see 2 pages. | 13:06.49 |
| | and I zoom the page I'm on... | 13:06.59 |
| | the second page no longer zooms to match the first one? | 13:07.09 |
| paulgardiner | Yeah but I think that's preferable to it being almost unusably lumpy | 13:08.09 |
| Robin_Watts | paulgardiner: OK, but what happens when you stop zooming? | 13:12.44 |
| paulgardiner | It then catches up | 13:12.58 |
| Robin_Watts | If I then pan to the next page, is the zoom now wrong? | 13:12.58 |
| | So subsequent pages 'jump' at the end of the zooming process. | 13:13.15 |
| paulgardiner | Yes, but usually they are not visible | 13:13.33 |
| Robin_Watts | Would it be possible to say "only set the zoom on a page if it's at least partially visible" ? | 13:13.39 |
| | That way we'd get smoothness *and* consistency. | 13:13.49 |
| paulgardiner | That would then give us 2x lumpiness back | 13:14.19 |
| | Better than 3x, but still not desirable | 13:14.32 |
| Robin_Watts | paulgardiner: In the normal "only 1 page visible" case, we'd get the same smoothness you get now. | 13:15.26 |
| paulgardiner | The jump at the end of the zoom isn't visible even in the half-panned case you describe because the animation back to full page visible beats it | 13:15.32 |
| Robin_Watts | In the "2 pages visible" case, we'd be better than we are now, but still be consistent. | 13:15.59 |
| | The visual feedback that the user gets is "I am only changing the zoom for the current page". | 13:16.29 |
| | So when you pan and you find the next page has zoomed, that's a surprise. | 13:16.47 |
| paulgardiner | I think you'd very often get a tiny bit of another page on because a little drag before the zoom is difficult to avoid. | 13:16.57 |
| Robin_Watts | So, by the principle of least surprise, it's wrong. | 13:17.05 |
| | We have a gap between pages, right? | 13:17.29 |
| | tor7: Any thoughts here? | 13:17.58 |
| Robin_Watts | grabs lnch. bbs. | 13:18.07 |
| | lunch. | 13:18.10 |
| paulgardiner | I see a little sliver of another page typically when I zoom | 13:18.17 |
| | Robin_Watts: It's not that I don't want to change it per se. I just think the current behaviour is a clear win over the alternatives. | 13:19.40 |
| | Robin_Watts: It even wins by the principle of least surprise. Noticing the second page not zooming would be slightly surprising. Randomly having the zoom twice as lumpy would be strange and difficult to understand. | 13:21.18 |
| tor7 | Robin_Watts: I think the tiny bit of another page depends on the aspect ratios of the pages and the screen and current orientation | 13:26.49 |
| | if it's fit-to-width or fit-to-height | 13:26.56 |
| amr_ | hello, I have a problem in building mupdf on android, I have been following the documentation, but in step no. 12 which is "execute ndk-build in Cygwin" it tells me that the command not found!!! | 13:37.43 |
| | although I have followed all the previous steps | 13:38.12 |
| | hello, I have a problem in building mupdf on android, I have been following the documentation, but in step no. 12 which is "execute ndk-build in Cygwin" it tells me that the command not found!!! | 13:40.19 |
| tor7 | amr_: then I suspect you haven't properly set up or installed the ndk | 13:47.19 |
| Robin_Watts | amr_: The latest versions of the ndk allow ndk-build to be run in a DOS window - i.e. you may not need cygwin. | 13:58.06 |
| amr_ | ok Robin, I downloaded the android ndk, and unpacked it to a directory without any spaces, but still giving me the same command "command not found" | 14:12.17 |
| Robin_Watts | amr_: Have you ensured that the ndk-build command is on your path ? | 14:15.14 |
| amr_ | yes, it is | 14:15.33 |
| Robin_Watts | Are you in cygwin or dos, currently? | 14:16.02 |
| amr_ | dos | 14:18.54 |
| Robin_Watts | echo %PATH% | 14:20.55 |
| | then check that the ndk is properly added to what is printed. | 14:21.32 |
| amr_ | yes, it's not seeing it in the path when I checked the path in the cmd, but why although when I go to variable environment I can see it!! | 14:29.55 |
| Robin_Watts | amr_: Have you restarted the sygwin window since installing it ? | 14:32.47 |
| amr_ | ok i did now and after I executed the command it showed me another error ""Compile thumb : mupdf <= mupdf.c jni/mupdf.c:15:24: fatal error: mupdf/fitz.h: No such file or directory compilation terminated. make: *** [obj/local/armeabi-v7a/objs/mupdf/mupdf.o] Error 1" | 14:37.35 |
| Robin_Watts | amr_: What version of the source do you have? | 14:41.41 |
| | Are you checking out from git ? | 14:41.47 |
| amr_ | the latest one 1.3 I used git to clone it | 14:42.17 |
| Robin_Watts | amr_: You mean you cloned git and then checked out to the 1.3 tag? | 14:42.49 |
| | Or are you on HEAD ? | 14:42.59 |
| | master, rather. | 14:43.04 |
| | What SHA are you on? | 14:43.17 |
| | git log -1 and paste the hash from there. | 14:43.34 |
| amr_ | what do you mean by SHA? | 14:44.08 |
| Robin_Watts | amr_: I mean, what hash are you on? | 14:44.45 |
| | git identifies commits by a hexidecimal hash number. | 14:45.02 |
| amr_ | I really don't understand what you mean | 14:45.41 |
| Robin_Watts | Do: git log -1 | 14:45.56 |
| | and then paste the "commit" line from that. | 14:46.18 |
| amr_ | excuse me but I don't understand what do you mean by git log -1? what is that? a command should i write or what? | 14:48.39 |
| Robin_Watts | A command you should execute, yes. | 14:49.24 |
| amr_ | commit 43bcd8a7516bfbd455d81de7e00d5e139abce438 | 14:51.36 |
| Robin_Watts | ok. paulgardiner are you here? | 14:52.06 |
| paulgardiner | Yep | 14:52.28 |
| Robin_Watts | You've been playing with the android build, right? amr_ is pretty up to date. | 14:52.35 |
| | Does the android build work for you? | 14:52.43 |
| paulgardiner | I'll give it a try | 14:53.05 |
| Robin_Watts | his error would seem to imply that the include path isn't set up right in the ndk-build step. | 14:53.37 |
| paulgardiner | The last time I installed the ndk, the path wasn't updated automatically, so I used the full path to ndk-build and it worked. | 14:54.21 |
| Robin_Watts | We're past the "ndk-build not found" thing. | 14:54.58 |
| | it now starts to build, but gives the error he pasted earlier about mupdf/fitz.h not being found. | 14:55.26 |
| paulgardiner | Oh okay. I suspected that which was why I didn't interject that before | 14:55.32 |
| Robin_Watts | which smells like include is not being passed to the compiler. | 14:55.53 |
| paulgardiner | It looks to be happily building here | 14:55.58 |
| | I seem to be using r8e. I think i have some flavour of 9 on my lap top and that worked last time I tried it | 14:56.39 |
| Robin_Watts | amr_: Well, it's building for paulgardiner, so I'm a bit at a loss, and I don't have time to go hunting further for problems, sorry. I have a rush job on at the moment. | 14:56.44 |
| paulgardiner | Build successful here | 14:56.48 |
| tor7 | gee, thanks again apple... ipad is stuck on an "activating ipad" screen, with no way to proceed. "activation servers are unavailable. try using itunes." itunes says, "can't upgrade, because I can't find the frigging file". | 15:00.27 |
| Robin_Watts | makes mental note to leave the itouch on airplane mode for another week. | 15:01.49 |
| amr_ | ok, can you just tell me what is the problem and I will solve it on my own? | 15:02.03 |
| | what is paulgardiner? | 15:02.42 |
| Robin_Watts | a question for the ages :) | 15:03.10 |
| paulgardiner | :-) | 15:05.19 |
| amr_ | paulgardiner, can you help me in this? | 15:06.18 |
| paulgardiner | amr_: The problem is that we don't know what the problem is. It look to be a problem local to your set up and not one in mupdf itself. My advice would be to uninstall the ndk, delete mupdf and then reinstall | 15:07.17 |
| amr_ | ok, thanks :) | 15:07.52 |
| paulgardiner | Don't bother with cygwin. It isn't needed with the latest ndk releases | 15:08.12 |
| amr_ | ok :) | 15:13.46 |
| ray_laptop | Robin_Watts: based on your pointing out the waste of going from YCC to RGB back to Gray, I am trying to modify pdf_draw so that when the filter is I force the image colorspace to gray. | 15:40.00 |
| | I looked at the jpeglib code and it looks like this will just pick the Y component. | 15:40.46 |
| Robin_Watts | ray_laptop: Ah, cool. Cos I reckon the only hope we have for getting anywhere close to their target will come from that, and the benefits from not shunting rgb data all the way through the pipeline. | 15:40.56 |
| paulgardiner | tor7: There's places in the iOS app where you use the background queue, but have it do nothing other than perform an action on the main queue. What does that do? Is that to delay the action until rendering has completed? | 15:41.10 |
| ray_laptop | Then the rest of the image code will be processing a DeviceGray image | 15:41.13 |
| Robin_Watts | ray_laptop: Indeed. It should avoid upscaling of the U and V and possibly even avoid the dct for those components too. | 15:41.40 |
| ray_laptop | now the challenge is to get that to work :-) | 15:41.43 |
| Robin_Watts | ray_laptop: Let me know if there is anything I can do to help. | 15:43.08 |
| ray_laptop | well, if you can think of any other areas to improve... in particular, the ktd_image_render in base/gdevAl2ktd.c | 15:46.03 |
| | It'll be processing less data, so that should help, but the coding style is not the cleanest | 15:46.47 |
| Robin_Watts | ray_laptop: I've tweaked their ktd_put_pdf14_image. Seems to be faster on x86 at least. | 15:48.24 |
| | I'm looking at the pdf14 blending now. | 15:48.56 |
| | I couldn't see anything obvious in ktd_image_render when I looked. | 15:48.59 |
| ray_laptop | Robin_Watts: OK. That's only used on page 2. Also, could you look at whether or not the dirty_rect tracking looks right, so we are pushing minimal data through ? | 15:49.36 |
| Robin_Watts | diret_rect tracking being part of what? pdf14? or clist? | 15:50.06 |
| ray_laptop | Robin_Watts: pdf14 painting | 15:50.19 |
| Robin_Watts | ok. | 15:50.25 |
| ray_laptop | the clist code keeps track of the transparency rectangles, but we only use it for band level decision of skipping transparency compositor actions for the band | 15:51.17 |
| | but ISTR that the pdf14 keeps track so that when it does the put_image it can only transfer the areas that have been painted | 15:52.16 |
| | Robin_Watts: and is the pdf14 device keeping everything as gray+tag ? (the color code this is based on used RGB) | 15:53.39 |
| Robin_Watts | ray_laptop: Yes, the blends and things I'm seeing in pdf14 are all grey+tag. | 15:55.15 |
| | WHY TAG? WHY? | 15:55.18 |
| | Why carry twice as much data around as it needs? including through the pdf14 device. | 15:57.11 |
| ray_laptop | Robin_Watts: they are supposed to be investigating it. They may be using it to select the halftone pattern when painting. For text, some printers use a finer halftone cell with less levels to make non black text edges "nicer" | 15:58.48 |
| chrisl | Robin_Watts: does that printer model do forcing text to black? Presumably they'd need the tag plane for that? | 15:58.49 |
| Robin_Watts | ray_laptop: Have I missed an email from them? | 15:59.13 |
| ray_laptop | Part of the problem is that they are very close to product release and so they are resistant to a change that would affect image appearance | 15:59.55 |
| | Robin_Watts: I don't think so. | 16:00.11 |
| Robin_Watts | Gruezi zeniko | 16:17.17 |
| zeniko | Robin_Watts: tor7: There's 10 new patches on zeniko/mupdf for you to review when you have some time to spare. | 16:17.22 |
| kens | OK I'm off, I'll look at my last form problem tomorrow, goodnight all | 16:18.27 |
| Robin_Watts | zeniko: Thanks. Will look as soon as I get my head above water again. | 16:23.26 |
| zeniko | Robin_Watts: I rarely get much time for being on IRC. I'll go through the IRC logs, in case you get to the patches while I'm not there. | 16:27.33 |
| Robin_Watts | zeniko: ok, thanks. | 16:28.28 |
| | I'm stuck in a rush gs job for a customer, or I'd look now. | 16:28.42 |
| zeniko | No worries. Most of these is code we need for SumatraPDF and which I'm just passing back to you upstream in order to reduce the differences between your and our repository. | 16:31.06 |
| Robin_Watts | zeniko: Sure. makes sense. | 16:32.27 |
| zeniko | Let's see how far we can get there. E.g. I'm not sure if you're interested in the .tga output to mudraw at all. | 16:34.24 |
| | I assume that some of our font changes might also be controversial - and then we maintain fixes to bugs which tor7 has wontfixed already. | 16:35.06 |
| | Robin_Watts: Maybe it would be easiest to mail you the main set of patches which I think would make sense for merging so that you or tor7 can go through it and decide which ones you'd accept at all. | 16:37.27 |
| ray_laptop | hmm... A quick test forcing gray doesn't work. There's like multiple images. | 16:38.21 |
| Robin_Watts | zeniko: It's probably best to do it via bugzilla - that way it's less prone to tor or I dropping the ball due to pressures from outside. | 16:38.29 |
| | For bugfixes, if you can supply an example file that shows why it's a problem, that makes it a lot easier for us to nod it through. | 16:39.43 |
| | font changes done specifically for windows are a problem. I think tor7 has font API changes on his ToDo list. I think the plan is for him to talk to you about that when he's sketched up the API he wants. | 16:40.37 |
| | I don't think we're burning for .tga output, but then again, if it's a small enough patch, it would probably make sense for us to take it. | 16:41.22 |
| | I need to revisit the output stuff to ensure we do banding for all the ones we can. | 16:41.39 |
| zeniko | It should be possible to add banding to the .tga output as well if you want that. Only bit that one needs is to also write a footer. | 16:42.48 |
| Robin_Watts | ray_laptop: What's the name of the their tool for viewing their output files? | 16:43.04 |
| | zeniko: OK, one of the other formats has a footer as well. | 16:43.25 |
| ray_laptop | Robin_Watts: wheel.exe | 16:43.26 |
| Robin_Watts | Got it. Ta. | 16:43.44 |
| ray_laptop | Robin_Watts: let me put it up on peeves to make sure you have the right one | 16:43.47 |
| | or is the one you have already working ? | 16:44.13 |
| Robin_Watts | Mine says it's out of date :( | 16:44.40 |
| | I have 1.12.2 | 16:44.50 |
| ray_laptop | Robin_Watts: I have 1.13 -- I'll upload it to peeves... | 16:45.50 |
| Robin_Watts | Thanks. | 16:45.58 |
| ray_laptop | Robin_Watts: It's there now | 16:47.11 |
| zeniko | Robin_Watts: I can add banding if you'd accept the patch that way (we don't need that ourselves). | 16:47.16 |
| | Gotta run now, see you around. | 16:47.29 |
| Robin_Watts | cu | 16:47.33 |
| tor7 | paulgardiner: any particular location? | 17:08.04 |
| paulgardiner | resizeImage in MuPageViewNormal for example. | 17:10.14 |
| | I guess it is a way to sort-of sync the queue without stalling | 17:11.07 |
| | Finish anything in the backgound and then do: | 17:11.28 |
| Robin_Watts | great, now my email won't send through the 3G dongle :( | 17:11.32 |
| paulgardiner | Robin_Watts: do BT and your internet provider know you have a shotgun? | 17:12.26 |
| Robin_Watts | paulgardiner: Mentioning this to BT would not be condusive to them sending an engineer to fix it. | 17:15.20 |
| | Or at least not one they weren't keen to lose. | 17:15.33 |
| paulgardiner | Damn! yeah, you're right | 17:17.10 |
| ray_laptop | errand. bbiab | 17:41.08 |
| willschm | ghostscript 9.09 in a powerpc (LE) environment, i'm seeing stack corruption in the neighborhood of TrioFormatProcess, 0x20's get written over the stack. Still trying to narrow down exactly where, but.. are there any TRIO_* defines that would be affected by endianness that aren't obvious by their names? | 18:37.27 |
| mvrhel_laptop | the transparency rabbit hole is going deeper and deeper with the nonisolated knockout stuff. trying to get a handle on the shape and alpha_g planes that the blending code seems to need for these cases at the same time | 18:54.51 |
| Robin_Watts | willschm: You probably need to speak to chrisl, but he's away for the night. | 19:17.32 |
| | I know some fixes have just been done to gs (well, at least one) for the powerpc. | 19:17.48 |
| | You might want to try grabbing the latest version from git and building that. | 19:18.00 |
| willschm | Robin_Watts: Ok, thanks. I'll continue lurking and catch him when I can. :-) | 19:19.08 |
| | looks like I am able to get a lot farther by disabling TRIO_FEATURE_FLOAT ... something fishy in the long double code that ends up getting called. | 19:20.10 |
| tor7 | paulgardiner: yeah, I can't remember why I do that dance in resizeImage | 20:04.45 |
| | but I'd be willing to bet it's to do with not freezing up the GUI, and letting queued jobs finish in order | 20:05.23 |
| | you could try ripping out the dance and seeing what happens. it might be some intricate interaction with queued jobs and the cancelling of pages... but really, I've completely forgotten so your guess is as good as mine. | 20:07.06 |
| chrisl_away | willschm: I'm not starting working again now, but if you open a bug in our bugzilla put a test file, command line and other details in that, I'll take a look tomorrow | 20:18.01 |
| mvrhel_laptop | bye | 20:27.08 |
| willschm | chrisl_away: Ok. the *big* footnote on what i'm doing is that i'm running ppc64 in Little Endian mode, so issues i'm hitting are likely do to endianness assumptions that have been true forever up until now. | 20:27.43 |
| ray_laptop | willschm: since x86 is little endian, and SPARC is big endian, most endian-ness issues should be OK. We regularly run on both. I don't recall offhand what the ARM endian usually is. | 23:02.39 |
| Robin_Watts | ARM endian is small on all sane systems. | 23:03.33 |
| | apple use mixed. | 23:03.36 |
| ray_laptop | willschm: there may be an issue with alignment on the PPC with long doubles that we aren't handling | 23:04.03 |
| | Robin_Watts: I've proven the concept of forcing JPEG to convert to monochrome and getting the right images out. Now I just have to come up with the "plumbing" for the customer's version | 23:05.22 |
| Robin_Watts | excellent. | 23:05.37 |
| | Let me know if there is anything I can do to help. | 23:06.02 |
| ray_laptop | I have the PS working -- just need to make it conditional on the device being monochrome, then I need to force a parameter into the DCT filter to tell it that we want monochrome | 23:12.35 |
| | OK. currentpagedevice /Colors get returns 1 for monochrome devices. I'll tuck that away in a dict so I don't need to do a getparams on every image | 23:17.36 |
| | Forward 1 day (to 2013/09/26)>>> | |
IRC Logs