| | <<<Back 1 day (to 2017/06/13) | 20170614 |
| RobinWattsLenovo | avih: "RobinWattsLenovo" is when I am connected via the laptop. | 06:43.08 |
| Robin_Watts | tor8: I've just recreated the history of the lcms branch properly. | 10:00.29 |
| | (previously, we had a squashed version of a load of commits on there at the start) | 10:00.51 |
| | So what is on robin/lcms is the unsquashed history, and it ends up somewhere with no diffs from what was there before. | 10:01.21 |
| | If you want to do your renaming etc magic, go for it. | 10:01.41 |
| tor8 | okay. I saw mvrhel had one commit fixing some of the stuff I mentioned yesterday. | 10:01.50 |
| Robin_Watts | (If you're already doing it, I'll cherry-pick it on later) | 10:01.57 |
| | oh. Let me look for that. | 10:02.00 |
| tor8 | do you want me to do it on top, or filter-branch through the entire thing? | 10:02.10 |
| Robin_Watts | tor8: Do it on top, I think. | 10:02.20 |
| tor8 | okay. that's certainly easier :) | 10:02.31 |
| | have you got any thoughts about the naming in the email? | 10:02.44 |
| Robin_Watts | I'm away from that email at the mo, but I didn't see anything that jumped out as bad. | 10:03.30 |
| tor8 | I think my only significant question is whether we should avoid naming types the same as functions (they live in separate name spaces but could be confusing) | 10:04.04 |
| | fz_cmm_engine() and the typedef fz_cmm_engine, for example | 10:04.22 |
| Robin_Watts | types and functions having the same name is bad. | 10:04.28 |
| tor8 | we could add a 'get' in there but that would be inconsistent, but I suspect better than not being able to use 'tags' to get to the appropriate definition | 10:04.51 |
| Robin_Watts | tor8: We currently have fz_icc_engine for the function, and fz_cmm_engine for the type. | 10:05.25 |
| tor8 | that seemed even more inconsistent :) | 10:05.36 |
| Robin_Watts | I'm not sure we can have the same name for type and function. | 10:05.46 |
| tor8 | I accidentally figured out it's possible a while ago when dealing with pdf_annot_type | 10:06.03 |
| Robin_Watts | tor8: ok... | 10:06.12 |
| | originally mvhrel had _get_ in there, but I removed it :) | 10:06.25 |
| | I have to go out in a mo to get my second rabies jab... | 10:06.52 |
| | but before I go... | 10:06.56 |
| | The javascript and java stuff needs updating. | 10:07.05 |
| tor8 | yeah, I'll tend to that | 10:07.10 |
| Robin_Watts | I have some fixes here for the java stuff. | 10:07.14 |
| | but there is one question remaining. | 10:07.25 |
| tor8 | I saw your question about the color params argument, whether to pack into an int or create an object | 10:07.27 |
| Robin_Watts | for the ColorParams... yeah. | 10:07.32 |
| tor8 | I think an object is the right way to go, even though it hurts thinking about the needless waste | 10:07.43 |
| Robin_Watts | My preferred solution is to use an int, and then have a ColorParams static class that provides functions like: | 10:07.56 |
| | bool ColorParams.OPM(int) | 10:08.13 |
| | int ColorParams.OPM(bool) | 10:08.22 |
| tor8 | it would be less wasteful if we had a pool of reusable objects for it | 10:08.35 |
| Robin_Watts | tor8: That seems overkill, and hard. | 10:08.58 |
| | I believe we are safe to say that fz_color_params == NULL is the same as everything being 0. | 10:09.33 |
| | I will attempt a fix for the java stuff when I get back from injection. | 10:13.34 |
| | But I'll leave the JS stuff to you. | 10:13.50 |
| | back in a bit. | 10:13.57 |
| avih | tor8: hey, did you read the backlog? | 10:16.35 |
| tor8 | avih: about the 'install' file permissions, pkgconfig, and shared library stuff? yeah. | 10:17.25 |
| | a bit busy to deal with it right now | 10:17.30 |
| avih | when would be a better time or it? | 10:18.05 |
| | for* | 10:18.50 |
| tor8 | once we've merged the lcms branch in mupdf | 10:19.09 |
| | or I get blocked waiting on robin or michael :) | 10:19.32 |
| avih | i'm unable to mentally convert any of those into even rough timestamps :) | 10:20.34 |
| | are we talking hours? days? months? | 10:20.56 |
| tor8 | hours or days :) | 10:21.14 |
| avih | i see :) and as someone which doesn't follow those, how would i know? ping you once in a while? | 10:21.52 |
| tor8 | I've made a note in my mujs/TODO file to ping you when I get around to the issues you brought up :) | 10:25.43 |
| | so sit tight, and ping me if you get impatient | 10:25.56 |
| avih | heh. fwiw, the mpv js pr is here https://github.com/mpv-player/mpv/pull/4482 after review and squashed fixes, and halt on the maintainer having issues building mpv with mujs mostly without the pkgconfig file (he did solve it locally with http://sprunge.us/cDMD ). | 10:28.36 |
| | and actually, just now he just suggested to merge it right now and that i'll followup with pkgconfig thingy with you | 10:29.42 |
| | (regardless of mpv, having a pkg config is a useful thing IMO too) | 10:30.24 |
| | w00t. just got merged. so you can go ahead and try it out :) and possibly expect feedback from mpv users. | 10:31.46 |
| tor8 | avih: grats! | 10:42.55 |
| avih | thx. you too :) (i think :p ) | 10:43.10 |
| | tor8: fwiw https://mpv.io/manual/master/#javascript | 10:47.06 |
| tor8 | RobinWattsLenovo: Robin_Watts: mvrhel: in fz_default_rgb getter, shouldn't we return fz_device_rgb when the default colorspace context is NULL rather than return NULL? | 10:50.23 |
| Robin_Watts | tor8: Urm... yes, I think. | 10:52.20 |
| | Similarly with the others. | 10:52.25 |
| | ok, bbs. | 10:53.05 |
| tor8 | Robin_Watts: okay, several commits on tor/lcms | 13:11.57 |
| Robin_Watts | tor8: cool. just a mo... | 13:12.09 |
| tor8 | Robin_Watts: the thirdparty-lcms2 submodule points to a non-existent commit though | 13:12.10 |
| | Robin_Watts: no rush | 13:12.23 |
| Robin_Watts | tor8: It does? | 13:12.23 |
| tor8 | e26bbdd3a7790cae4d9904439fdbf3c1b46b44e1 does not exist in either robin/thirdparty-lcms2.git or the main thirdparty-lcms2.git | 13:13.25 |
| Robin_Watts | https://pastebin.com/ihFEqpiv | 13:13.51 |
| | tor8: I have e26bbdd here... maybe I didn't push it. | 13:15.15 |
| | ah, I suspect michael blew it away with his latest changes to lcms. Let me fix that. | 13:17.21 |
| | OK, look now. | 13:19.13 |
| | tor8: That pastebin is my java attempt to allow me to use ColorParams as an int. | 13:20.02 |
| tor8 | Robin_Watts: huh. so, the fz_color_params struct only hase one 'op' field | 13:20.32 |
| | but we should have one for op and one for OP (for fill and stroke states) | 13:20.45 |
| Robin_Watts | tor8: Ah, we have 2 fz_color_params. | 13:21.12 |
| tor8 | oh, the gstate has two structs. | 13:21.13 |
| | one for each state | 13:21.18 |
| Robin_Watts | One for stroke, one for fill. | 13:21.19 |
| tor8 | yeah, I see now | 13:21.34 |
| Robin_Watts | So, technically, the color_params can be seen as being part of the color triplet (quadruplet) | 13:21.41 |
| | PC is unwell. rebooting. | 13:29.22 |
| dabu | Hi | 17:26.26 |
| 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. | 17:26.26 |
| dabu | I have a problem building MuPDF for Android. I'm using Mac OS and have all the dependencies: ndk-bundle, ant, make, android, all listed on the site. However, when trying to make the project, I get a build failed error | 17:27.33 |
| | I'm not sure what is the best way to paste it | 17:27.47 |
| | So I'll just paste it here and maybe someone will know what's up | 17:28.13 |
| | 1 error generated. | 17:28.25 |
| | make[1]: *** [/Users/dabu/Projects/MuPDF/build/intermediates/ndkBuild/debug/obj/local/x86/objs-debug/mupdf_core//Users/dabu/Projects/MuPDF/libmupdf/source/fitz/archive.o] Error 1 | 17:28.27 |
| | make[1]: *** Waiting for unfinished jobs.... | 17:28.29 |
| | make[1]: *** [/Users/dabu/Projects/MuPDF/build/intermediates/ndkBuild/debug/obj/local/x86/objs-debug/mupdf_core//Users/dabu/Projects/MuPDF/libmupdf/source/fitz/bbox-device.o] Error 1 | 17:28.31 |
| | make[1]: *** [/Users/dabu/Projects/MuPDF/build/intermediates/ndkBuild/debug/obj/local/x86/objs-debug/mupdf_core//Users/dabu/Projects/MuPDF/libmupdf/source/fitz/bidi-std.o] Error 1 | 17:28.33 |
| | 1 error generated. | 17:28.35 |
| | make[1]: *** [/Users/dabu/Projects/MuPDF/build/intermediates/ndkBuild/debug/obj/local/x86/objs-debug/mupdf_java//Users/dabu/Projects/MuPDF/libmupdf/platform/java/mupdf_native.o] Error 1 | 17:28.37 |
| | make[1]: Leaving directory `/Users/dabu/Projects/MuPDF' | 17:28.39 |
| | :externalNativeBuildDebug FAILED | 17:28.41 |
| | Damn, that looks awful | 17:28.43 |
| avih | dabu: next time if it's more than 2-3 lines, use something like pastebin.com | 17:29.01 |
| dabu | Sorry, I'm doing it right now | 17:29.14 |
| | I didn't know it will split it into all these messages | 17:29.25 |
| | https://gist.github.com/rafal-adamek/9fbd6afab8d05fad3c6daa8af783095b | 17:30.32 |
| | It's better I think? | 17:30.38 |
| | Anyway, I would appreciate any help with this | 17:30.51 |
| Robin_Watts | dabu: Looks like there is a problem with the setup on your machine. | 17:33.18 |
| dabu | Are you able to tell what's wrong from this? | 17:33.43 |
| avih | the only issue seems to be "include/mupdf/fitz/output.h:190:16: error: redeclaration of 'strlen' must have the 'overloadable' attribute" | 17:34.16 |
| Robin_Watts | Look at include/mupdf/fitz/output.h | 17:34.26 |
| avih | where the other place is a system include file | 17:34.34 |
| Robin_Watts | and try deleting line 190. | 17:34.44 |
| avih | Robin_Watts: i'm completely unfamiliar with android dev, but isn't it expected that system libs would have strlen? why is it redefined at the mujs include files? | 17:35.48 |
| | or maybe just redeclared, still, same question. | 17:36.10 |
| dabu | I'm trying it right now | 17:36.57 |
| | I'm a newbie if it comes to NDK on Android and there is just so much stuff in here | 17:37.26 |
| | Build successful :) | 17:39.31 |
| | Thank you! | 17:39.33 |
| Robin_Watts | dabu: Yes. It doesn't help that the android tools change every time. | 17:39.36 |
| | dabu: So, you're an android dev? | 17:39.42 |
| dabu | Yes | 17:39.45 |
| Robin_Watts | Looking to use MuPDF in an app? | 17:39.49 |
| | Are you aware of the license? | 17:39.57 |
| | MuPDF is provided under 2 licenses. | 17:40.09 |
| | Firstly, it's supplied under the GNU AGPL. This means that if you abide by all the (many) terms of the GNU AGPL you can use MuPDF for free in your app. | 17:40.39 |
| dabu | Actually I wanted to... either alter or fork the app available on F-droid | 17:40.59 |
| Robin_Watts | The biggest and most crucial requirement there is that you have to be prepared to give away the entire sources to your app to anyone who has your app that asks for it. | 17:41.29 |
| dabu | Of course still as an open source project | 17:41.29 |
| | Yes | 17:41.35 |
| Robin_Watts | That's *all* the sources, not just your ones. | 17:41.37 |
| dabu | I'm aware of that | 17:41.38 |
| Robin_Watts | OK, cool, if you're happy with that, then no problem. | 17:41.45 |
| | I like to warn people about it in case they don't realise and then spend months developing something only to find that out later :) | 17:42.08 |
| dabu | What do you mean *all* the sources? Like, the whole app? | 17:42.10 |
| Robin_Watts | Yes. | 17:42.14 |
| dabu | Then ok | 17:42.18 |
| | that's what I want | 17:42.21 |
| Robin_Watts | Some people think that they only need to release the parts relating to MuPDF. | 17:42.42 |
| dabu | Publish it on F-Droid and of course give all the credit where its due | 17:42.46 |
| Robin_Watts | but you need to give everything away, even the bits with nothing to do with MuPDF. | 17:43.06 |
| dabu | I know :) | 17:43.16 |
| | All the source code | 17:43.20 |
| Robin_Watts | dabu: Fab. Sounds like you're sorted then. | 17:43.20 |
| dabu | But | 17:43.26 |
| | I want to ask you something | 17:43.29 |
| | I've just built the app and installed in on the device | 17:43.39 |
| | But it's different than the app available on F-Droid | 17:43.47 |
| Robin_Watts | which app ? | 17:43.57 |
| | (Which app did you build? There are several) | 17:44.16 |
| dabu | https://f-droid.org/repository/browse/?fdfilter=MuPDF&fdid=com.artifex.mupdfdemo | 17:44.18 |
| avih | Robin_Watts: "give away" is a weird language. better, i think, would be to allow others use your all the app's sources under the same or compatible license | 17:44.23 |
| Robin_Watts | avih: "give away" is sufficient to impart the whole horror of the AGPL to people unprepared for it, I feel :) | 17:45.05 |
| avih | it certainly does :) | 17:45.19 |
| dabu | I cloned the repo and made it according to this: | 17:45.31 |
| | https://mupdf.com/docs/android-build-viewer.html | 17:45.32 |
| Robin_Watts | dabu: Which repo? :) | 17:45.49 |
| | http://git.ghostscript.com/?p=mupdf-android-viewer-old.git;a=summary <- That one is the app you're looking for, I suspect. | 17:46.05 |
| | http://git.ghostscript.com/?p=mupdf-android-viewer-mini.git;a=summary <- That one is a simpler app built using the new JNI interface - it's likely better to develop from. | 17:46.57 |
| | http://git.ghostscript.com/?p=mupdf-android-viewer-nui.git;a=summary <- That one is another app we're working on that will have the same look at feel as the new version of SmartOffice. | 17:47.32 |
| dabu | Oh | 17:47.47 |
| | I get it now | 17:47.50 |
| | Yes, indeed it says Mini | 17:47.54 |
| | Is the android-viewer-old also available for public use? | 17:50.37 |
| Robin_Watts | Yes. Same license terms. | 17:51.01 |
| | It is the version we have on google play etc, but it'll probably not get much attention henceforth. | 17:51.32 |
| dabu | Are you preparing another Android app? | 17:52.00 |
| Robin_Watts | Yes, the -mini and -nui ones. | 17:53.13 |
| | I suspect that -nui will end up being the most fully featured. | 17:53.26 |
| dabu | Well | 17:56.19 |
| | do you need any help with android stuff? | 17:56.26 |
| | MuPDF (the one from the FDroid) is my favorite PDF reader out there and I wanted to made some changes to the UI that would better suit my needs. But if you need help with something serious, I would gladly help | 17:58.14 |
| Robin_Watts | dabu: That's a very kind offer. | 17:58.36 |
| | MuPDF is developed by a company called Artifex. | 17:58.48 |
| | It's the same company that has developed Ghostscript for years. | 17:59.02 |
| | and now develops SmartOffice too. | 17:59.09 |
| | We license Ghostscript and MuPDF for free under the GNU AGPL, and for people that can't take those terms (of whom there are lots), we also offer commercial licenses. | 17:59.48 |
| dabu | Och, I undersand | 18:00.01 |
| Robin_Watts | Those commercial licenses cost money, and that's what funds us. | 18:00.01 |
| | So, you are absolutely free to make changes and improvements and feed them back to us. | 18:00.39 |
| | We'll gladly take them on, as long as: 1) they meet our coding standards etc, 2) we don't disagree with them, 3) they don't conflict with something we're doing commercially, and 4) that you are prepared to assign copyright to us. | 18:01.26 |
| | 4) is important, cos we can't afford to lose the right to distribute the software commercially. | 18:02.00 |
| | That means we can't take in bits of code that we can't license as we wish. | 18:02.12 |
| | If, understanding those terms, you want to develop new features for the apps, we'd love to have them. | 18:02.57 |
| | There is probably something you should understand about the different apps, so I'll do a little history lesson. Bear with me. | 18:03.59 |
| | MuPDF is at heart a portable C library. It builds and runs on almost anything. | 18:04.16 |
| | We've done our best to put all the PDF cleverness into the library under a C level API. | 18:04.52 |
| | This means that all the viewers/tools etc are fairly thin wrappers that call down to that C API. | 18:05.15 |
| | Now, when I first wrote the Android app that you're talking about, we didn't have a JNI interface. | 18:05.44 |
| dabu | Sorry, I will get back to you in half an hour | 18:05.56 |
| Robin_Watts | so I hacked one together that was just enough for what we wanted to do with the app. | 18:05.56 |
| | dabu: No worries. I may be gone by then, so I'll finish my little story, and you can read the logs. | 18:06.24 |
| | Paul Gardiner then expanded the app, and made it much shinier. He did that without making too many changes to the original structure of my JNI, just extending it as required. | 18:07.18 |
| | This means that there is rather more intricacy in the Java->C layers of the app than we'd like. | 18:07.55 |
| | If you want to modify the app, you will almost end up having to work both at the C and the java level. | 18:08.21 |
| | Many android developers are uncomfortable working like that (and it's perfectly reasonable). | 18:08.46 |
| | Accordingly, in the later versions of MuPDF, we've done a much nicer JNI implementation, that offers a Java version of our C API. | 18:09.21 |
| | The calls map pretty much directly down. | 18:09.29 |
| | This means it's MUCH more flexible for app authors. | 18:09.53 |
| | It's also more maintainable and readable etc. | 18:10.10 |
| | Accordingly, the new apps we're working on call the new JNI interface. | 18:10.38 |
| | They can't do as much as the old one, yet, but when they do they will be SOOO much nicer to work on. | 18:10.59 |
| | For instance, if you wanted to do 2-up display, that'd be horrible to hack into the old app, but comparatively simple to do in the new one. | 18:11.48 |
| dabu | Thank you for sharing the details with me (and of course the help building the app, old one works perfectly as well). | 18:59.50 |
| | As for me, I'm working as a full time Android dev in a corporation (at the Junior position right now) and also study IT during the weekends, so my free time is very limited. | 19:00.53 |
| | I think that having a good, modern and free PDF viewer is more than welcome on the platform though and if it's possible I would like to help | 19:01.42 |
| | However, it's too soon to commit for now, I think. You're professionals and I don't want to waste your time if it could not work. I will try to tinker with the old app for now and maybe make the interface more modern and see the results | 19:03.19 |
| | Forward 1 day (to 2017/06/15)>>> | |
Log of #mupdf at irc.freenode.net.