| | <<<Back 1 day (to 2012/10/23) | 2012/10/24 |
| Robin_Watts | mvrhel: I've grabbed bug 693407 - if you object, just say. | 00:43.17 |
| | Having said that, it works perfectly for me, I think. | 00:43.55 |
| | Will retest more thoroughly in the morning. | 00:44.08 |
| marcosw | alexcher: there is a problem with alex_x6. Do i have a login on that machine? If so could you let me know the ip address, it's not in /etc/hosts on gate. If I don't have a login check the end of the alex_x6.dbg file to see if there are any obvious error messages. | 00:45.50 |
| Robin_Watts | Ah marcosw, you're awake... | 00:47.19 |
| | bug 693407 - does it look completely blank when it fails ? | 00:47.34 |
| marcosw | No, I just added a screen shot of the current master vs. 9.02. I do see a blank page with 9.06 | 00:48.07 |
| Robin_Watts | OK. I see the flaw, thanks. | 00:50.55 |
| | I'll try to track it down tomorrow. | 00:51.10 |
| marcosw | thx | 00:53.18 |
| mvrhel_laptop_ | hi Robin_Watts | 01:28.23 |
| | thanks for the heads up on you taking the bug | 01:28.34 |
| | I was just about to look at it | 01:28.41 |
| mvrhel_laptop | henrys: Is Gemma just using tiffsep so that they can get overprint preview? If so, the may be able to just use tiff32nc with the -dSimulateOverprint | 01:42.44 |
| | marcosw: do you know the answer to this? | 01:43.04 |
| | this would free the from the limit on the spot colorants and save in performance | 01:44.33 |
| | boy I can't type tonight | 01:44.46 |
| | back to a few more things for customer 330 | 01:54.23 |
| marcosw | mvrhel_laptop: I believe you are correct, gemma only uses the preview image. | 02:20.28 |
| mvrhel_laptop | then it may make some sense to ease her into the approach that I mentioned. plus we could get some testing of this | 02:21.04 |
| marcosw | I'll confirm with her and suggest the -dSimulateOverprint feature. I presume that's a recent feature and we'll need to get her a current build. | 02:21.16 |
| mvrhel_laptop | yes | 02:21.33 |
| | and its testing is limited. customer 330 requested this and I am trying to test it as best I can | 02:21.51 |
| | we dont really have a contone CMYK device that we test on the cluster do we | 02:23.09 |
| | bbiaw | 02:51.04 |
| kens | chrisl, I see the inkcov thing is runbling on | 07:05.57 |
| | Do we know if 'Kent' is usinga debug build ?If so we could get him to run with -Z: and copy the result to us. | 07:07.12 |
| | I'm wondering if this is related to bug #693367 which is a filename problem, also apparently using Java. | 07:07.47 |
| chrisl | kens: No, I think he's using the build I did to test my change adding inkcov, and offered to let him use it. So, not debug, no | 07:21.55 |
| | He claims the same code works for JPEG output, so I can't see it being a file name problem..... | 07:22.31 |
| kens | It might be worth giving him a debug build to try, so we can see the arguments, I'm suspicous that his Java is screwing up teh arguments | 07:22.56 |
| | I'd like to close that bug too, since its been idle for 2 weeks. How long do I haveto wait for a customer resposne do you think ? | 07:23.22 |
| chrisl | Hmm, I thought it was C++..... | 07:23.32 |
| kens | I thought that initially but... | 07:24.02 |
| chrisl | Depends on the customer, and my memory: I usually wait a week for customers with a history of being a pain, and two weeks for "good" customers. | 07:24.27 |
| kens | They are well pas either then :-) | 07:25.04 |
| | The bit that looks non C++ to me is: | 07:25.30 |
| | args[8] = string.Format("-sOutputFile={0}",outfile.txt); | 07:25.30 |
| | args[9] = string.Format("{0}", inputfile.pdf); | 07:25.30 |
| | But I guess that might be C++ it depdends on his string class | 07:25.54 |
| | Either way, I think it woulod be useful to see what he's passing, given that the command line app allagedly works | 07:26.37 |
| chrisl | Okay, I will do a debug build for him. I can't do a debug build with an installer, IIRC...... | 07:27.45 |
| kens | Surely he can just replace the executable ? | 07:27.59 |
| | I mean, if he's coding his own app, he should be capable of that :-) | 07:28.16 |
| chrisl | DLL, yes. But...... | 07:28.24 |
| kens | Well, closed that bug, lets see if that provokes some action. | 07:31.20 |
| chrisl | Well, we can't just sit on open bugs when the reporter doesn't respond | 07:32.24 |
| kens | I suspect that they followed one of the suggestions, discovered their app was passing the wrong filename and fixed it. They aren't terribly good about telling us stuff like that (embarrassed I exepct) | 07:34.35 |
| chrisl | kens: I'm suspicious "Kent" hasn't done anything about stdout/stderr, so I thought it better to check that before going further | 07:56.27 |
| kens | Yes I saw the mail | 07:56.56 |
| | He *really* needs to see stdout and stderr | 07:57.10 |
| chrisl | That's why I didn't any point doing anything more until we check that... | 07:57.47 |
| miha | good morning | 09:08.17 |
| sebras | miha: likewise. | 09:12.40 |
| miha | how to make this mupdf android ndk-build faster... int resolution in mupdf.c ? APP_OPTIM := release in Application.mk ? something else? threads perhaps? :) | 09:34.44 |
| Robin_Watts | miha: The resolution you need to render at is set by the number of pixels on the screen and the selected zoom level. | 09:36.56 |
| | Yes, a release build would be faster, in theory at least. | 09:37.15 |
| miha | Robin_Watts: from my brief testing, about 2x as fast as debug | 09:37.34 |
| Robin_Watts | And using threads is possible. | 09:37.37 |
| | cool. | 09:37.39 |
| miha | Robin_Watts: using threads is possible how? :) | 09:38.47 |
| Robin_Watts | See doc/overview.txt | 09:39.52 |
| miha | Robin_Watts: i see. | 09:43.03 |
| | what does this mean 10-24 11:59:10.700: E/libmupdf(26790): warning: openjpeg warning: SOT marker inconsistency in tile 304: tile-part index greater (5) than number of tile-parts (5) | 09:58.03 |
| | i get lots of these often :) | 09:58.13 |
| Robin_Watts | There is an image in your file in Jpeg2000 format. | 10:04.49 |
| | and the decoding software we use doesn't like it. | 10:05.06 |
| miha | oh :) | 10:06.38 |
| Robin_Watts | well, the decoding software decodes it, but it finds problems with it - hence that warning. | 10:07.03 |
| sebras | miha: it may be valuable to extract that j2k image and send it to openjpegs bugtracker so they can take a look at it. | 10:08.43 |
| miha | sebras: may i msg? | 10:19.39 |
| sebras | miha: sure. | 10:25.47 |
| | miha: I'm leaving for lunch in a few mins, though. | 10:26.00 |
| miha | sebras: ok, can wait :) | 10:28.47 |
| paulgardiner | tor8, Robin_Watts: yesterday's commits with the requested alterations are up on paulg/master | 14:04.49 |
| kens | mvrhel : or mvrhel_laptop, you free for a few minutes ? | 14:27.42 |
| chrisl | Hmm, there doesn't seem to be a printf format placeholder for a 64 bit integer that won't result in a warning on one or other build :-( | 14:55.29 |
| kens | :-( | 14:55.57 |
| chrisl | I thought the whole point of the C99 macros was to avoid exactly this problem! | 14:57.48 |
| mvrhel_laptop | kens: I have to run kids to school. be back in a bit | 15:12.40 |
| henrys | why did we have 4000 dpi for the bbox device? | 15:18.56 |
| kens | To meka ure its accurate ? | 15:19.39 |
| | sure* | 15:19.44 |
| henrys | seems excessive and risks overflowing internal fixed coordinates at very large page sizes. | 15:22.23 |
| kens | Well, low resolution gives the wrong answer sometimes,epscially with glyphs near the edge of the page | 15:22.50 |
| | THat said, 4000 does seem like a lot | 15:24.10 |
| chrisl | henrys: Ray seemed quite insistent that we retain the high resolution when I queried it a couple of years ago | 15:25.16 |
| | Although I would probably favour something like 4320dpi...... | 15:27.08 |
| kens | 4321, it has a nicer sequence :-) | 15:29.59 |
| chrisl | But not an integer multiple of 72.... | 15:30.38 |
| | OKay, 6.9Gb PDF ripping on Windows...... | 15:31.59 |
| kens | cool | 15:33.20 |
| henrys | I wonder when a morning will begin without hpgl/2 questions. | 15:33.32 |
| chrisl | henrys: I suspect bbox outputs the coordinates in a PS/PDF style coordinate space, which, IIRC, is "upside-down" compared to PCL. Could that be a source of confusion? | 15:40.17 |
| | Crumbs, Freetype converted to JavaScript...... | 15:42.58 |
| henrys | gl/2 is the same as ps most of the time. But generally I think the coordinates are reported in "user space" so it should just work for everything. I'll debug it today sometime. | 15:43.42 |
| kens | chrisl yes I saw that | 15:43.54 |
| chrisl | kens: at least they were reasonable in the "Why? Because we can....." bit! | 15:44.26 |
| henrys | in fact pcl used to embed the bbox device to catch dirty pages but it was a performance hit so I moved to heuristics. | 15:44.30 |
| kens | alongwith teh 'don'tlook at the performance' and 'really, don't do this' | 15:44.37 |
| chrisl | henrys: it was just the comment about missing marks at the bottom of the page when the bounding box starts at {0,0} | 15:45.27 |
| | kens: I wonder.... Ghostscript is JavaScript.... :-) | 15:45.49 |
| | s/is/in | 15:45.54 |
| kens | It crossed my mind... | 15:46.02 |
| | I *will* be impressed if the tool works for that | 15:46.17 |
| chrisl | Possibly mupdf would be a less insane idea..... | 15:46.25 |
| | (But still insane!) | 15:46.33 |
| kens | DOn't suggets it where Tor might hear you :-) | 15:47.09 |
| chrisl | Is emscripten what google are using for their C to JS conversion? | 15:47.50 |
| kens | I owuld guess so | 15:48.01 |
| chrisl | I had it in my mind it was Google's own tool | 15:48.44 |
| kens | I'm sure Google would like you to think that ;-) | 15:49.03 |
| henrys | it's funny you mention that becuase I was wondering how an emscripten'd mupdf would perform against mozilla's js pdf. | 15:49.04 |
| kens | hears the sound of Tor running away | 15:49.24 |
| chrisl | Porbably poorly as I suspect they use the browser canvas for rendering, so that would be "native" | 15:50.05 |
| henrys | well that kind of stuff could be "patched up" later ;-) | 15:51.18 |
| chrisl | a simple matter of programming....... | 15:52.28 |
| henrys | I have talked miles into going bsd for jbig2dec, now I just have to convince you guys. | 15:53.11 |
| Robin_Watts | henrys: What's the advantage to us? | 15:53.35 |
| henrys | mozilla would like to use it and I think it is would good for us to improve our relationship with them. | 15:54.10 |
| chrisl | Fine by me, I can't see that we can generate any revenue from it...... | 15:54.20 |
| Robin_Watts | chrisl: Right, except our competitors (pdf.js) get to use it to improve their competing product. | 15:54.59 |
| | Let's give everyone baseball bats so they can hit us with them. | 15:55.46 |
| henrys | they'll just use something else | 15:55.52 |
| chrisl | Or write their own | 15:56.04 |
| kens | jbig2 is not that hard, I'm sure a Google engineer could code it in a week or so | 15:56.05 |
| henrys | and we might get bug fixes back. | 15:56.26 |
| Robin_Watts | If we can guarantee getting fixes back, that may be worthwhile. but BSD does not guarantee us that. | 15:56.40 |
| henrys | keep in mind commercially we use luratech. | 15:58.06 |
| mvrhel_laptop | kens: I am here now if you want to chat | 15:58.07 |
| kens | OK off for a pizza, I'll try and come back later, night all | 15:58.08 |
| | SOrry mvrhel | 15:58.16 |
| Robin_Watts | I have no strong objection I guess. As chrisl says, we aren't getting revenue from it. | 15:59.19 |
| | I fear that it won't do anything meaningful in "improving our relationship with mozilla". | 15:59.53 |
| sebras | I guess you guys know of https://mozillalabs.com/en-US/pdfjs/ already..? | 16:01.13 |
| Robin_Watts | sebras: See what I said about pdf.js above :) | 16:01.43 |
| sebras | Robin_Watts: oh, sorry. | 16:02.13 |
| | I replied before getting to the end of the log. :) | 16:02.23 |
| Robin_Watts | no worries. | 16:02.23 |
| | I often don't listen to what I say either >8*) | 16:02.43 |
| sebras | what dictates the choice of license apart from your own whims? | 16:02.49 |
| henrys | sebrase:right we are going to bsd jbig2dec so they can use it in pdfjs, that's what we are talking about. | 16:03.19 |
| sebras | henrys: oh, I see. :) | 16:03.55 |
| Robin_Watts | sebras: We want to be able to sell the stuff we write - hence anything we hope to generate revenue from can't be BSD. | 16:03.57 |
| sebras | Robin_Watts: true. does it have to be BSD? pdf.js appears to be apache v2.0 | 16:05.40 |
| | I always forget the license compatibilty matrix. :-/ | 16:05.59 |
| Robin_Watts | BSD is universal donor. | 16:06.10 |
| henrys | actually they want MPL I'd like something with more mind share that doesn't need to be explained. | 16:06.47 |
| sebras | maybe pdf.js-people can share something else that you'd benefit from -- testfiles or whatever..? | 16:09.28 |
| chrisl | Money? ;-) | 16:09.43 |
| sebras | chrisl: do they have any? ;) | 16:10.02 |
| chrisl | Good point..... | 16:10.30 |
| Robin_Watts | They get their money in the form of a grant from google in exchange for having google as their default search provider/homepage. | 16:10.38 |
| sebras | however, once pdf.js is mature and working well in browsers in phones and other devices where firefox/whatever-it-will-be-renamed-to-next is bundled then mupdf might have a smaller market I guess. | 16:11.35 |
| miha | as user i see no other good default search provider than google anyway. bing i don't like and rest are no alternative... | 16:12.07 |
| henrys | sebras:yes but that will happen whether we give them jbig2dec or not. | 16:13.25 |
| sebras | henrys: I know. I guess it's a matter of whether you want to accelerate this or not. | 16:14.15 |
| | don't get me wrong, I don't particularly like everything being re-implemented in js, but I see it happening often nowadays. it even annoys me a little. :) | 16:15.05 |
| henrys | sebras:yes tor8 should be tasked with doing mupdf in js ;-) | 16:20.21 |
| Robin_Watts | Would it save him from having to write a viewer? | 16:20.46 |
| henrys | Robin_Watts:I guess the browser would be the viewer right? | 16:21.11 |
| sebras | henrys: he will kill me for this. :) | 16:21.33 |
| Robin_Watts | Depends on what sort of page display you want. 1up, 2up etc. | 16:21.50 |
| henrys | we should have played a joke on him at an in person meeting - all agreed and serious about him doing mupdf in js. | 16:23.10 |
| sebras | henrys: well, he's logged out so if you just clean up the irclogs you still have a chance to do so. ;) | 16:24.04 |
| henrys | I wouldn't be able to keep a straight face. | 16:24.33 |
| sebras | drives home, see you later. | 16:25.20 |
| chrisl | Well, I can "compile" Ghostscript into JavaScript, but it doesn't run...... | 16:39.31 |
| henrys | wow you actually tried it? | 16:41.44 |
| | what does the js look like? | 16:42.00 |
| chrisl | BIG, comes out at 107Mb, for a fairly cut down build. And even running "-h" was a no go..... | 16:43.04 |
| | Oh, there are actually recognisable GS function names in the js output - but it's largely incomprehensible to me...... | 16:45.40 |
| henrys | we need not think zero-sum game either, it could be js pdf will improve the pdf web ecosystem, that can only be good for us. | 16:45.47 |
| chrisl | Past experience says more PDFs means more people printing PDFs....... | 16:47.04 |
| mvrhel_laptop | I have to think there will still be a market for native code implementations | 16:47.45 |
| chrisl | Well, medium/high quality proofing will never fly with a js implementation, I reckon | 16:48.57 |
| Robin_Watts | So it won't affect gs, but might affect mupdf. | 16:49.42 |
| henrys | I'm imagining what comes out of emscripten is something like an intermediate code - what the dragon book calls 3 address instruction codes. | 16:50.46 |
| chrisl | henrys: I can't comment, as I really don't know js at all - but it doesn't look "nice"..... | 16:52.37 |
| | Holy crap! If I leave out the threading stuff, GS emits our "-h" message compiled into JS - that's stunning! | 16:58.58 |
| | It's very unhappy rendering anything, though - no big shock, there! | 17:01.01 |
| henrys | I'm sort of wondering why it wouldn't just work ... but very slowly. It is just assembler in javascript. | 17:06.14 |
| Robin_Watts | henrys: depends on the OS calls we make, I suspect. | 17:07.11 |
| | but I guess we'd expect that to be caught at compile time. | 17:07.36 |
| chrisl | I suspect it's more just a case of the rendering code is one of the bigger challenges in generating code, so more likely to trip up a converter | 17:08.08 |
| | Robin_Watts: does mupdf have an equivalent of gs's "AUXCC"? | 17:09.43 |
| Robin_Watts | Urm... HOSTCC maybe? | 17:10.02 |
| chrisl | Don't see it.... | 17:10.27 |
| Robin_Watts | look at the cmapdump lines. | 17:10.40 |
| henrys | it's not converting from C it goes to llvm bitcode than to js so the rendering code shouldn't be any different than any other code. | 17:10.53 |
| Robin_Watts | henrys: So you're saying it's essentially an interpreter for llvm intermediate format code. | 17:11.41 |
| henrys | that's what it says on the page. | 17:12.03 |
| Robin_Watts | chrisl: Ah, right. See the 'CROSSCOMPILE' definition. | 17:13.01 |
| | If that's defined, then we assume that the generate stage has been done already, and we don't bother doing cmapdump/fontdump/cquote | 17:13.36 |
| chrisl | Robin_Watts: thanks, I'll need to pick this up tomorrow, I have to go out.... | 17:13.42 |
| Robin_Watts | "need" :) | 17:13.51 |
| chrisl | Assuming I bother, I'll need to...... | 17:14.41 |
| henrys | kens:marcos said he'd handle elizabeth so I assume that still holds. | 17:16.11 |
| | oh right kens left for the logs then | 17:16.38 |
| | bbiab | 17:16.48 |
| henrys | can't imagine some register transfer language in javascript being worth a damn for anything but it seems to be getting use. | 17:19.39 |
| chrisl | Anyway, enough fun for now - off out....... | 17:24.36 |
| mvrhel_laptop | so henrys, I was thinking that we could get some use out of gemma for testing by having them try to use my recent commit with -dSimulateOverprint with the tiff32nc device | 17:27.35 |
| | I mentioned this to marcosw last night. he was going to ping her about this | 17:28.05 |
| | that would help their performance I would think | 17:28.18 |
| | if they are just after the blended output and don't need the separations | 17:28.37 |
| henrys | mvrhel_laptop:marcosw said he'd followup I wasn't sure if he's back to regular work. | 17:45.28 |
| | mvrhel_laptop:that was a question, is marcosw going to followup or should I? | 17:54.21 |
| | sorry I wasn't being clear. | 17:54.40 |
| mvrhel_laptop | henrys: I believe marcosw was going to do this | 17:55.20 |
| | bbiaw | 18:00.20 |
| sebras | what's the p in pdf_dict_getp()? | 18:57.26 |
| | and don't answer portable... | 18:57.35 |
| Robin_Watts | path | 18:57.38 |
| | Root/Info/Blah etc | 18:57.49 |
| sebras | ah... | 18:58.06 |
| | Robin_Watts: I stumbled over a pdf that fails in pdf_load_annots | 19:00.48 |
| | due to a missing apperance dict which is re-introduced in load_or_create_form() as an empty dict. | 19:01.08 |
| | later get_font_info() complains since it can not find a font name.... | 19:01.28 |
| | https://bugs.freedesktop.org/show_bug.cgi?id=14433 the attached pdf. | 19:02.25 |
| kens | henrys is Elizabeth the AIX performance problem ? | 19:29.37 |
| | mvrhel : ping ? | 19:29.46 |
| | <tumbleweeds....> | 19:30.15 |
| henrys | kens:yes | 19:42.39 |
| | kens: marcosw is back so our support duty is done. | 19:43.30 |
| kens | excellent, thanks henrys | 19:45.57 |
| sebras | paulgardiner: are you here? | 21:01.34 |
| Ch3rryC0ke | Robin_Watts: Are you there? Can I ask you for some help on getting mupdf to compile for ARM in Visual Studio? | 21:38.48 |
| | I've been able to get libthirdparty compiling, but now I'm running into an issue with the dependency on the "generated" project. | 21:39.15 |
| | Basically visual studio gives me an error when trying to run generate.bat | 21:49.27 |
| sebras | paulgardiner: Robin_Watts sebras/master has a patch for the forms-stuff: basically we need to always query the inheritance hierarcy for the DA field and we didn't, so we file depending on AcroForm's DA attribute would fail. | 22:01.37 |
| | paulgardiner: Robin_Watts the url I mentioned earlier links to an example exhibiting the issue. | 22:05.00 |
| paulgardiner | sebras: yes, thanks. That should fix it. | 22:08.02 |
| sebras | paulgardiner: np. | 22:08.21 |
| mvrhel | sorry I missed you kens | 23:09.18 |
| henrys | chrisl_away:oh of course you are right about the gl/2 coordinates. I wasn't thinking straight. | 23:14.02 |
| | Forward 1 day (to 2012/10/25)>>> | |
IRC Logs