| | <<<Back 1 day (to 2018/02/12) | 20180213 |
| hil | Hi. Is there a way to remember last position when reopening a pdf? | 00:05.04 |
| sebras | hil: in what version of mupdf? for android? | 00:09.58 |
| | hil: for mupdf-x11 and mupdf-gl we do not. and as far as I know mupdf-win32 is the same. | 00:10.35 |
| | mupdf for iOS I know little about. | 00:10.49 |
| | hil: doesn't look like we do it for android either. | 00:14.21 |
| hil | sebras: sorry. mupdf-x11 | 00:14.24 |
| | too bad. I was really hoping that wouldn't be the case but thanks sebras | 00:14.47 |
| sebras | hil: though... | 00:14.54 |
| | hil: I have seen this one: https://github.com/mrkkrp/mupdf-page | 00:14.59 |
| | hil: I have no idea how well that works. | 00:15.06 |
| | tor8 Robin_Watts (for the logs): another fuzzing fix on sebras/master | 01:43.50 |
| | it clusters well. | 02:03.00 |
| | Robin_Watts: there's a sweet commit on sebras/master that is yearning for a review. :) | 11:53.00 |
| tor8 | sebras: looks reasonable enough. | 12:02.07 |
| sebras | tor8: ta. | 12:03.26 |
| tor8 | sebras: the bug for "Bug 698991: If there is no document there are no objects." is fixed elsewhere already, so you can remove that commit | 12:04.48 |
| sebras | tor8: ok, I think I saw your change, but I forgot to remove mine. | 12:05.12 |
| tor8 | sebras: Robin_Watts: one fix on tor/master | 12:14.52 |
| kundan | Help | 12:20.05 |
| sebras | kundan: have you read the resources we supplied you with last time? | 12:20.39 |
| kundan | yes but i am not able to add bitmap over pdf | 12:21.20 |
| Robin_Watts | kundan: Everything I said last time still applies. | 12:25.56 |
| | We give no guarantee of support for MuPDF, unless you're a commercial customer. | 12:26.28 |
| kundan | okey no issue | 12:27.11 |
| sebras | kundan: if you become a paying customer we would of course help you, but at the moment we are tied up in other work, so we can't really spend time helping you. | 12:27.20 |
| Robin_Watts | If you want us to even consider helping you, then we need a clear statement of what you are trying to do, what you've tried so far, where you get stuck, etc. Without that we won't even start to think about your problem, cos we just don't have time. | 12:28.34 |
| | Basically, the more you can narrow down the problem, the less work it will be for us, and the more chance that we might be able to find the time to help. | 12:29.26 |
| | tor8: OK, I guess. Does that solve Codys problem? | 12:30.23 |
| | The only qualm I have is whether we think that will upset the existing users of pdf_add_image - do they rely on the copies in the cached document resource dict being direct? | 12:31.33 |
| tor8 | Robin_Watts: it was a bug I probably introduced when fixing another one--where I made the pdf_is_stream require an indirect object | 12:43.21 |
| Robin_Watts | tor8: right. | 12:43.37 |
| tor8 | there's no reason for preload_image to call pdf_load_object rather than go via an indirect object | 12:43.41 |
| | referring to stream objects via the indirect reference is always better and more robust | 12:43.59 |
| Robin_Watts | well, the fact that we have to malloc a new indirected thing is a shame, but I can live with that. | 12:44.06 |
| tor8 | Robin_Watts: yeah. I have considered making pdf_new_indirect use 'singleton'/unique objects so we never make more than one for each combination of document+number | 12:44.52 |
| Robin_Watts | the worry I had is whether we ever rely on loading a direct copy into the resource dict, and then being able to change the object without it affecting the cached one. | 12:45.03 |
| tor8 | pdf_add_image always returns an indirect reference | 12:45.21 |
| Robin_Watts | tor8: I can't see that we're ever creating a plethora of them. | 12:45.28 |
| | so I think your solution is good. | 12:45.38 |
| tor8 | Cody's problem was newbie programming mistakes--passing the wrong things to the correct function. | 12:46.12 |
| Robin_Watts | tor8: In his cut down program, possibly. | 12:46.44 |
| tor8 | he was passing a char* to the pdf_obj* key argument, and passing the fz_image as the value (rather than the object returned by pdf_add_image) in pdf_dict_put | 12:46.48 |
| Robin_Watts | The actual problem in his original code sounds much more like what you've just fixed here. | 12:47.13 |
| tor8 | Robin_Watts: this was in his copy of the filter-processor doing the image filtering | 12:47.16 |
| | but it could well be that what I fixed here fixes his main problem. I'll notify him and point him to my commit. | 12:47.36 |
| Robin_Watts | tor8: Fab. | 12:47.42 |
| tor8 | ah, god damn it! I keep forgetting 'reply all' | 12:49.00 |
| | Robin_Watts: jni/js bindings to layer device api on tor/master | 13:38.37 |
| Robin_Watts | tor8: Cool. | 13:42.33 |
| | Are you going to roll that in with my commit? | 13:42.41 |
| | lgtm. | 13:42.52 |
| tor8 | Robin_Watts: I should roll in the bug fix at least, but could keep the actual bindings separate. | 13:44.39 |
| | what say you? | 13:44.42 |
| Robin_Watts | tor8: Whatever you prefer. | 14:23.13 |
| kundan | can you please any help me.if i want to add t text on the position of signature then how can i do it | 14:34.57 |
| sebras | 5 line fix on sebras/master | 15:24.49 |
| | clusters well. | 15:24.58 |
| malc_ | tor8: have you seen my "for the logs" message here or was it in vain? | 15:27.25 |
| tor8 | malc_: argh! | 15:29.49 |
| malc_ | scratches his head, assumes - no | 15:30.17 |
| tor8 | I missed it, and now that I read it ... same reaction. | 15:30.45 |
| sebras | malc_: yeah, and I ought to have caught that yesterday when I checked the patch. | 15:30.47 |
| malc_ | C is wonderful like that | 15:31.16 |
| tor8 | sebras: malc_: fix for that on tor/master | 15:31.29 |
| malc_ | sebras: caught, caught how? | 15:31.34 |
| tor8 | I'm sure that will make visual studio gripe about signed/unsigned conversions though... | 15:31.54 |
| sebras | tor8: yeah, the return in pdf_document_permissions() would likely cause warnings. | 15:32.42 |
| | malc_: I read through tor8's patch the other day and I didn't notice that the value was > 2G | 15:33.10 |
| malc_ | sebras: ah, i envy you, living in a beautiful world where ints are strictly 32 bits... | 15:34.03 |
| sebras | malc_: bignums are nice, I like those. | 15:34.41 |
| malc_ | sebras: yeah | 15:35.47 |
| | Prelude> :t 1 | 15:35.49 |
| | 1 :: Num p => p | 15:35.49 |
| | Prelude> :t 0xfffffffc | 15:35.49 |
| | 0xfffffffc :: Num p => p | 15:35.52 |
| | | 15:35.55 |
| sebras | Robin_Watts: do you have time to have a look at sebras/master? | 16:16.36 |
| Robin_Watts | sure. | 16:17.01 |
| sebras | I'm trying to get my sebras/wip smaller, so I'm picking of a few patches at a time and preparing them as well as I can before asking for review. | 16:17.06 |
| Robin_Watts | sebras: 1 of 3 looks good. | 16:20.18 |
| sebras | Robin_Watts: 3!? you should probably refetch origin/golden and sebras | 16:20.47 |
| Robin_Watts | How many am I supposed to be looking at? | 16:22.42 |
| | The second one (orig = node) worries me. | 16:23.25 |
| sebras | Robin_Watts: 2 | 16:23.26 |
| Robin_Watts | (the first one in time order) | 16:23.43 |
| sebras | Robin_Watts: "Bug 699018: Null terminate buffer in fz_snprintf() even if too short." is already on origin/master | 16:23.48 |
| | "Avoid revisiting the same page tree node repeatedly." is the one you are worried about | 16:23.57 |
| | and "Bug 698901: Drop pixmaps/knockout group upon error when ending group." | 16:24.05 |
| Robin_Watts | Suppose I have a tree that is [ [<page 1> <page 2>] [<page 3> <page4>] ] | 16:26.44 |
| | and i'm looking for page 4. | 16:26.57 |
| sebras | Robin_Watts: the idea is that if we look at a page tree node and conclude that node of its Kids contain the page we're looking for, there is no need to revisit the node again only to discover that it was marked a few seconds ago. | 16:26.59 |
| moimeme | Hi | 16:29.08 |
| mubot | Welcome to #mupdf, the channel for 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. | 16:29.08 |
| moimeme | Do you know how can I check if a file is a valid PDF file using MuPdf ? I managed to make MuPdf process Pdf Files, but if I rename an executable to .exe.pdf, the application stops because in error.c there is exit(EXIT_FAILURE); | 16:30.23 |
| kens | Welll, if MuPDF won't read it, its not a valid PDF, isn't that good enough ? | 16:30.58 |
| moimeme | Can I check if the file is a Valid Pdf file before processing it ? Or there is a way to make silent exceptions from mupdf instead of exit ? | 16:31.08 |
| kens | Of course, it might be a valid file of a different type | 16:31.15 |
| Robin_Watts | moimeme: If you call MuPDF as a library, yes. | 16:31.34 |
| kens | There's no way to check if a PDF file is entirely valid without interpreting the entire file. | 16:31.41 |
| Robin_Watts | If you call it as an executable, no. | 16:31.43 |
| moimeme | yes I call it as a library, from a .net app | 16:31.49 |
| Robin_Watts | moimeme: I can't help you with .net | 16:32.04 |
| sebras | moimeme: is this your own app? | 16:32.21 |
| Robin_Watts | But from C, if you do fz_open_document etc, then nothing will ever call exit(EXIT_FAILURE) | 16:32.25 |
| moimeme | I can manage the .net part | 16:32.29 |
| | yes | 16:32.29 |
| sebras | moimeme: is it open source? | 16:32.47 |
| moimeme | in pdf_open_document_with_stream | 16:33.00 |
| | you have | 16:33.02 |
| | pdf_init_document | 16:33.07 |
| | in it, it can throw an exception and then exit | 16:33.22 |
| | error.c line 122 | 16:33.32 |
| Robin_Watts | moimeme: It only exits if you haven't wrapped the call in an fz_try. | 16:33.39 |
| | When we hit errors, we throw exceptions. | 16:34.09 |
| | If you are set up to handle exceptions, then great. | 16:34.19 |
| | If you aren't, then throwing the exception would crash. | 16:34.27 |
| moimeme | hmm, thanks Robin, let me check this | 16:34.37 |
| Robin_Watts | So we don't throw the exception, we print an error and exit. | 16:34.40 |
| moimeme | ( Sebras, it's not open source, not commercial too, it's an app it helps me generate preview for files for my Data mining personnal project ) | 16:35.31 |
| sebras | moimeme: be sure to not give the app to anyone else, otherwise you are in a license pickle. | 16:36.45 |
| Robin_Watts | sebras: OK, so... can we lose orig entirely, and change the while to be while (i != len) | 16:37.02 |
| | sebras: I can't see a formulation that I actually think is clear :( | 16:39.10 |
| moimeme | ok sebras, thank you all, and thanks for this great library | 16:39.59 |
| sebras | Robin_Watts: I fail to see how your example about page 4 would cause a problem..? | 16:41.00 |
| | Robin_Watts: but I agree that while (i != len) would work as a replacement for orig != node | 16:41.17 |
| Robin_Watts | sebras: Yeah, ignore my example. | 16:41.18 |
| | i != len also removes hit == NULL | 16:41.46 |
| sebras | Robin_Watts: I tested with pdfref17.pdf which has a huge page tree and it fetches page indicies 0..N-1 correctly. | 16:41.49 |
| | Robin_Watts: mm, I'm looking at that part right now. | 16:42.32 |
| | ok, so we only set hit if i < len seems reasonable to me. | 16:43.00 |
| | Robin_Watts: so perhaps while (i < len)? | 16:43.21 |
| Robin_Watts | I could live with that. | 16:44.58 |
| | The second commit lgtm. | 16:45.04 |
| | I could live with either if you could convince me it was clearer :/ | 16:45.19 |
| sebras | Robin_Watts: I can't really, other than if i >= len then we have exhausted the Kids array without finding the page we were looking for. | 16:48.59 |
| Robin_Watts | sebras: Possibly what I'm looking for is: /* If i == len, then we have exhausted the Kids array without finding the page we were looking for. */ } while (i < len); | 16:49.54 |
| sebras | and if i <len then we have found either a page tree node that we need to look into, or found the page itself | 16:49.55 |
| Robin_Watts | i.e. just a comment before the while might be enough to assuage my tiny brain. | 16:50.23 |
| | This is not a criticism of your code at all, just noting that encroaching senility is making the existing code harder to understand than I'd like. | 16:51.07 |
| sebras | Robin_Watts: no worries. :) | 16:51.36 |
| | Robin_Watts: we can't do away with hit == NULL though. | 16:53.05 |
| | Robin_Watts: because then we'd revisit the page tree node if it indeed contains the page we're looking for. | 16:55.03 |
| Robin_Watts | Right. | 16:57.19 |
| sebras | Robin_Watts: new version on sebras/master | 17:07.26 |
| Robin_Watts | tor8 will complain about the lack of capitalisation, but yes, that looks good to me. | 17:12.48 |
| sebras | Robin_Watts: fixed. what about the top commit? | 17:16.30 |
| Robin_Watts | lgtm. | 17:17.05 |
| malc_ | sebras: https://blog.regehr.org/archives/1559 | 18:42.58 |
| | Forward 1 day (to 2018/02/14)>>> | |
Log of #mupdf at irc.freenode.net.