| | <<<Back 1 day (to 2016/06/21) | 20160622 |
| inflex | Haven't looked at them yet. This is an opensource project that we're considering using it with (though Iknow there's incompatibilities within the licences of those too) | 00:01.13 |
| | Might be a clash possibly with the MIT licence that our software uses? | 00:02.03 |
| | Then again, we're considering a bidirectional pipe/comms option too where the two separate programs just talk to each other rather than integrating the PDF viewer | 00:06.09 |
| Robin_Watts | inflex: MuPDF is licensed under the GNU AGPL, and under a commercial license. | 00:15.02 |
| | The MIT license is incompatible with the GNU AGPL. | 00:15.37 |
| | (As I understand it) | 00:15.56 |
| | The GNU AGPL says that if anyone links any code with a GNU AGPL project, then the whole project must be released under the GNU AGPL. | 00:16.31 |
| | Hence your code would need to change from the MIT license. | 00:16.58 |
| | OR we can do you a commercial license, at which point you can do almost anything you want - except pass on that license to other people. | 00:17.37 |
| | Doing a bidirectional pipe/comms thing is tricky legally too. | 00:19.09 |
| | I would advise you to look into this carefully before investing lots of time. | 00:19.47 |
| | (Sorry to be the bearer of bad news) | 00:20.05 |
| inflex | No, that's fine, really. | 00:29.50 |
| somaReverse | Hi. What font do I miss https://ptpb.pw/NG6g ? | 02:16.17 |
| Guest44796 | I am having error in building the ndk.. "jni/mupdf.c:484:3: warning: passing argument 3 of 'fz_new_stream' from incompatible pointer type [enabled by default]" | 07:51.23 |
| chrisl | That's not an error, that's a warning: I wouldn't have thought the build would stop for a warning | 07:56.35 |
| Guest44796 | hmm,, ok let me check the final one that is stopping me from building.. thanks.. w | 07:58.20 |
| | it was this function | 08:05.37 |
| | fz_new_draw_device_with_bbox | 08:05.37 |
| chrisl | I'm afraid the person who might be able to help you won't be around here for a while. | 08:10.07 |
| Guest44796 | oh I see.. will just play around with it then.. thanks.. I just used this before last month and it's working fine.. now deleted my local copy and redid as I want a fresh copy.. but yeah :D | 08:12.11 |
| | ok thanks chris | 08:12.13 |
| chrisl | The jni stuff is in a state of flux right now, so things are liable to change/break | 08:13.13 |
| Guest44796 | are you refering to the jni compiler? | 08:16.45 |
| chrisl | Guest44796: no, the mupdf jni interface | 08:25.20 |
| Guest44796 | oh,, I see.. so if I use older version should work then? | 08:26.07 |
| chrisl | I couldn't say - mupdf in general, and android stuff in particular are not my areas, sorry | 08:27.13 |
| Guest44796 | I see.. I'll just try... but based on what happened or what you shared.. it was due to the updates.. thanks chris :D | 08:30.18 |
| Robin_Watts | Guest44796: Is that in the jpx stuff? | 08:57.33 |
| | no, ignore me. | 08:57.50 |
| | I'll have a look in a mo. | 08:57.57 |
| | somaReverse: You're not missing a font. | 08:58.30 |
| | It's just that some of your fonts are very large, so we're avoiding building some huge tables for them. | 08:58.56 |
| Guest44796 | haha,, ok thanks robin, the issue was happening in the method 'fz_new_draw_device_with_bbox' .. and when I try to generate | 09:02.21 |
| | there are functions that says obsolete | 09:02.30 |
| | just pulled an older committed version | 09:02.42 |
| | pulled this version "Fix Gproof DLL calling on windows" | 09:03.05 |
| | since not sure which last committed version is working | 09:03.19 |
| Robin_Watts | I can confirm the problem here. | 09:22.58 |
| | tor8 made some changes to the core last week, and obviously missed the android bit. | 09:23.22 |
| | We'll get that fixed. | 09:23.37 |
| tor8 | Robin_Watts: I've also cocked something up with the draw device transform bit that I'm debugging now | 09:23.53 |
| | the scissor rects are being mishandled if the transform is !identity | 09:24.08 |
| | when doing masks and groups | 09:24.15 |
| Robin_Watts | tor8: Did you see mvrhel's comment from last night? | 09:24.16 |
| | missing font files? | 09:24.27 |
| tor8 | Robin_Watts: yes. I forgot to updated libfonts.vcproj | 09:25.26 |
| Guest44796 | ok robin,, thanks.. will wait for the update then.. will just use the latest.. since it is more better :D | 10:06.24 |
| tor8 | Robin_Watts: in pdf_run_page_contents_with_usage we concatenate the incoming ctm with the page->ctm | 11:19.07 |
| | isn't the order of concatenation wrong though? | 11:19.14 |
| Robin_Watts | There is a 50% chance of it being wrong :) | 11:19.44 |
| | and a 50% chance of me reasoning it out and getting it wrong. | 11:20.34 |
| tor8 | the right hand side usually has the 'old' transform | 11:20.47 |
| Robin_Watts | Does reversing it break the cluster? And does reversing it solve your problem? | 11:20.58 |
| tor8 | so I'd say it's probably 51% chance of it being wrong :) | 11:21.02 |
| Robin_Watts | If "no, yes" then I'd support changing it :) | 11:21.13 |
| tor8 | Robin_Watts: I think it will be hard to test, since the vast majority of the time it'll be an identity matrix | 11:23.41 |
| Robin_Watts | tor8: Change the line, cluster push, check for breakages. | 11:24.00 |
| | How hard is that? | 11:24.05 |
| tor8 | oh, that's not hard | 11:24.17 |
| Robin_Watts | That will give us confidence that it *could* be wrong. | 11:24.22 |
| tor8 | but the cluster won't test this bit of code (since we always call it with the identity matrix) | 11:24.39 |
| Robin_Watts | And if it then solves the particular problem that you're seeing, I'm good with it. | 11:24.45 |
| tor8 | I don't see any actual problem, but going through the matrixes threw up a red flag | 11:24.59 |
| | let me see if I can cook up a file/test case | 11:25.20 |
| | rats. both of the orders are wrong :/ | 11:28.55 |
| | no. I'm just ending up applying the matrix twice >.< | 11:37.57 |
| | I've now convinced myself that your original order is correct. | 11:41.40 |
| Robin_Watts | heh :) | 11:41.46 |
| tor8 | Robin_Watts: a few fixes on tor/master | 11:42.41 |
| | Robin_Watts: do you want to get muraster committed to master? | 11:42.59 |
| Robin_Watts | tor8: Yes please. There are various fixes there waiting for review. | 11:43.26 |
| tor8 | Robin_Watts: looks like the other fixes there are already in? | 11:44.51 |
| | Robin_Watts: muraster does it really need #include "mupdf/pdf.h" /* for pdf output */ | 11:45.37 |
| Robin_Watts | tor8: PRobably not. | 11:46.54 |
| | I think muraster is already in too. | 11:47.04 |
| tor8 | oh, it is! | 11:47.15 |
| Robin_Watts | But that extra header is a good catch. | 11:47.34 |
| tor8 | muraster.c is not included in the unix Makefile | 11:48.43 |
| | adding it throws up a bunch of errors and warnings | 11:48.48 |
| | source/tools/muraster.c:414:20: warning: '/*' within block comment [-Wcomment] | 11:49.23 |
| | #define SEMAPHORE /* type for a semaphore */ | 11:49.23 |
| | ^ | 11:49.23 |
| | source/tools/muraster.c:415:9: warning: 'SEMAPHORE_INIT' macro redefined [-Wmacro-redefined] | 11:49.23 |
| | #define SEMAPHORE_INIT(A) /* init a semaphore */ | 11:49.23 |
| Robin_Watts | tor8: ugh. THose need to be fixed. Will look at them. | 11:49.45 |
| | Why do we have cmapcleanx and cmapcleanz ? | 11:49.55 |
| tor8 | Robin_Watts: in case we ever need to regenerate the 'optimized' CMap resource files | 11:50.16 |
| Robin_Watts | I mean, what's the difference? | 11:50.26 |
| tor8 | the ones that share common chunks using 'usecmap' | 11:50.27 |
| | I can barely remember | 11:50.44 |
| | one is outputting them unoptimized and the other one compresses them | 11:50.57 |
| | by compresses, I mean it joins up ranges etc | 11:51.14 |
| Robin_Watts | ok. | 11:51.37 |
| tor8 | cmapcleanx just parses and pretty prints a CMap as is | 11:52.04 |
| | cmapcleanz optimizes the ranges and singletons | 11:52.13 |
| | ah, no | 11:52.52 |
| | cmapcleanx turns *all* lookups into singles | 11:52.59 |
| | so that you can use sed and awk and grep to massage the cmap files | 11:53.12 |
| | and cmapcleanz packs the singletons back up into ranges for the final output | 11:53.29 |
| Robin_Watts | Ok, they all look plausible enough to me. | 11:53.44 |
| tor8 | it's what I used to create the UniGB-X etc CMaps that have the big chunks of common lookups for all the UTF-16, UTF-32 and UCS-2 etc cmaps | 11:54.41 |
| | to save a *lot* of space | 11:54.48 |
| | Robin_Watts: thanks. | 11:54.56 |
| | bgprint_flush isn't called | 12:01.08 |
| | a WIP to fix up muraster.c to build on linux on tor/master | 12:01.36 |
| Robin_Watts | No, bgprint_flush is now done another way. | 12:04.45 |
| | tor8: Hmm. When did the fz_set_pixmap_resolution change go in? | 12:06.16 |
| | I might have argued for fz_set_pixmap_resolution{,s} myself. | 12:06.44 |
| | but the fixup looks good to me. | 12:07.40 |
| tor8 | Robin_Watts: in the "Set pixmap resolution when creating pixmaps for draw device." commit | 12:35.01 |
| Robin_Watts | tor8: right. | 13:04.56 |
| somaReverse | Robin_Watts: Thanks for the explanation. | 14:25.52 |
| marcosw1 | kens: are you around? | 15:17.09 |
| kens | yeah | 15:17.15 |
| marcosw1 | just confirming that we can read pdf/x-3 and x-4 files. Phil is asking. | 15:17.38 |
| | I canât see any reason why not, but thought Iâd double check since they are an important customer. | 15:17.54 |
| kens | Well PDF/X is a subset of PDF, so yes | 15:17.54 |
| | I haven't read the spec of PDF/X4 in detail, I thought it was still provisional | 15:18.21 |
| | apparently PDF/X-4 is indeed finalised, ahs been for some time | 15:19.32 |
| | Since PDF/X is a subset, we never have a problem reading it | 15:19.45 |
| marcosw1 | thx. | 15:20.47 |
| sebras | tor8: do you have time to take a look at the patch over at sebras/master? | 15:31.29 |
| | tor8: still trying to get the samples correct with the luratech jpx codec. I only support 8bit at the moment and that I likely the issue. | 15:33.00 |
| | tor8: I also resurrected the jpegxr-branch from bitrot and it plays along nicely. | 15:39.01 |
| | Forward 1 day (to 2016/06/23)>>> | |
IRC Logs