| <<<Back 1 day (to 2017/01/11) | 20170112 |
Guest2802 | I'm trying to work out MuPDF - Is there an actual Java API that's usable alongside android code? The documentation doesn't really make it that clear. And is it usable through an android gradle file? | 01:09.21 |
Robin_Watts | Guest2802: hi | 01:09.35 |
Guest2802 | hi | 01:09.38 |
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. | 01:09.38 |
Robin_Watts | Yes, there is a java API. | 01:09.46 |
| Yes, it's usable alongside android code. | 01:09.54 |
| It's very new, hence the documentation isn't there yet. | 01:10.12 |
Guest2802 | Ah, fair enough | 01:10.24 |
| Is it distributed via a maven repo s that it can be used via gradle? | 01:10.40 |
Robin_Watts | it's built currently using an ndk-build file. | 01:10.49 |
Guest2802 | Ah, so it'll still require the NDK as well? | 01:10.58 |
Robin_Watts | AIUI, even with gradle, gradle calls down to ndk-build. | 01:10.59 |
| Anything written in C will need the ndk. | 01:11.13 |
Guest2802 | My main reason with asking about gradle is that it then puts everything in one place and makes building from multiple devices a tonne easier | 01:11.30 |
Robin_Watts | MuPDF is written in C, and has a 'shim' layer sat on top to do the JNI magic to make it work with java calls. | 01:11.36 |
Guest2802 | yeah | 01:11.42 |
Robin_Watts | Guest2802: We have a project that builds using gradle and makes a viewer in java. Let me find it. | 01:12.50 |
Guest2802 | Thanks | 01:12.58 |
| So with this - can I load up a PDF and render pages to a Bitmap? | 01:13.24 |
Robin_Watts | http://git.ghostscript.com/?p=apps/mupdf-android-nui.git;a=summary | 01:13.42 |
| With that project, no. | 01:14.09 |
| That project is an android viewer. It renders to android bitmaps and then displays them in a view. | 01:14.34 |
Guest2802 | But the library can? | 01:14.43 |
Robin_Watts | If you want to just open a document and render to bitmaps, then yes, the library is certainly capable of that. | 01:15.06 |
| And that project may not be an awful place to start - certainly it should help with the building etc. | 01:15.23 |
| BUT... before you go any further, I should check you understand the license terms for MuPDF. | 01:15.40 |
Guest2802 | Yeah, building is the part that I'd need to look at the most | 01:15.52 |
| From what I understand the license states that it must be open source - however if it's not specific licensing can be negotatied | 01:16.13 |
Robin_Watts | MuPDF is released under 2 licences. You have to pick one of them and abide by it. | 01:16.13 |
Guest2802 | ah | 01:16.17 |
Robin_Watts | The first license is the GNU AGPL. | 01:16.25 |
| It's a big complex license but basically it says "You can use MuPDF in your project if you want for free, with no warranty etc. But in exchange your whole project must be released under the GNU AGPL too. | 01:17.28 |
| This means (among other things) that anyone who gets a copy of your software has a right to get the source code too, and to modify/distribute it. | 01:18.12 |
Guest2802 | Yeah, I'm familiar with the GNU licenses. This specific project would be closed source - and I was going to email the licensing email once I'd worked out that I was definitely going to use it. | 01:18.21 |
Robin_Watts | OK, so the AGPL is no good for you. You'd therefore need a commercial license, and we do those too. | 01:18.54 |
Guest2802 | Mainly because I'm building something for a company that needs more than what the base Android PDFRenderer API can provide. (Specifically passwords on PDFs and speed) | 01:19.17 |
Robin_Watts | It would be worth you contacting sales@artifex.com. | 01:19.17 |
| OK. Commercial licences are a reasonable price. | 01:19.46 |
| By which I mean, they are not peanuts. | 01:20.01 |
Guest2802 | Yeah | 01:20.20 |
| Are they a yearly license fee? | 01:20.38 |
Robin_Watts | Yearly license fee combined with per royalty charges I believe. | 01:21.16 |
Guest2802 | Hmm, okay. Thanks | 01:21.36 |
Robin_Watts | but the exact details can be tailored to need, I believe. I'm just an engineer, I stay away from the commercial side. Talk to Scott, he's very friendly. | 01:21.50 |
Guest2802 | Yeah, thanks :) | 01:21.59 |
Robin_Watts | The main thing is to avoid you spending weeks getting it working only to find it's out of your price range. | 01:22.13 |
Guest2802 | Basically just trying to get a feel for the different libraries available to see which one works best for what I'm trying to do | 01:22.19 |
| Yeah | 01:22.23 |
Robin_Watts | I'm on UK time, so off to bed now. If you have any more questions, please just ask and someone will answer when the sun rolls around to the appropriate position. | 01:23.19 |
Guest2802 | thanks, night | 01:23.27 |
Robin_Watts | night. | 01:23.32 |
Darajan | I'm having some linking errors when building javaviewerlib for win32: "6>Linking... 6>LIBCMTD.lib(dbgheap.obj) : error LNK2005: __malloc_dbg already defined in MSVCRTD.lib(MSVCR90D.dll) " and "6>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library 6>LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library" | 09:34.46 |
| Anyone recognize this? | 09:35.05 |
| I was building it wrong (building libraries for debug & java-lib for Debugjava) changed buildprofile to debugjava for solution and it worked fine | 09:42.24 |
sh4rm4^bnc_ | hi. are there mujs release tarballs ? | 13:36.01 |
tor8 | sh4rm4^bnc_: no. | 13:37.57 |
| but you can download tarballs from the gitweb page | 13:38.11 |
sh4rm4^bnc_ | with commit hash and reproducible checksum ? | 13:39.00 |
tor8 | http://git.ghostscript.com/?p=mujs.git;a=tree and the 'snapshot' link | 13:39.08 |
| we haven't done any official releases of mujs. | 13:39.30 |
sh4rm4^bnc_ | would be interesting to have a mujs-node; at least the most basic bits | 13:47.14 |
jogux | tor8: sebras: fredross-perry: to recap what I just told Robin_Watts - the customer that was getting weird compile errors with mupdf+xcode, the root cause was essentially (for two different reasons) that #include <math.h> was ending up including fitz/math.h. IMHO it would be a really good idea to rename fitz/math.h. (and for the same reason, fitz/string.h too). Arguably clang/xcode is stupid, and I wouldn't argue against that, but it is going to cause | 18:08.33 |
| customers and us pain again and again if we don't rename. (It caused me a lot of pain getting the cocoapod to work.) | 18:08.34 |
fredross-perry | jogux - thanks for the update - yes sounds like a fine idea. | 18:09.45 |
jogux | the workaround is to set USE_HEADERMAP = NO and make sure include/mupdf/fitz is NOT on the compiler's include path. | 18:12.14 |
Robin_Watts | ?: | 18:14.34 |
| EWRONGWINDOW | 18:17.19 |
jogux | I think we've had this same discussion before about a year ago - I've stuck in a bug so it doesn't get lost: https://bugs.ghostscript.com/show_bug.cgi?id=697476 | 18:18.20 |
tor8 | jogux: ugh, yeah, I remember running into that idiotic Xcode behaviour years ago... | 22:25.08 |
| probably best to rename the header files | 22:25.19 |
jogux | tor8: yeah :-S (I don't have time to do it btw, deep in smartoffice things...) | 22:26.52 |
tor8 | jogux: I'll deal with it tomorrow | 22:40.33 |
jogux | awesome, thanks tor8! | 22:40.50 |
| Forward 1 day (to 2017/01/13)>>> | |