| | <<<Back 1 day (to 2020/11/24) | Fwd 1 day (to 2020/11/26)>>> | 20201125 |
| lexboss777 | Hello! When I compile mupdf for use in iOS it's being too large - 182 MB. It's because of the fonts resources/fonts/hans. How do I exclude them from a mupdf static library? | 07:33.22 |
| ator | add -DTOFU and -DTOFU_CJK to the C command line when building it | 10:10.18 |
| sebras | lexboss777: if you define TOFU or TOFU_CJK when buliding I ... ator beat me to it. :) | 10:10.28 |
| lexboss777 | @ator @sebras even if I define those variables in the hard-way in include/mupdf/fitz/config.h the size of compiled static library is not changing. I do it through config.h to be sure that they are applied. | 10:22.32 |
| | #define TOFU#define TOFU_CJK | 10:23.41 |
| | Worth to mention that I compile mupdf 1.11. Because https://github.com/ArtifexSoftware/mupdf-ios-viewer points to that release. | 10:25.46 |
| sebras | lexboss777: did you remove the build directory after updating config.h? | 10:40.44 |
| | I'm on linux, but I've verified that I get the same build size when building mupdf 1.11 regardless of whether I set TOFU on the command line or change config.h | 10:41.32 |
| lexboss777 | @sebras yes, ofcourse I did remove it. | 10:42.21 |
| sebras | @lexboss777 ok, then I'm puzzled. I can't bulid test for ios since I'm not on a mac. | 10:44.15 |
| ator | lexboss777: the static library will still include all the font resources and be very big, but with those defines they won't be linked with the final executable | 10:48.18 |
| lexboss777 | @ator I was guessing that excludance of redundant fonts was a job left for a linker. I just didn't want to push a 390 MB (it's the size of a fat lib with x86_64, i386, armv7, arm64) mupdf lib to our git repo.I think I can provide those defines AND manually delete fonts that we don't need from resources/fonts and then we should be fine I guess ) | 10:54.01 |
| ator | you can remove the font files from the resources too, yeah | 10:54.33 |
| sebras | lexboss777: is your repo on github somewhere? | 10:57.06 |
| lexboss777 | @sebras no it's a private repo. But currently I do all the things with repo mupdf-ios-viewer https://github.com/ArtifexSoftware/mupdf-ios-viewer | 10:58.23 |
| | I use mupdf-ios-viewer repo to compile mupdf. And then I use mupdf static library in our xamarin.iOS project (it's a C#). | 11:00.02 |
| artifexirc-bot | <Robin_Watts> lexboss777: You are aware of the MuPDF license, right? | 11:18.16 |
| | <Robin_Watts> If you're not a commercial customer of Artifex, then you can only use MuPDF if you abide by the terms of the GNU AGPL. | 11:18.57 |
| | <Robin_Watts> Now the GNU AGPL is a big complicated license that you need to understand, and I am not a lawyer, so I can't/won't give legal advice but there are some really obvious things. | 11:19.56 |
| lexboss777 | @artifexirc-bot, ok we will check it before we will choose a mupdf as solution for our needs. thanks | 11:20.27 |
| artifexirc-bot | <Robin_Watts> 1) Any app that uses code licensed under the GNU AGPL must release its source code on request to anyone that obtains a copy of the app. That's ALL the source for ALL the app. | 11:20.58 |
| | <Robin_Watts> 2) I'm not sure that it's actually possible to use any GNU AGPL licenses with the iOS AppStore because of their licensing terms. | 11:21.35 |
| | <Robin_Watts> lexboss777: Fab. Just didn't want to see you invest hours in getting it working only to discover that there was the unseen licensing hurdle waiting to trip you up. | 11:22.09 |
| | <Robin_Watts> Taking a commercial license from Artifex removes both 1) and 2) from being issues. | 11:22.23 |
| | <paulgardiner> Just pointing out bug 703179 in case it goes unnoticed for a while. | 14:07.35 |
| | <ator> @Robin_Watts got a minute? | 15:30.42 |
| | <Robin_Watts> Sure. I have to pop out in 15 mins. | 15:30.59 |
| | <ator> in pdf-op-filter.c function walk_string() | 15:31.05 |
| | <ator> there's something fishy going on if we run into a space character | 15:31.59 |
| | <ator> I have uni = 48 (".") | 15:32.15 |
| | <ator> the editable string has a space | 15:32.25 |
| | <ator> it goes into the else if (rune == 32) branch | 15:32.41 |
| | <ator> and then repeats that forever, there's no way it progresses | 15:32.56 |
| | <Robin_Watts> str->pos++ ? | 15:33.03 |
| | <ator> remove is false in this case | 15:33.40 |
| | <Robin_Watts> I can't remember what this function does. Gimme a mo. | 15:34.44 |
| | <ator> if (!remove) str->pos += n; | 15:34.45 |
| | <ator> if it's removing then the str will be shortened | 15:35.10 |
| | <ator> I think you may have missed the non-removal case in this branch | 15:35.23 |
| | <Robin_Watts> if (!remove) str->pos++; in the rune == 32 case? | 15:35.44 |
| | <ator> but then I wonder what happens in the if (rune == uni) case where the comment says "skip" but then runs the "remove" branch | 15:36.09 |
| | <ator> I want to move the str->pos += n to an else after the if (remove) | 15:37.19 |
| | <ator> does that sound right to you? | 15:37.32 |
| | <ator> I don't really know what walk_string is supposed to do though... | 15:38.11 |
| | <Robin_Watts> It looks superficially OK to me, yes. | 15:38.20 |
| | <Robin_Watts> This is to do with redaction, right? | 15:38.42 |
| | <ator> it runs for both redaction and normal filtering | 15:38.59 |
| | <ator> non-redacting mutool clean "sanitize" case triggers this | 15:39.14 |
| | <Robin_Watts> It might run for normal filtering, but I think it's intended for redaction. | 15:39.26 |
| | <ator> yes. 'remove' is true if the text should be redacted | 15:39.44 |
| | <Robin_Watts> IIRC, then the idea is that we 'walk' the Alt Text strings for characters as they come in. | 15:40.01 |
| | <ator> false if it's not to be redacted, but still needs to be tracked to know where in the StructText we are | 15:40.02 |
| | <ator> I think. not 100% sure here. | 15:40.23 |
| | <Robin_Watts> If the strings match, and we aren't redacting, we just update the pointer so that we look for the next incoming char in the correct place. | 15:40.41 |
| | <Robin_Watts> If the strings match, and we are redacting, we remove the char. | 15:40.48 |
| | <Robin_Watts> If the strings don't match, then we record that fact, and at the end, if we were supposed to redact any of it, we delete the whole string (better to be safe than sorry). | 15:41.18 |
| | <ator> yeah, the 'walk_string' function is called via mcid_char for all characters | 15:41.35 |
| | <ator> makes me wonder what happens with doubled up characters | 15:41.49 |
| | <ator> like the 'p' in "happy" | 15:41.55 |
| | <ator> wouldn't that redact both "p" instances? | 15:42.11 |
| | <Robin_Watts> No, if we match we stop. | 15:42.29 |
| | <Robin_Watts> do { ... } while (rune != uni) | 15:42.40 |
| | <ator> no, we only stop when we don't match | 15:42.41 |
| | <ator> bah. you're right. logic is weak with this one today. | 15:42.58 |
| | <Robin_Watts> ISTR this hurt my head as I wrote it too 😦 | 15:43.17 |
| | <ator> I'd be happier with an explicit GOTO in the 'space' case | 15:43.30 |
| | <ator> make me brain hurt less | 15:43.35 |
| | <Robin_Watts> explicit comment, good, explicit goto bad. | 15:44.38 |
| | <ator> http://git.ghostscript.com/?p=user/tor/mupdf.git;a=commitdiff;h=4d13810a5d0357204718990bfc215305abdefcb6 this but with a proper commit message maybe | 15:44.39 |
| | <Robin_Watts> That gives a change in behaviour if remove and rune == uni. | 15:45.39 |
| | <ator> that should preserve the logic (but the comment seems misleading) | 15:45.42 |
| | <Robin_Watts> but possibly the correct behaviour 🙂 | 15:45.57 |
| | <ator> it changes the logic for uni != 32 and rune == 32 | 15:46.02 |
| | <ator> /* Match. Remove or skip over that one. */ | 15:46.18 |
| | <Robin_Watts> Previously, if rune == uni and remove, we'd have added n to str->pos | 15:46.37 |
| | <Robin_Watts> In your revised code, we don't. | 15:46.53 |
| | <ator> the else is not in the same if-else chain | 15:46.57 |
| | <Robin_Watts> I know. | 15:47.21 |
| | <ator> after the if (rune == uni) else chain, there's a second independent if (remove) | 15:47.22 |
| | <Robin_Watts> I know. | 15:47.25 |
| | <Robin_Watts> In the original code, if (rune == uni) we'd str->pos += n; | 15:47.59 |
| | <Robin_Watts> In the original code, if (rune == uni) we'd str->pos += n regardless of remove. | 15:48.07 |
| | <ator> ah yes. I see what you mean. adding to str->pos there seems wrong, because we also remove the character at the old pos | 15:48.12 |
| | <ator> so then we'd skip the next character | 15:48.19 |
| | <Robin_Watts> Yes. I think your fixed version is a change in behaviour, but it's a good change. | 15:48.34 |
| | <Robin_Watts> Right. I gotta pop into banbury to drop off a harddrive. bbs. | 15:50.23 |
| | <ator> I'm looking into it now. | 15:55.29 |
| | <paulgardiner> Tak | 15:57.28 |
| | <paulgardiner> Hmmm! Did I just say "ceiling"? | 15:58.22 |
| | <paulgardiner> Tack | 15:59.38 |
| | <ator> @Robin_Watts when sanity checking my results by redacting in the same document from the eternal loop, segfault in update_mcid because tag->alt.utf8 and tag->mcid_obj are both null | 15:59.58 |
| | <ator> which seems to be the same issue that paul's run into | 16:00.37 |
| | <ator> @paulgardiner ceiling or roof, take your pick :) | 16:01.06 |
| | <Robin_Watts> @ator back. | 16:33.47 |
| sebras | @Robin_Watts re 702780: can't that commit use pdf_dict_get_inheritable()? | 20:22.19 |
| | then it will also detect cycles in the tree for your. | 20:23.06 |
| | <<<Back 1 day (to 2020/11/24) | Forward 1 day (to 2020/11/26)>>> | |
Log of #mupdf at irc.freenode.net.