| | <<<Back 1 day (to 2016/07/05) | 20160706 |
| sebras | tor8 (for the logs): besides the three commits you have already imported to tor/master there are another five commits on sebras/master. | 04:03.43 |
| | tor8: the trivial java Makefile typo, exposing LAB colorspaces (so they can be used in JPX-decoding) | 04:04.07 |
| | tor8: luratech jpx decoder support | 04:04.17 |
| | tor8: optinal of course, as ia the jpeg-xr support. | 04:04.38 |
| | tor8: and finally support for pbm/pgm/ppm/pam. | 04:04.55 |
| | tor8: I ran them through clusterpush and as far as I know there are only progressions. I reported a number of luratech JPX related bugs in bugzilla however. | 04:05.53 |
| | Robin_Watts: if you also want to take a quick look I'm happy to sort out any issues either of you may identify. | 04:06.20 |
| juexing | hello | 12:07.26 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:07.26 |
| juexing | EXCEPTIONALLYU,Are you there? | 12:09.07 |
| Robin_Watts | juexing: Hi. | 12:14.22 |
| | You're after help with digital certificates, right? | 12:14.54 |
| | The engineer you need is paulgardiner, but he's not here at the moment. He's busy on other stuff. | 12:15.23 |
| juexing | ok,thanks | 12:16.22 |
| | I hope I'll come back next time, | 12:17.04 |
| | Can someone help me. Ha-ha | 12:17.04 |
| Robin_Watts | juexing: I think you will find us reluctant to help you until you can be clearer about what you want. | 12:20.14 |
| | AIUI, you have a project that does not currently use MuPDF. | 12:20.26 |
| | And you want to add digital signature functionality to that project. | 12:20.52 |
| | Either that means you're going to use MuPDF (in which case we need to sort out the license), or you're going to implement such code yourself. | 12:21.42 |
| | You've dismissed discussion of the license before, which leads me to believe that either you're going to use MuPDF and disregard the license issues, or you plan to implement code yourself, based on anything you can find within MuPDF. | 12:23.36 |
| | I cannot see any reason why we'd want to go out of our way to help you in either of those cases. | 12:24.08 |
| | If I have misunderstood the situation, please feel free to correct me. | 12:24.22 |
| Robin_Watts | foods. | 12:25.38 |
| juexing | Pure technical problems, the use of mupdf can not call this function pfx. Would like to seek help | 12:31.37 |
| yaw | Hi | 12:59.28 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:59.28 |
| juexing | hi | 12:59.53 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:59.53 |
| yaw | Could someone tell me please if Mupdf make use of the Gpu or not ? | 12:59.54 |
| | would it be benefical for my server to have a good graphical card ? | 13:00.22 |
| tor8 | yaw: the mupdf library and renderer do not use the GPU. some of the viewers do, but only to show the rendered image on screen. | 13:00.39 |
| yaw | Ok thanks tor8, I don't know how the jpeg compression part takes of the total time, but there is a gpu accelerated jpeg library, it could be good to have an option to use it : https://github.com/hoopoe/gpujpeg , thanks anyway for your answer :) | 13:02.23 |
| juexing | hi,i have a problem | 13:02.32 |
| | void pdf_sign_signature(fz_context *ctx, pdf_document *doc, pdf_widget *widget, const char *sigfile, const char *password) | 13:02.45 |
| kens | juexing did you read what Robin_Watts wrote above ? | 13:02.52 |
| juexing | How to call this function? | 13:02.59 |
| | en,i see | 13:03.15 |
| Robin_Watts | yaw: We never compress jpeg. | 13:04.47 |
| | We *decompress* JPEGs, but that's all. | 13:05.09 |
| | Generally jpeg decompression is not a huge proportion of runtime (though, this obviously varies according to the PDF file in use). | 13:05.44 |
| | Certainly, it should be possible to drop a different jpeg lib into MuPDF. | 13:06.08 |
| | We won't make it a requirement of the core though, cos MuPDF runs in many places where there is no GPU. | 13:06.37 |
| | yaw: If you want to submit a patch that enables MuPDF to use that library, then we'd probably consider it. | 13:07.48 |
| yaw | Robin_Watts: Ok, I'll do some benchmarking and if there is a significant perf gain I'll do a pull request | 13:10.26 |
| Robin_Watts | yaw: OK. I'd be tempted to just profile mutool draw for a bit on your files. | 13:11.13 |
| | If the jpeg decompression doesn't show up heavily in those profiles, then clearly optimising it isn't going to help much. | 13:11.39 |
| | (i.e. if jpeg decompression accounts for say 10% of runtime, then even if you speed it up 1 million times, you'll only ever get a 10% boost) | 13:12.12 |
| tor8 | Robin_Watts: a long list of commits on tor/master for review | 13:15.30 |
| yaw | yes of course, I don't have yet files, I'm planning to launch a product for Electronic Document Management, Customers can scan any document ( with any resolution ) and import it in the app, I'm benchmarking several pdf libraries and Mupdf shows to be the best of them, I'll profile it on some general scanned documents to see how much the jpeg decompression takes, if there is a way to improve it it would be a pleasure to help the pro | 13:17.02 |
| | licensing questions but that would be in another threads | 13:17.16 |
| Robin_Watts | tor8: Do I need to review the sebras commits? | 13:17.58 |
| | yaw: Cool. let us know if we can help. | 13:18.23 |
| tor8 | Robin_Watts: no, I have looked those over. | 13:18.31 |
| | a second pair of eyes on them wouldn't hurt, but they're looking good to me and pass cluster tests | 13:19.07 |
| Robin_Watts | It's a shame sebras didn't copy the API comments in his fz_device_lab commit. | 13:19.31 |
| | OK, everything up to the end of sebras stuff seems plausible. | 13:21.47 |
| | The buffer overrun fix does indeed fix a buffer overrun. It might be nicer to move to a malloced block rather than a staticly sized one to avoid dropping annotations? | 13:22.27 |
| tor8 | Yes, it probably would. | 13:24.42 |
| Robin_Watts | tor8: In the flatten inheritable one... | 13:24.54 |
| | You flatten mediabox and cropbox, but not artbox or bleedbox etc. | 13:25.20 |
| tor8 | Robin_Watts: correct. according to the specification, there's a limited subset of properties that should be inheritable. | 13:25.46 |
| | and the other boxes aren't | 13:25.50 |
| Robin_Watts | OK, good answer :) | 13:25.56 |
| tor8 | stupid inconsistencies... | 13:25.56 |
| Robin_Watts | part of me is worried about making pdfclean alter the document in that way by default. | 13:26.43 |
| | I could imagine that I'd pdfclean a document to decompress it, and suddenly the decompressed version wouldn't show the problem I was hunting for any more, because of this flattening. | 13:27.11 |
| tor8 | Robin_Watts: it was potentially creating broken files otherwise | 13:27.23 |
| Robin_Watts | ok. | 13:27.32 |
| | Fair enough then. | 13:27.40 |
| tor8 | since the page tree is recreated, the inherited properties would not be copied over | 13:27.49 |
| | since we reset the /Parent chain that it would follow | 13:28.01 |
| | this only happens when subsetting pages | 13:28.11 |
| Robin_Watts | Drop generation number from public interfaces - excellent one! | 13:28.33 |
| tor8 | took a while to get it right, and I had to bloat the pdf_xref_entry slot with one more entry | 13:29.05 |
| | but I love the results! | 13:29.08 |
| Robin_Watts | tor8: It would be nice if the commit messages for things like "Fix garbage collection and page grafting for indirect reference chains." said a bit more. | 13:32.03 |
| | I can imagine us hitting a case in a years time where this is causing problems, and not having a clue why it was changed. | 13:32.34 |
| | A reference to a file/command line that was broken would be enough to at least verify that any subsequent fix was correct. | 13:33.08 |
| | otherwise we end up flip flopping back and forth over breaking different things. | 13:33.31 |
| | likewise to the end commit message. | 13:33.48 |
| | s/end/next/ | 13:33.54 |
| tor8 | Right. I'll write a more thorough explanation in the commit message. | 13:34.01 |
| Robin_Watts | In the "Add fitz to pdf downcasting functions for pages and annotations." we should be adding new API comments. | 13:37.34 |
| | (I'm as guilty as anyone for not adding them when I should. We should try to have all public API methods commented really). | 13:38.04 |
| | In the "Start slimming pdf_page." you add fz_transition *transition to fz_page_presentation and don't update the API comment. | 13:39.06 |
| | Pickling the page_ctm into an annot is bad. | 13:40.04 |
| | Maybe. | 13:40.25 |
| | suppose I have 2 threads accessing the same annot at the same time. | 13:40.38 |
| | hmm. maybe that's not allowed. | 13:40.47 |
| tor8 | Robin_Watts: the annot code uses a lot of transforming back and forth between fitz' page space and pdf user space | 13:40.54 |
| | the page_ctm in the annot is read only once created | 13:41.09 |
| | I am planning on revising the annotation code to make them thin as well, which could possibly drop the pickled page_ctm and inv_page_ctm | 13:41.34 |
| Robin_Watts | tor8: So, different threads using the fz_annots wouldn't conflict ? | 13:42.16 |
| | (notwithstanding the fact that maybe we can't ever safely have different threads using the annots). | 13:42.38 |
| tor8 | Robin_Watts: not in terms of the page_ctm, no | 13:43.33 |
| | that's set when loading the annot | 13:43.40 |
| Robin_Watts | ok. | 13:43.43 |
| | We are relying on being able to invert the page_ctm when we weren't before though, right? | 13:46.24 |
| | In pdf_page_transform, if cropbox is unset, it ends up empty? | 13:48.38 |
| tor8 | Robin_Watts: we were inverting in various annotation functions before. the page_ctm is always safe to invert. | 13:49.35 |
| Robin_Watts | tor8: ok, i haven't seen that on my voyages yet, will keep looking. | 13:49.57 |
| | ah, I see it. | 13:50.47 |
| | Yeah, that commit looks good too, other than my query about cropbox. | 13:51.02 |
| | ok, that's everything up the last WIP commit. | 13:51.36 |
| tor8 | Robin_Watts: yes. it (ugly) relies on pdf_to_rect having everything to default to NULL and 0 | 13:51.49 |
| | so it ends up with an empty rect | 13:51.55 |
| Robin_Watts | tor8: Right, but in the case where it's unspecified, shouldn't it be mediabox? | 13:52.25 |
| | (and arguably unspecified should be different to specified to be empty) | 13:52.47 |
| tor8 | if cropbox is set, we use it to intersect the mediabox we return | 13:52.59 |
| | if it's unset, we don't modify mediabox | 13:53.10 |
| Robin_Watts | right, but cropbox remains unset. Ah, it's a local thing that's not used afterwards. | 13:56.12 |
| | OK, sorry, got it. lgtm. | 13:56.17 |
| tor8 | thanks! | 13:56.25 |
| | it does cause a bunch of clusterpush differences due to the matrix calculations being done slightly differently | 13:56.47 |
| | but I think I fixed a bug doing that too! | 13:56.53 |
| | with how userunits were being handled | 13:57.08 |
| | fortunately I haven't seen any real files use UserUnit... only one file in all our cluster tests | 13:57.27 |
| | the diffs are down to rounding differences with floating point math | 13:58.27 |
| sebras | typhoon passing Taipei thu/fri so if you don't hear from me it's because I've lost connectivity. but I'm on the 9th floor so I guess I won' | 14:13.27 |
| | t be flooded at least! :) | 14:13.36 |
| rayjj | sebras: I hope you have food and water to last a few days (just in case) | 14:15.39 |
| sebras | seems like it will pass rather quickly. | 14:15.56 |
| | but I should probably go out and buy some more food. hm... | 14:16.11 |
| rayjj | sebras: I meant in case it floods. | 14:16.12 |
| | shops usually have much of their inventory at near ground level | 14:16.38 |
| | (or below) | 14:16.43 |
| sebras | rayjj: you're right. | 14:17.01 |
| rayjj | I should talk -- we live in an earthquake area and I don't have much of an earthquake kit. :-/ | 14:18.17 |
| sebras | rayjj: I don't remember where in the US live. California? | 14:20.12 |
| Robin_Watts | rayjj: You need an "in case of emergency" box full of balaclavas and baseball bats for looting. | 14:20.21 |
| sebras | Robin_Watts: so rayjj lives in detroit? ;) | 14:20.44 |
| Robin_Watts | sebras: LA. | 14:20.48 |
| sebras | Robin_Watts: aha! | 14:21.07 |
| kens | I have a friend who has lived in LA for some years, when I visited they were very careful to show me where the spare room torch was and instuct me in what to do in case of an earthquake. Fortunately there weren't any while I was there | 14:21.28 |
| Robin_Watts | A guy I (and jogux and pete) know moved out to SF. | 14:24.11 |
| rayjj | kens: I usually don't need a torch at night, but that is (except for full moon) due to light pollution. An earthquake that knocked out power would severely reduce light pollution | 14:24.26 |
| | (only the few random fires to light the sky) | 14:24.44 |
| Robin_Watts | In the first noticable tremor, he woke up and was running around the flat checking everything. | 14:24.52 |
| | The rest of the people in the building were like "meh". | 14:25.05 |
| rayjj | I've been here since '76 and I've only been in one or two where anything fell over -- stuff standing or leaning up in shelves and cabinets | 14:27.03 |
| | so I've definitely become jaded | 14:27.35 |
| | Robin_Watts: I replied yesterday (after a long while) to you comments on the patches. Are you OK with them "as-is" ? | 14:28.24 |
| Robin_Watts | Yes. | 14:29.14 |
| | Sorry, should have explicitly replied. | 14:29.37 |
| rayjj | Robin_Watts: OK. Thanks. It's a trade off for performance vs. nicer looking code. I don't have the same objection to variable assignment in a conditional: if ((code = ...) < 0) is my favorite, but in complex conditionals it isn't as nice | 14:31.11 |
| | wow --haven't seen 36 regression jobs pending for a while. The mupdf team must have taken a laxative | 14:36.58 |
| | I really don't know how you guys can work like that -- the chance of something you are doing overlapping an area someone else is working on seems too great | 14:38.32 |
| Robin_Watts | rayjj: lots of them are very small. | 14:39.20 |
| | and it's 18 commits, not 36 really. | 14:39.31 |
| | though, yes, there is that risk. | 14:39.54 |
| tor8 | rayjj: Robin_Watts: most of these commits have been sitting on our public personal repos for a while | 14:40.23 |
| rayjj | "Start slimming the pdf_page" affects quite a few files | 14:40.29 |
| Robin_Watts | rayjj: Yes, some of them are large. | 14:40.38 |
| tor8 | rayjj: matrix math rounding differences. | 14:40.45 |
| Robin_Watts | tor8: rayjj has a point that we should try to push more often though. | 14:40.59 |
| tor8 | Robin_Watts: I don't want to interrupt you too often :) | 14:41.17 |
| rayjj | and that one reminds me of "Change ... (part 1 of 12)" which is why I noticed that one | 14:41.33 |
| | hopefully none of these are changes that are intentionally deferred by conditional compile. | 14:42.37 |
| | tor8: why should you be the only one that respects Robin's ability to concentrate ;-) | 14:43.24 |
| Robin_Watts | rayjj: No igorisms here. | 14:43.55 |
| | I am thrilled that I am managing to convince anyone that I can concentrate :) | 14:44.36 |
| rayjj | Robin_Watts: in this group, I suspect that "concentration" is a few sigmas out of the general population norm | 14:55.37 |
| | finally got to my commits :-) | 17:05.47 |
| | 2.5 hours later :-( | 17:06.04 |
| sebras | rayjj: sorry. maybe I should make bigger commits for mupdf. :) | 17:07.44 |
| | rayjj: but tor8 also contributed. | 17:07.53 |
| HenryStiles | sebras: I did push back on luratech looking at segfaults and they agreed | 17:14.34 |
| sebras_ | HenryStiles: ok. so the initially didn't want to look at the report? | 17:24.45 |
| Robin_Watts | sebras: You just need to be pushier about getting your stuff reviewed :) | 17:24.53 |
| sebras_ | Robin_Watts: why? how so? | 17:25.08 |
| Robin_Watts | sebras_: Hassle us more to review stuff. | 17:25.23 |
| sebras_ | Robin_Watts: with Henrys? or with you? /me is confused. :) | 17:25.24 |
| | Robin_Watts: I mainly try to direct review requests to tor8 because you are mainly (supposed?) to look at SO. | 17:26.28 |
| Robin_Watts | sebras_: Sorry. To avoid there being huge batches of commits going in at once, we should try not to sit on lots of commits in our own repos for ages. | 17:26.43 |
| sebras_ | Robin_Watts: ah. now I got the context. | 17:27.01 |
| Robin_Watts | sebras_: I'm on both MuPDF and SO (just SO this week), but that doesn't mean I can't spare time to review stuff. | 17:27.11 |
| sebras_ | Robin_Watts: ok. you may get a few requests during tor8s absence. | 17:27.36 |
| Robin_Watts | Of course. Likewise :) | 17:27.46 |
| sebras_ | Robin_Watts: the jpeg-xr stuff was sitting on an _old_ branch for quite some time because tor8 mentioned that he was worried about the stability of the jpeg-xr library. | 17:28.08 |
| Robin_Watts | HenryStiles: I have JPEG Tiffs working here. Just trying to get it through ATS now. | 17:28.11 |
| | sebras_: Yeah. | 17:28.25 |
| sebras_ | Robin_Watts: the jpx-stuff lead to a few random CBZ and PNM pieces, but the main thing I've been putting effort into is JPX though. | 17:28.59 |
| | Robin_Watts: but now that it's finished I'll look into the java bindings stuff. | 17:29.28 |
| | Robin_Watts: might be tricky, but tor8 reassured me that it probably isn't. let's see. :) | 17:29.53 |
| Robin_Watts | sebras_: It looks complex, but it's really not that bad. | 17:35.34 |
| sebras_ | jni is new to me, I guess that's all. but I did look at the java Document.countPages() vs muruns Document.countPages() vs fz_count_pages() and it seemed pretty straightforward. | 17:36.29 |
| Robin_Watts | sebras_: Yeah, the trick is in mapping from java objects to native objects, but that's fairly systematic now. | 17:37.30 |
| sebras_ | mmm, I haven't looked at something which is missing yet though. that's on the agenda for tomorrow I guess. | 17:38.29 |
| fredross-perry | Robin (or anyone) - handful of commits on my mupdf master for review, thanks. | 17:51.57 |
| Robin_Watts | fredross-perry: The 'hasRetinaDisplay' one is interesting. | 17:59.13 |
| fredross-perry | in that...? | 17:59.23 |
| | well, yes, it needs to be actually correct. | 17:59.43 |
| Robin_Watts | On Windows, there is a call you can make (in C or C# at least) that serves the purpose of a) actually getting the resolution, and b) telling the OS that you are respecting the resolution. | 18:00.11 |
| malc_` | Robin_Watts: resolution = dpi? | 18:00.35 |
| Robin_Watts | If you don't make the call, windows just scales all the paints up, and everything gets fantastic blurry vision. | 18:00.46 |
| | Yes. | 18:00.48 |
| fredross-perry | I forgot I left it in that state. | 18:01.23 |
| malc_` | Robin_Watts: are there many displays that provide that these days? apart from, well, "retina display"... | 18:01.28 |
| Robin_Watts | So, in this instance, a scale of 2 would be wrong (for my laptop it's 1.2 or thereabouts), and we'd still get blurriness. | 18:01.36 |
| | malc_`: Yes, many. Laptops especially. | 18:01.57 |
| | Windows theoretically copes with different monitors having different resolutions, but don't ask me how. | 18:02.24 |
| malc_` | Robin_Watts: all i see is increase in physical dimensions, that makes pixel resolution less impressive.. that's for standalone monitors ofcourse | 18:02.47 |
| Robin_Watts | fredross-perry: When you do commit messages like "Android viewer: add mupdf_native.c to build", it's best to leave a blank line in between paragraphs. | 18:03.20 |
| | otherwise some git tools run them together and it looks horrible. | 18:03.33 |
| | platform/android/example is your new viewer? | 18:05.26 |
| fredross-perry | i can reword them. | 18:05.59 |
| | platform/android/example is the new viewer | 18:07.03 |
| Robin_Watts | cool. Then everything looks good to me, apart from the retina display one. | 18:07.23 |
| fredross-perry | I'll see if I can drop that one and come back to it. | 18:07.43 |
| Robin_Watts | https://www.indiegogo.com/projects/101hero-the-world-s-most-afforable-3d-printer/ | 18:09.29 |
| fredross-perry | $99 !!! | 18:12.30 |
| Robin_Watts | Indeed. | 18:13.32 |
| | The $109 + shipping one is the one that was tempting me... | 18:14.00 |
| fredross-perry | I did a clusterpush of my mupdf changes, and got | 18:24.44 |
| | ran 2430 tests in 133 seconds on 24 nodes | 18:24.45 |
| | Differences in 1500 of 2430 non-pdfwrite/ps2write/xpswrite test(s): | 18:24.45 |
| | but I've done nothing to the core code, so I expect this is known? | 18:25.21 |
| Robin_Watts | fredross-perry: Are you up to date with the latest stuff? | 18:26.51 |
| fredross-perry | thought I was, I'll look again. | 18:27.04 |
| Robin_Watts | (i.e. git pull --rebase golden master, then a cluster push should come back clean) | 18:27.19 |
| | possibly if you tested earlier, the cluster hadn't finished checking all the commits. It should be OK now. | 18:27.37 |
| fredross-perry | no it was just moments ago. Trying again. But i think I was clean. | 18:29.03 |
| Robin_Watts | fredross-perry: Ah, no, you're fine. | 18:29.57 |
| | Look again at the cluster report. | 18:30.04 |
| | "Differences from trunk:" shows 1 difference. | 18:30.19 |
| | "Differences from previous clusterpush:" shows lots. | 18:30.31 |
| fredross-perry | oops. ok. | 18:30.42 |
| Robin_Watts | It's differences from trunk we care about. | 18:30.42 |
| fredross-perry | but what of the one diff? | 18:30.47 |
| Robin_Watts | It's an easy mistake. I make it all the time. | 18:30.53 |
| | broken_png_image is one that changes for the hell of it. | 18:31.03 |
| | so you're golden. | 18:31.07 |
| fredross-perry | ;-) | 18:31.19 |
| | pushed! | 18:31.37 |
| tor8 | fredross-perry: hate to be a nag, but there's mixed space and tab indentation in DocViewActivity.java | 19:10.58 |
| | most of the new files are all spaces, but AndroidDrawDevice is all tabs | 19:11.18 |
| | Robin_Watts: does android studio make it impossible to configure indentation settings to be consistent? | 19:12.40 |
| Robin_Watts | Not a clue, sorry. | 19:13.00 |
| tor8 | it seems to be a common theme with the android java sources... both now and back when paul was working on the android viewer. | 19:13.28 |
| | Forward 1 day (to 2016/07/07)>>> | |
IRC Logs