| | <<<Back 1 day (to 2018/02/05) | 20180206 |
| sebras | fredross-perry: I hope this commit makes sense to you and compiles correctly in ATS: http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=d8ea36e8091df4f504e6903557b76a996222e71b;hp=f5bb2fa8cd7dcef8bae35ac65fa5bb1394ae6d2f | 02:57.53 |
| fredross-perry | quick questeion - does it matter what order you include limits.h and stdint.h | 02:59.48 |
| sebras | fredross-perry: no, they should be defining different things. | 03:00.18 |
| | fredross-perry: that ought to be true for all POSIX headers. I know of now inclusion order restriction for POSIX headers. | 03:01.24 |
| fredross-perry | ok, i'll try it now. | 03:01.26 |
| sebras | s/now/no/ | 03:01.28 |
| | fredross-perry: I belive that with this we'll be able to compile atleast with NDKs >= r14 | 03:02.09 |
| | I'm still trying to figure out when android introduced the timegm() function that we seem to depend on nowadays. | 03:02.27 |
| fredross-perry | I can try a few. | 03:02.35 |
| sebras | fredross-perry: I put all the NDKs in a gigantic git repo yesterday so I can easily switch between NDK versions. | 03:03.20 |
| fredross-perry | One of the things ATS needs to do is to fetch the git submodule and do make generate, so in order to do a true ATS test, i'll need the commit pushed first. But I'll do a local build test to see that it does build minus that first. | 03:08.25 |
| sebras | fredross-perry: great, I still need it to pass the tor8-filter tomorrow. but at least I prepared the patch and motivated why it is neceesary. | 03:09.29 |
| | fredross-perry: perhaps a comment as to _why_ limits.h is included even though it doesn't seem necessary is in order. | 03:09.53 |
| | I might add that before tor8 reviews it, but I don't anticipate doing any non-cosmetic changes. I'll keep you posted on when it reaches master. | 03:10.39 |
| fredross-perry | ok thanks. | 03:10.55 |
| sebras | fredross-perry: I have a patch queue of 20 odd patches so I need his assistance tomorrow since r o b i n (whom I may not disturb) is unavailable at the moment. | 03:12.23 |
| fredross-perry | if this could get high priority then I can sinmit a big chunk of muso for review. | 03:13.41 |
| sebras | fredross-perry: I know, I'll see what I can do tomorrow. | 03:14.16 |
| fredross-perry | thank you. | 03:14.23 |
| | ok, I did a local build with ndk r14b, and it worked as advertised. | 03:26.12 |
| sebras | do you mind trying it out with r15 too? | 03:26.40 |
| | if it is easy. | 03:26.44 |
| fredross-perry | I have 15c on hand. | 03:36.03 |
| sebras | r16b works. | 03:40.20 |
| | fredross-perry: so there is a high likelihood that r15c will work for you too. | 03:41.22 |
| fredross-perry | swell. | 03:41.33 |
| | yes, 15c looks good too. | 03:41.44 |
| sebras | fredross-perry: I'm trying r13c now. I want to know what the oldest version we compiles cleanly under is. | 03:41.58 |
| fredross-perry | I have 10d and 8e | 03:42.27 |
| sebras | I know that 10e doesn't work. | 03:42.46 |
| fredross-perry | what's wrong with 10e? | 03:44.23 |
| sebras | timegm() is missing. | 03:44.29 |
| fredross-perry | ah. | 03:44.36 |
| sebras | we use it in source/pdf/pdf-annot-edit.c | 03:44.42 |
| | for the date/time support we added to annotations for you some time back. | 03:45.02 |
| fredross-perry | right | 03:45.13 |
| sebras | hm.. seems like r13c might work, but not for mips64 (I get a compilation error because crtbegin_so.o is missing). | 03:45.48 |
| fredross-perry | well, buiding with 10d works. | 03:47.40 |
| sebras | really?! ugh, I hate android. :-P | 03:48.26 |
| fredross-perry | indeed. | 03:48.32 |
| | is yur missing timegm() a runtime error, or a build error? | 03:50.04 |
| sebras | all the archs in r13c worked fine exception mips64. | 03:50.10 |
| fredross-perry | 'cause I'm only building. | 03:50.16 |
| sebras | fredross-perry: it was a link error. | 03:50.16 |
| fredross-perry | hm. | 03:50.20 |
| | maybe I should get 10e and try it. Also, I'm on OSX bu that should not be an issue, one would think | 03:50.53 |
| sebras | fredross-perry: both things might be reasons for why it may be different in your case. | 03:51.31 |
| fredross-perry | .1Gbyte download - stay tuned | 03:52.16 |
| | 1.0 Gb | 03:52.28 |
| | 10e is OK for me too | 04:10.10 |
| sebras | fredross-perry: I get a build error for mips due to pdf_parse_date() linking to timegm | 04:12.36 |
| | fredross-perry: perhaps you are not building for mips? | 04:12.47 |
| fredross-perry | i am not. Only armeabi-v7a | 04:13.16 |
| sebras | I see the same issue in r11c. | 04:14.19 |
| fredross-perry | trying mips with 10e now | 04:16.31 |
| | well, that worked too. | 04:18.51 |
| sebras | I get a link error with armeabi-v7a using r11c too. | 04:18.57 |
| fredross-perry | tell me which project you're building. | 04:19.22 |
| sebras | git://git.ghostscript.com/mupdf-android-fitz.git | 04:19.47 |
| | just using gradle. | 04:19.54 |
| fredross-perry | ok | 04:24.23 |
| | cloning ... | 04:24.31 |
| | so. much. setup. | 04:40.52 |
| | ok, intersting, possibly sad. I get the timegm link error now, wth mupdf-android-fitz and r10e. Question becomes, why not with MuSO? | 04:46.13 |
| sebras | fredross-perry: perhaps because you happen to link with some library that has timegm()..? | 04:47.02 |
| fredross-perry | probably. | 04:47.11 |
| | but that doesn't thrill me. | 04:47.20 |
| | but maybe I won't worry. | 04:50.25 |
| sebras | is there a requirement on what NDKs muso must build with exception r14b due to ATS? | 04:51.01 |
| | ok, so the symbol comes from platforms/android-16/arch-x86/usr/lib/libc.so | 04:53.29 |
| | and it is present in r12b, but missing in r11c | 04:53.38 |
| | fredross-perry: so the latest version that build entirely cleanly for all architectures for me is NDK r14b | 04:55.01 |
| | r13c fails to build mips64, possibly due to some issue in the NDK itself. | 04:55.25 |
| | r12b fails to build armeabi due to the compiler complaining about some ARM assembler in halftone.c (and possibly later also in draw-simple.c) | 04:56.00 |
| | r11c fails to build armeabi-v7a/mips/x86 due to timegm() missing, and also complains about the arm assembler | 04:56.30 |
| | the situation is identical for r10e and r9d | 04:56.43 |
| fredross-perry | ATS is using r14b, but might get bumped up in the future for some reason. Maybe we'll cross that bridge when it happens. Anyway, I am only interested in armeabi-v7a. | 04:57.01 |
| sebras | fredross-perry: I'll investigate more later today if we can/want to support something earlier than r14b. | 04:58.45 |
| fredross-perry | head to #artifex please | 04:58.53 |
| sebras | now I _really_ ought to sleep a bit. | 04:58.53 |
| tor8 | sebras: we already include stdint.h as a dependency in fitz/system.h which is included by all files | 08:56.58 |
| | so memory.c shouldn't need a second inclusion of stdint.h | 08:57.16 |
| | nor should store.c | 09:00.06 |
| paulgardiner | That crash bug I mentioned yesterday: I keep forgetting the copy of mupdf I use lags behind trunk. I've resynced and all seems fine now. The code in that area is wildly different. | 10:50.16 |
| sebras | tor8: really? :-/ | 11:47.39 |
| tor8 | sebras: yes. we need it for int64_t etc in our function prototypes, so must include it. | 12:00.15 |
| sebras | tor8: wait... that seems to only include stdint.h for MSVC older than VS2012..? | 12:00.33 |
| | no.. I can't read my ifdefs. | 12:00.50 |
| tor8 | newer than! | 12:00.56 |
| sebras | if you miss the enclosed #ifndef #define #endif #else it looks like it is only for older versions. :) | 12:01.27 |
| | tor8: ok, at the top of sebras/master you'll find two commits concerning limits.h | 12:05.17 |
| tor8 | sebras: yes, those two on the top LGTM | 12:19.38 |
| sebras | tor8: nice, now what about the rest? :) | 12:20.02 |
| tor8 | in "Remove duplicated help string from mudraw." shouldn't the removed line be inside the #ifdef instead? | 12:21.20 |
| | the intent is to show only the available options | 12:21.33 |
| sebras | tor8: there is an #else to thwt #ifdef which has a different string. | 12:21.41 |
| tor8 | ah, yes. | 12:21.56 |
| | helps to look at the full context :) | 12:22.00 |
| sebras | tor8: yeah, but if you only look at the diff it is a reasonable question. :) | 12:22.19 |
| tor8 | "Now a new run of is only started" in the commit message a word | 12:23.21 |
| sebras | :) | 12:24.03 |
| tor8 | and there's what looks like a debugging fz_warn left in that commit too | 12:24.05 |
| sebras | crap! | 12:24.18 |
| tor8 | "Bug 698991" I don't understand how we can get there and still have doc==null | 12:25.27 |
| | oh. there's a non-indirect object we're using as an indirect object? | 12:25.58 |
| | and therefore don't have the baked in 'bound_document' thing | 12:26.07 |
| | I'll want to look at that one a bit more, see if there's some more insidious problems | 12:26.23 |
| | so, all but "Bug 698990" and "Bug 698991" LGTM | 12:26.53 |
| | the first one just needs a minor tweak, the second one is probably fine but I want to analyze the problem myself to make sure I haven't missed something important | 12:27.19 |
| sebras | yeah I fixed 698990 just now. | 12:27.33 |
| | I have updated sebras/master now. | 12:28.51 |
| | I threw out 698991 for the time being (until you analyzed the situation a bit more) | 12:29.07 |
| | and fixed the commit message and fz_warn in 698990 | 12:29.23 |
| | AIUI that means sebras/master now LGTM? | 12:29.37 |
| tor8 | sebras: yes. sebras/master LGTM. | 12:36.21 |
| sebras | sweet! | 12:36.27 |
| | oh, and the fix for 698991 is really just papering over the issue. I realize that. | 12:50.06 |
| | I also felt that it is probably a bad idea to allow passing doc == NULL around in the code, because I don't think we handle that gracefully everywhere. | 12:51.09 |
| | fredross-perry (for the logs): the fix for limits.h is now in. | 14:12.54 |
| | tor8: on sebras/wip I have | 14:25.56 |
| | "Add separations to pixmap rendering functions." and "gl: Render separations using equivalent process colors." | 14:26.05 |
| | I discovered a number of PDFs that are using separations that draw more things when rendered in mutool than in the desktop viewers. | 14:29.52 |
| | Bug691425.pdf is one of them. | 14:30.52 |
| | implementing this means that mutool and mupdf-{gl,x11} now draws the same thing. | 14:31.17 |
| | presumably we would want to do the same for the android viewer of course, but I put this off until we agree that this is something that we ought to do. | 14:31.42 |
| | now, the rendering of Bug691425.pdf looks a bit iffy, so I'm still trying to understand what is happening here. | 14:32.00 |
| Robin_Watts | sebras, tor8: If a document has a userpassword set, but no ownerpassword, Acrobat refuses to load it without the userpassword being given. | 14:59.58 |
| | We load it, because the ownerpassword is set to "" | 15:00.11 |
| | I suspect we should only accept an ownerpassword of "" if a userpassword isn't set. | 15:00.38 |
| sebras | Robin_Watts: it spec says that apps should ask for a password, but if you supply either password correctly then you may view the document. I assume we automatically test "" before even showing any password input prompt..? | 15:06.53 |
| Robin_Watts | sebras: We do. | 15:07.11 |
| | I have a document from Cody here that has a userpassword of "userpass", an owner password of "". | 15:07.39 |
| sebras | Robin_Watts: if you just press enter in acrobat then it doesn't accept that as the owner password? | 15:07.46 |
| Robin_Watts | Acrobat prompts for a password. We don't. | 15:07.48 |
| sebras | Robin_Watts: yes, but if you simply press enter in Acrobat, what happens? | 15:08.05 |
| Robin_Watts | It complains at me. | 15:08.13 |
| | It says "I need a valid document open password" | 15:08.28 |
| sebras | does it matter if you use Acrobat Pro or what ever it is called? | 15:08.32 |
| Robin_Watts | I have not tried. Hold on... | 15:08.56 |
| sebras | that contradicts the spec stating that either password is ok. | 15:08.57 |
| Robin_Watts | My Acrobat pro won't open the file at all, saying it's an old file. | 15:09.37 |
| sebras | I'm thinking that maybe that version, which is geared towards editing, might do things differently wrt user/owner password. acrobat reader might not even care to authenticate the owner password. | 15:09.41 |
| Robin_Watts | a NEW file. | 15:09.43 |
| sebras | heh, ok. | 15:09.55 |
| Robin_Watts | The spec supposedly says that you can't have a userpassword without an owner password | 15:10.07 |
| | Which kinda makes sense. | 15:10.14 |
| | user passwords having less power than owner passwords. | 15:10.29 |
| sebras | I haven't seen that reference. | 15:10.43 |
| Robin_Watts | Me either, but that's what Cody claims, and it makes sense. | 15:11.04 |
| | sebras: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=b6c6eb9327679cbad74a52697e3252141f1c29d6 | 15:16.20 |
| sebras | Robin_Watts: ugh, that logic was not fun. | 15:30.04 |
| | Robin_Watts: I think it checks out though. | 15:30.22 |
| tor8 | Robin_Watts: ugh. why do we need to fail when the 'illegal' password is actually able to be used to decrypt the file? | 15:35.11 |
| Robin_Watts | tor8: I can only comment on what Acrobat does, and that we are doing something different. | 16:26.12 |
| | In this regard it does appear that Acrobat is doing something sane. | 16:26.21 |
| | If a user password is set, then it seems very odd to allow an empty owner password. | 16:26.42 |
| sebras | Robin_Watts: do we care what other viewers do? | 16:27.43 |
| Robin_Watts | sebras: When they do something sane, and we don't... probably. | 16:30.27 |
| sebras | Robin_Watts: I would argue that the file is created badly. the PDF creator shouldn't allow having now owner password if there is a user password, at a minimum it ought to require the owner password to be the same as the user password. | 16:33.27 |
| Robin_Watts | sebras: Yes. I agree. The file is created badly. However, such files exist out in the wild, so we are kinda stuck with doing something sane with them. | 16:34.03 |
| sebras | Robin_Watts: you patch sets out what it aims to do at least. you might need to hash out the preferred behaviour with tor8. | 16:37.41 |
| Robin_Watts | sebras: I'm open to 'saner' behaviour, though I can't think of any at the moment. | 16:40.09 |
| sebras | Robin_Watts: how would one go about getting owner privileges in a file like this? | 16:40.53 |
| Robin_Watts | sebras: You can't. | 16:42.18 |
| alex_b | Hello! I had a quick question about loading a PDF from a stream | 17:05.41 |
| | What are the available "magic" const char values? | 17:06.46 |
| sebras | alex_b: these are mimetypes. | 17:08.20 |
| | alex_b: so you can tell mupdf what document you think this data is. | 17:08.31 |
| | alex_b: for streams there are no file names so any file extension can not be used. | 17:08.52 |
| | alex_b: btw, I'm happy to hear that you are playing around with mupdf. what is it that you are developing? | 17:09.43 |
| alex_b | Ahhh, I just read that in the documentation. Thanks for clarifying though. | 17:14.35 |
| | I'm working on an iOS app | 17:15.01 |
| sebras | alex_b: oh, so you are using mupdf to render .pdfs? | 17:18.22 |
| | alex_b: or this is perhaps or .epub? | 17:18.29 |
| alex_b | PDFs, the goal is to have an app the university can use to fill out survey forms using a PDF file. | 17:20.33 |
| sebras | alex_b: aha, I see. | 17:20.47 |
| | alex_b: what license will the app be released under? | 17:20.54 |
| alex_b | I'm hoping to open source it when I get the app complete with a GNU AGPL license | 17:23.25 |
| sebras | that sounds like a good plan. | 17:24.04 |
| | alex_b: but I'm unsure if you are allowed to upload it to the itunes store though. I thought they opposed GPL/AGPL licensed apps..? | 17:24.40 |
| alex_b | I found this wiki article: https://en.wikipedia.org/wiki/List_of_free_and_open-source_iOS_applications | 17:25.13 |
| | I think they recently changed their minds about that? | 17:25.33 |
| | If Apple doesn't like that I'll look into commercial licensing options. MuPDF is really great and I'd love to support you guys. | 17:28.29 |
| sebras | alex_b: sounds good. should you need to inquire about a commercial license you would need to contact sales@artifex.com. :) | 17:29.12 |
| alex_b | cool, thanks for the help! I'll be back if I have any more questions. | 17:36.22 |
| sebras | alex_b: look into the licensing situation sooner rather than later though, before you spend time that might end up being wasted. | 17:37.02 |
| | Forward 1 day (to 2018/02/07)>>> | |
Log of #mupdf at irc.freenode.net.