| | <<<Back 1 day (to 2018/01/23) | 20180124 |
| Robin_Watts | sebras: We don't use that lcms. We use our own incompatible lcms fork. | 00:32.39 |
| | sebras: Other 2 look good. | 00:33.20 |
| sebras | Robin_Watts: by that account several libraries may also be incompatible forks because they have local patches that have not yet gone upstream or that are unlikely to be upstreamed any time soon. | 01:24.17 |
| hello123 | Hi is anyone there? I have a question about mupdf. I am attempting to integrate mupdf into a mac app. I downloaded mupdf-0.5-macosx.tar.gz but it doesn't have 'extract.' Any recommendations on how I can get mupdf to extract in as a unix executable or somehow use a static library on the Mac? THANK YOU! | 05:53.18 |
| | Sorry I asked the wrong question! How do include all the required dependencies inside an Xcode app project? | 06:39.21 |
| tor8 | sebras: lcms2 is a special case -- because we've changed the API so we can't even link with stock lcms2 IIRC | 10:16.06 |
| paulgardiner | Is my saving-failure fix okay to push? sebras has looked it over. | 10:53.11 |
| Robin_Watts | paulgardiner: Yup. lgtm. | 11:06.56 |
| | unless you want to fix "non-incemental" in the commit message :) | 11:07.23 |
| paulgardiner | Yeah I might :-) Actually, I've just noticed there's a #define(_WIN32) and I've altered only one side. Better fix that too. | 11:13.46 |
| | Doesn't show up in the diffs of course | 11:14.04 |
| sebras | tor8: how about me changing the title to say "Fork of " and point to our git tree but keep the rest? | 11:14.09 |
| tor8 | sebras: that would work for me. what do you think Robin_Watts? | 11:24.07 |
| sebras | tor8: updated. | 11:26.36 |
| Robin_Watts | sebras: I might make it say "incompatible fork of", but yeah. | 11:27.35 |
| sebras | Robin_Watts: commit on sebras/master updated. it never mentions lcms. | 11:32.49 |
| Robin_Watts | :) | 11:33.36 |
| sebras | Robin_Watts: don't worry, I wont push it. I'll simply remove it. | 11:33.53 |
| Robin_Watts | sebras: I think you're right to put it in the docs. | 11:34.07 |
| sebras | also I spelled "license" as "library" which is all wrong. | 11:34.09 |
| Robin_Watts | It's just that linking against stock lcms2 will fail. | 11:34.19 |
| | Ours has a different ABI, and differently named header files. | 11:34.38 |
| | We've done as much as we can to make it impossible for people that want to use ours to accidentally use another one. | 11:34.57 |
| sebras | Robin_Watts: I know, but the code we use is still 90% from an original source, and that's what I want to point out. | 11:37.06 |
| | Robin_Watts: and most importantly the license under which we use it. | 11:37.27 |
| Robin_Watts | sebras: Sure. Which is why I just wanted it to say "Incompatible fork". | 11:40.00 |
| | If it says "fork of..." you know the distros will try to make it shared. | 11:40.14 |
| sebras | Robin_Watts: I'm sure they will try anyway. | 11:40.44 |
| Robin_Watts | sebras: Yeah, well, I'll be rude to them. | 11:41.03 |
| sebras | Robin_Watts: tor8: updated. how about the rest of the patches on sebras/master? | 11:41.21 |
| | tor8: I've delibrately kept "Do not throw away byte when lexing tokens without strings." until we meet later today. | 11:41.40 |
| Robin_Watts | sebras: First 4 are fine. | 11:42.52 |
| sebras | I might have forgotten to thank oss-fuzz in several of these. I might add this to the commit messages, but otherwise leave them unchanged. | 11:43.29 |
| Robin_Watts | Fifth one too. | 11:43.43 |
| sebras | Robin_Watts: that one took quite some time to figure out. | 11:43.54 |
| | Robin_Watts: but now I know more about splay trees than I've ever done! :) | 11:44.06 |
| Robin_Watts | sebras: The splaying stuff was correct, as far as I can see. It was the usual tree manipulation where I went wrong. | 11:45.07 |
| | splay trees rock. | 11:45.11 |
| | The draw-mesh one... | 11:45.33 |
| | we used to only free temp if temp != dest | 11:45.43 |
| sebras | Robin_Watts: yes, but that happens only if shared->use_function I believe. | 11:45.57 |
| Robin_Watts | sebras: hmm. | 11:46.09 |
| sebras | Robin_Watts: if !shade->use_function we assign temp = dest | 11:46.10 |
| | Robin_Watts: but you can't see that in the diff. | 11:46.18 |
| Robin_Watts | Right. | 11:46.23 |
| sebras | Robin_Watts: that's in the code just prior to this. | 11:46.24 |
| Robin_Watts | ok. That lgtm then. | 11:46.37 |
| sebras | Robin_Watts: I toyed with possibly splitting fz_paint_shade() into a use_function implementation and one do_not_use_function implementation. but I decided to leave that for later. I'm focusing on resolving the fuzz bugs at the moment. | 11:47.29 |
| | Robin_Watts: I got another three today. | 11:47.35 |
| Robin_Watts | sebras: All lgtm. | 11:47.43 |
| sebras | ok, thanks! I think tor8 wen't into hiding. | 11:48.01 |
| Robin_Watts | sebras: I am about to do the same to try and concentrate on refactoring this SSE stuff. | 11:50.50 |
| sebras | Robin_Watts: no worries. | 11:51.36 |
| | my idead is to bother tor8 in real life instead! that'll keep me occupied. | 11:52.10 |
| avih | tor8: hey, did you see my message about a week ago about -fPIC in libmujs.a? | 12:21.13 |
| tor8 | avih: gcc -fPIC -o libmujs.a one.c and you're done... | 12:35.53 |
| | -o libmujs.o I mean | 12:36.03 |
| | or override the CFLAGS variable | 12:36.34 |
| avih | i couldn't do that with CFLAGS, i think the makefile ignores prior values. also, not sure i get the gcc ... command. | 12:37.13 |
| tor8 | if you pass a variable on the make command line it overrides EVERYTHING in the makefile | 12:37.55 |
| avih | if i change at the makefile from CFLAGS := ... to CFLAGS ?= ... then i can override CFLAGS, but then lose whatever otehr flags the makefile sets | 12:38.19 |
| tor8 | so "make CFLAGS=foo" will make CFLAGS be "foo" and ignore everything in the makefile that changes CFLAGS | 12:38.22 |
| avih | this did not work for me, but i can retry | 12:38.47 |
| tor8 | variables set on the command line are hard overrides | 12:38.51 |
| | you will lose all the CFLAGS the makefile sets though | 12:39.08 |
| | one workaround is to add a second variable that CFLAGS depends on that you can set on the command line | 12:39.23 |
| | like XCFLAGS or something like that | 12:39.27 |
| | -CFLAGS := -std=c99 -pedantic -Wall -Wextra -Wno-unused-parameter | 12:40.03 |
| | +CFLAGS := $(XCFLAGS) -std=c99 -pedantic -Wall -Wextra -Wno-unused-parameter | 12:40.03 |
| | and the "make XCFLAGS=-fPIC" would that solve what you're trying to accomplish? | 12:40.17 |
| | my "gcc ... command" is just me telling you that you don't need the makefile to build | 12:40.34 |
| avih | i think so,. how common is XCFLAGS? | 12:40.40 |
| tor8 | all you need is to compile one.c and that's everything you need | 12:40.47 |
| avih | yeah, but you fixed it later, and i didn't see where is libmujs.a is generated, as it generates a ,o file | 12:41.17 |
| | .o * | 12:41.29 |
| tor8 | ar cru libmujs.a libmujs.o | 12:41.33 |
| avih | right, that's the missing part. | 12:41.41 |
| tor8 | if you need to package up the one .o file as a .a | 12:41.48 |
| | I have no idea how common XCFLAGS is | 12:42.07 |
| | XCFLAGS and XLIBS aren't "standard" by any means, but they're not exactly uncommon either | 12:42.59 |
| avih | do you think it should be supported via the makefile itself? e.g. ffmpeg and libass can create a static lib with PIC via makefile args (iirc ffmpeg with --with-fpic, and libass with.. a similar thing) | 12:43.03 |
| tor8 | why do you want a static library with position independent code? | 12:43.32 |
| avih | to create a statically linked bigger lib | 12:43.50 |
| tor8 | that's just making everything slower than it needs to be | 12:43.53 |
| avih | that's true | 12:43.59 |
| tor8 | if you want a bigger static library made of smaller libraries, just combine the object files...? | 12:44.27 |
| avih | well.. depends if it's 32 or 64, but yes, PIC can make things less optimized | 12:44.37 |
| tor8 | a .a library is just a file archive without compression | 12:44.49 |
| avih | a shared library which is comprised of static libs | 12:45.18 |
| tor8 | right. then you do need -fPIC. | 12:45.44 |
| avih | basically libmpv with all its stuff baked in | 12:46.10 |
| | which includes ffmpeg, libass and potentially libass | 12:46.23 |
| | mujs* | 12:46.30 |
| tor8 | I'll add XCFLAGS to the makefile and you can work from there. | 12:46.44 |
| avih | so you think it shouldn't be supported officially via an explicit arg? (i don't know how common such use case is) | 12:47.35 |
| tor8 | "make XCFLAGS=-fPIC" is good enough for me | 12:47.56 |
| | I don't want a bajillion different configurations | 12:48.08 |
| avih | i don't disagree | 12:48.14 |
| Robin_Watts | avih: If we were using configure, then --with-fpic would be appropriate. | 12:48.23 |
| | But we're not. | 12:48.27 |
| avih | right. in ffmpeg it's indeed with configure | 12:48.38 |
| tor8 | configure would be overkill for a library that consists of building one extremely portable source file | 12:49.13 |
| avih | tor8: any reason to use "make XFLAGS=.." rather than supporting "XFLAGS=... make .." ? | 12:49.29 |
| Robin_Watts | avih: tomato tomato | 12:50.00 |
| avih | (i wasn't aware that passing it as argument to make overrides :=) | 12:50.13 |
| tor8 | avih: both work, but setting them on the command line will work on other shells too and not jsut bash-alikes | 12:50.18 |
| | if you set it on the command line, that is a hard override | 12:50.44 |
| avih | i thought this syntax was posix, isn't it? | 12:50.44 |
| tor8 | avih: let me know when windows is posix :) | 12:50.58 |
| avih | :) | 12:51.05 |
| tor8 | and I'm sure there are a few csh die hards still alive... | 12:51.10 |
| avih | can it be don with csh? | 12:51.22 |
| tor8 | if you set it in the environment, it doesn't override as hard | 12:51.24 |
| avih | done* | 12:51.26 |
| tor8 | yes. I'm just not sure of the syntax. | 12:51.33 |
| | it might be the same, who knows | 12:51.40 |
| avih | right, and yes, good reason. it is more explicit this way too | 12:51.49 |
| tor8 | it's been over a decade since I had the misfortune of being subjected to csh though :) | 12:51.55 |
| avih | metoo probably. actually, make it two decades :) | 12:52.16 |
| | thanks :) | 12:52.40 |
| tor8 | yeah, two decades is actually more like it | 12:53.54 |
| | 1997 or thereabouts | 12:53.59 |
| avih | same :) | 12:54.04 |
| | tor8: isn't it more common to add user flags at the end such that they can override the built ins? | 12:59.10 |
| tor8 | if you want to override the builtins, you can override the whole CFLAGS... | 13:01.26 |
| | if you want that level of control, I say just compile the damn C file and stop trying to abuse the makefile | 13:02.36 |
| avih | the point is that you can get nicer customization for free by just moving its position | 13:16.22 |
| kens | paulgardiner : the bug report you;ve opened, can you attach a file that isn't an 'eml' file ? | 13:19.25 |
| | In particualr a file that doesn't have the email headers would be a start :-) | 13:19.52 |
| paulgardiner | Strange. Wasn't aware I'd done that | 13:20.11 |
| | Which bug? | 13:20.28 |
| kens | Well, when I download it from Bugzilla, it comes out as a .pdf.eml file and if I open it in VS it has an email header and a base64 encoded content | 13:20.46 |
| | 698918 | 13:20.55 |
| | Possibly 698919, haven't looked at it yet | 13:21.14 |
| | 698919 is OK | 13:21.48 |
| paulgardiner | Oh, I see what I've done. Idiot | 13:22.24 |
| kens | The Hebrew file is missing several fonts | 13:22.26 |
| | Especially Arial,Bold | 13:22.46 |
| paulgardiner | I guess those fonts must be built in within other readers | 13:23.05 |
| kens | Or they are using the Window ArialBoldMT (like Acrobat) | 13:23.20 |
| | GS substitutes Helvetica | 13:24.01 |
| | And much of the Hebrew is entirely missing. I'm afraid that's what happens when you use fonts and don't embed them, the substitute font may not have the missing glyphs, or not encoded in the same place | 13:24.59 |
| | The text in Arial is OK (font is embedded) the text in Arial,Bold is not (font not embedded) | 13:26.19 |
| paulgardiner | Shouldn't we be trying to match the substitution mechanism of Acrobat? | 13:32.04 |
| kens | I doubt we can. If you supply Ghostscript with ArialMT-Bold.ttf as a substitute for Arial,Bold, which is common, I expect it will work. | 13:32.41 |
| | But what should we do on a Linux system which doesn't have that font ? | 13:32.54 |
| | Adobe can ship fonts, they are a font foundry after all, amongst other thigns | 13:33.07 |
| | And in the absence of the original font on the system, Acrobat can be just as bad. | 13:33.23 |
| | Its simply lucky for you that hte missing font is widely available on Windows systems, and you are (presumably) using Windows | 13:33.44 |
| paulgardiner | It's results from our tester running MuSO on an iPad. | 13:34.23 |
| | He was comparing the results with Foxit. | 13:34.45 |
| kens | Well then I guess they also have Arial available, or are using a substitute font which is copatible. | 13:34.48 |
| | I've no idea what Foxit ships with. | 13:35.00 |
| | Also I presume this is MuPDF, I don't know what you guys do with missing font substitution | 13:35.29 |
| paulgardiner | Yeah MuPDF | 13:35.43 |
| kens | As I said, I could fix it in Ghostscript by supplying the missing font as a substitute | 13:35.45 |
| paulgardiner | Yeah, so possibly it's more of a MuSO problem than a MuPDF problem. | 13:36.18 |
| kens | Umm, could be, I was just commenting on it really | 13:36.44 |
| paulgardiner | Yes, useful thanks Ken | 13:36.55 |
| kens | Looks like your annotation object number 222 is broken | 13:46.42 |
| | Must admit I can't immediately see why | 13:48.27 |
| | Wellfixing the broken annotation just egts to the next broken annotation.... | 14:06.05 |
| malc_ | tor8: the commit message of 57d7b61fe408e585802dbc953d7d19eaeac1e533 states - "Shifting into the sign bit is undefined behavior." per my reading of the standard text (6.5.7#4) shifting of negative value is outlawed not shifting into the sign bit.. am i missing something? | 15:12.23 |
| tor8 | malc_: yes, bad formulation on my part. | 15:21.32 |
| malc_ | tor8: gotcha | 15:23.35 |
| adam1 | greetings! i was hoping to ask a question about the mupdf build process | 18:23.46 |
| | I am trying to build without the /generated content | 18:23.56 |
| | i.e. the large files for the fonts, encoding, etc | 18:24.04 |
| | is this easily possible or is it tied in too deeply? | 18:24.17 |
| | sebras had helped me with a problem a few weeks ago from walking the pdf dom | 18:25.13 |
| | i'm trying to build with the minimal set of libraries, which after some ldd work i've cut down about half | 18:38.58 |
| | but those big files are still crapping on my cross compile | 18:39.11 |
| | i can build in my regular dev environment just fine | 18:39.22 |
| tor8 | adam1: you need several of those files for PDF support | 18:43.58 |
| adam1 | even if i just want to walk the dom? | 18:44.19 |
| tor8 | but you can slim down the number by setting some #defines (and removing the corresponding files, we rely on the linker to drop the unused ones) | 18:44.21 |
| | adam1: unfortunately yes, some bits in the guts are a coupled so that it's non-trivial to exclude the CMap and font resources | 18:45.11 |
| | though you may need to clarify "walk the dom" | 18:45.27 |
| | build with XCFLAGS="-DTOFU -DNOCJK" and you should only need to generate the base14 fonts (the ones in resources/fonts/urw/) | 18:46.39 |
| adam1 | after checking dependencies i do need cmap | 18:46.41 |
| tor8 | then you can remove the other resources/fonts/* directories and they should be skipped | 18:47.21 |
| | with -DNOCJK you shouldn't need the CMap files either | 18:48.15 |
| | but then you should be aware that you won't be able to read the text in any PDFs with CJK fonts or scripts | 18:48.36 |
| adam1 | i can just add that to just before my makefile linkstep? | 18:48.49 |
| | this is my code: https://pastebin.com/keqtnXQy | 18:51.57 |
| tor8 | I would guess so; I haven't tried it in a while but I don't think we've changed anything that would prevent what I suggested from working. | 18:53.42 |
| adam1 | btw, here's example output from that code, explains what i mean by walking the dom (or at least i think so) | 18:56.06 |
| | https://pastebin.com/DcsaiDPT | 18:56.07 |
| tor8 | adam1: you know you could write that kind of tool using a 'mutool run' script in javascript, right? | 19:00.35 |
| adam1 | yea, but for platform reasons i have to use c | 19:01.05 |
| | and it is in fact mostly a mutool hack job | 19:01.20 |
| | hmm, so i tried the XCFLAGS trick, and still got the generated directory full of c files | 19:12.26 |
| tor8 | did you also remove the font resource files? | 19:14.39 |
| malc_ | tor8: you once explained the rationale behind using C generation instead of incbin or objcopy, but i can't recall it anymore, care to repeat? | 19:14.46 |
| tor8 | malc_: cross compilation. portability. | 19:14.59 |
| adam1 | not sure about the font resource files | 19:15.16 |
| | i did a make nuke | 19:15.20 |
| malc_ | tor8: incbin takes care of the first, the second is a problem yeah | 19:15.34 |
| tor8 | lots of compilers and OSs, different levels of incbin/objcopy support | 19:15.35 |
| adam1 | i just need to delete /resources/fonts | 19:15.53 |
| | ? | 19:15.54 |
| tor8 | adam1: rm resources/fonts/noto/* resources/fonts/han/* resources/fonts/droid/* resources/fonts/sil/* | 19:16.11 |
| malc_ | du -bh generated | 19:16.20 |
| tor8 | you need to keep resources/fonts/urw | 19:16.20 |
| malc_ | 42M generated | 19:16.20 |
| | is atrocious though | 19:16.30 |
| | and that's only compiled stuff, generated in topdir: | 19:17.13 |
| | du -bh generated | 19:17.14 |
| | 168M generated | 19:17.14 |
| | sigh | 19:17.18 |
| tor8 | malc_: blame the ancients for inventing so many damned different alphabets and scripts ;) | 19:18.00 |
| adam1 | lol | 19:20.15 |
| malc_ | tor8: i'd rather blame ISO for not making incbin/objcopy standard :) | 19:21.03 |
| adam1 | cool, that did cut the number of generated files down to about a third | 19:21.35 |
| | but the pdf-cmap ones are the ones that are really killing me | 19:21.51 |
| | and they remain | 19:21.53 |
| | :( | 19:21.55 |
| | so i guess no way to run mudpf with out the cmap stuff i guess? | 19:23.49 |
| tor8 | adam1: make "XCFLAGS=-DNOCJK" "CMAP_GEN=" | 19:24.37 |
| adam1 | okay, let me try that too | 19:25.12 |
| | i'd set that at the top of the makefile, or in my build step? | 19:26.38 |
| tor8 | make CMAP_GEN= FONT_GEN= "XCFLAGS=-DNOCJK -DTOFU -DTOFU_BASE14" | 19:26.47 |
| | that should do the trick for building a completely resourceless (and dysfunctional) mupdf | 19:27.01 |
| | use that line for your build step | 19:27.17 |
| | and it should build without needing to delete font files or anything else | 19:27.26 |
| adam1 | oh wow, that did the trick | 19:37.38 |
| | only icc-profiles.c was left | 19:37.44 |
| | which should be manageable | 19:37.53 |
| | tor8: many many thanks | 19:38.00 |
| fredross-perry | tor8, sebras - I am using Document.save() (not the new streaming save) to save a file. It calls pdf_save_document(), which is failing. When we get to fz_new_output_with_path(), if append is zero (it is for this particular file), it first removes the file, but then proceeds to open the file with "rb+", which fails because it doesn't create the file. I think it should open the file with "wb" in this case. I tested this and it | 23:06.40 |
| | works. Thoughts? | 23:06.41 |
| sebras | fredross-perry: this sounds like paul's accidentally introduced bug fixed in a55835a7 | 23:37.17 |
| | fredross-perry: if you don't have that patch in your tree, you probably need to rebase it. | 23:37.36 |
| fredross-perry | i'll see, | 23:37.44 |
| | looks familiar. Ill grab it and see. | 23:38.30 |
| | Paul's fix *almost* works. It fails if "rw+" is used, but wrks if "wb" is used. Could be a platform difference? | 23:50.21 |
| | sorry, scratch that. It fails if "wb+" is used, but works if "wb" is used. For the append=0 case. | 23:51.25 |
| | iow, this works: file = fopen(filename, append ? "rb+" : "wb"); | 23:51.38 |
| | paulgardiner ^^^ | 23:52.08 |
| paulgardiner | That's weird. Do you know why wb+ fails? | 23:55.05 |
| | Maybe we would be better off creating an empty file before opening in the non-append case and then always opening rb+ | 23:57.47 |
| | Forward 1 day (to 2018/01/25)>>> | |
Log of #mupdf at irc.freenode.net.