| | <<<Back 1 day (to 2018/04/03) | 20180404 |
| tor8 | Robin_Watts_: oops, I messed up yesterday. I pushed the commit without actually having run the cluster test first :(. there's a "Fix silly typo" commit that should fix things at the bottom of tor/master | 10:30.39 |
| Robin_Watts_ | tor8: lgtm | 11:24.38 |
| Hufokus | Hello! Does fz_new_image_from_pixmap create a fz_image on heap? Cos' it seems like it drops after leaving an area where it was created | 11:31.59 |
| Robin_Watts_ | Hufokus: Yes, the fz_image is a heap allocated thing. | 11:41.59 |
| | That function returns a reference to the created image. When you are done with it, you should fz_drop_image. | 11:42.22 |
| moolc | tor8: any thoughts on pt astra? | 12:29.14 |
| sebras | tor8: sorry, I ought to have caught that in the review. :-/ | 14:15.24 |
| tor8 | sebras: no worries, I caught it and fixed it. | 14:28.17 |
| | sebras: I've recreated my scripts to munge on the CMap resources | 14:28.37 |
| | and a cmapdump python script, so we don't need the awkwardly bootstrapped cmapdump.c tool | 14:28.56 |
| sebras | tor8: is there any occurence where PDF_MAKE_NAME(a,b) where a is not the stringification of b..? | 15:59.08 |
| Robin_Watts_ | sebras: I can't find PDF_MAKE_NAME anywhere. | 16:06.48 |
| | Oh, is that in tor8's new commit? | 16:06.57 |
| sebras | Robin_Watts_: on tor/master you can. | 16:07.01 |
| | Robin_Watts_: yes. | 16:07.07 |
| Robin_Watts_ | And now I understand your question :) | 16:07.15 |
| sebras | Robin_Watts_: he gets rid of namedump. | 16:07.18 |
| Robin_Watts_ | oh, crumbs, ew. ew. ew. ew. | 16:07.52 |
| | Actually, maybe I take that back. | 16:09.17 |
| | Maybe just a single 'ew' :) | 16:09.23 |
| sebras | tor8: I'd like for the PDF_NAME(X) macro to stay the same as it was, so perhaps PDF_ENUM_X can simply be PDF_NAME_X? | 16:09.46 |
| | Robin_Watts_: what's the ew? | 16:10.45 |
| Robin_Watts_ | The idea of using PDF_NAME(Foo) instead of PDF_NAME_Foo is 'ew'. | 16:12.05 |
| | but I see the attraction of dropping namedump, and I can probably live with it. | 16:12.22 |
| sebras | Robin_Watts_: both would work for me, but I see no reason to change it really. :) | 16:12.37 |
| Robin_Watts_ | sebras: Removing the need to build *any* tools would be nice. | 16:13.23 |
| | but I don't think we can get there. | 16:13.28 |
| sebras | tor8: in source/pdf/pdf-object.c you under PDF_MAKE_NAME2, but it should be PDF_MAKE_NAME | 16:13.37 |
| | Robin_Watts_: any step in that direction would be good. | 16:13.54 |
| | Robin_Watts_: but I presume that the worst one is the fonts. | 16:14.05 |
| Robin_Watts_ | sebras: If we can't stop the fonts, then I don't see the advantage in stopping the names. | 16:14.31 |
| | Oh, and "Identity-H", Identity_H etc. | 16:16.31 |
| sebras | Robin_Watts_: yes. | 16:16.41 |
| Robin_Watts_ | That's where string != constant. | 16:16.45 |
| sebras | Robin_Watts_: ah, I see. | 16:17.17 |
| | Robin_Watts_: how annoying. | 16:17.23 |
| Robin_Watts_ | indeed. | 16:17.37 |
| sebras | Robin_Watts_: oh hexdump is used to dump the icc-profiles too. | 16:17.47 |
| | Robin_Watts_: and our embedded javascript. | 16:18.04 |
| | Robin_Watts_: somehow I feel that if we can afford to process the cmaps using a script, and check in its result, we should be able to afford that for fonts/icc/whatever too. | 16:18.46 |
| | Robin_Watts_: the key to doing so is that these files must not be updated frequently, which I believe is true for all of our resources. | 16:19.23 |
| Robin_Watts_ | sebras: it means we end up bloating the git repo, but disc space is cheap. | 16:20.19 |
| | and releases are much larger. | 16:20.51 |
| | Personally, I think I'd like to leave stuff as being generated on the fly, but to offer a separate release 'generated' zip each time. | 16:23.09 |
| sebras | Robin_Watts_: source code releases are larger of course, but .apks wouldn't be e.g. | 16:23.18 |
| Robin_Watts_ | sebras: Indeed. | 16:23.33 |
| | I guess the big question is, can premake generate appropriate makefiles/project files? | 16:24.06 |
| sebras | Robin_Watts_: and pulling from the git repo wouldn't really matter. cloning it anew would cause bandwidth increases though. | 16:24.17 |
| Robin_Watts_ | yeah. | 16:24.37 |
| sebras | Robin_Watts_: LGTM on sebras/master? | 16:44.08 |
| Robin_Watts_ | looks plausible to me, sure. | 16:44.54 |
| tor8 | sebras: yes, Identity-H and adobe.pkcs7.foo etc aren't the pure stringification | 17:17.47 |
| | I'd rather double them than risk mis-sorting by using separate macros | 17:17.58 |
| | and yes, it's a single 'ew' but loses an extra build step | 17:18.25 |
| | Robin_Watts_: I've managed to get rid of the cmapdump compile step too, and I expect we can keep the icc profiles and such checked in | 17:18.51 |
| | leaving only the font blobs | 17:18.54 |
| | which, with a decent compiler chain, can be built using tools like objdump | 17:19.16 |
| Robin_Watts_ | Right, but unless we can get rid of the generation step for the font blobs, I don't see the advantage in any of it. | 17:19.28 |
| tor8 | I think we'll just bite the bullet and check in the font file resources too, but there is one potential issue with it | 17:19.49 |
| | with linux, we get decent compile speeds and memory use by using gargantuan string literals | 17:20.12 |
| | but MSVC chokes on big string literals | 17:20.21 |
| Robin_Watts_ | Personally, I think we should leave the generation stuff as it is now, with the additional thing that we should offer a 'generated.zip' with every release we do. | 17:20.24 |
| tor8 | the generation stuff is easily the number one complication with our build system | 17:21.40 |
| Robin_Watts_ | Yes, but it's not a big complication. (Or at least it shouldn't be) | 17:22.02 |
| tor8 | cmapdump.c is a particularly nasty hack, but I wrote a replacement script in python | 17:22.25 |
| | and I don't expect those resource files to ever change, so checking in one generated 2.5Mb C file should be good enough and then we won't have to worry about that step ever again | 17:23.05 |
| Robin_Watts_ | Right. I can live with a 2.5Meg C file for the CMAPs. | 17:23.26 |
| tor8 | the 100M for font files is more icky | 17:23.37 |
| Robin_Watts_ | Generating the font files is not a huge issue. | 17:23.56 |
| | And for cases where it is (java/ndk users), generated.zip | 17:24.22 |
| tor8 | on linux, you can abuse the linker to create object files from binary data | 17:25.12 |
| | yes. but reducing it to one set of files would ease my mind (hence me working to eliminate namedump and cmapdump) | 17:27.10 |
| Robin_Watts_ | tor8: At the moment people can subset the cmap files, right? Does that still work with a single checked in source file? | 17:35.56 |
| | I bet it doesn't. | 17:35.59 |
| tor8 | Robin_Watts_: it's no worse than it was before :) | 17:36.18 |
| | we had some superset cmap files, but I think we can safely drop those | 17:36.32 |
| | our cmap subsetting is basically an all-or-nothing deal | 17:37.02 |
| Robin_Watts_ | What I'm saying is that it would be better if we had a directory full of .h files, and a .c file that #included them. | 17:37.25 |
| | Then we can have #ifdeffery to choose which subsets to include. | 17:37.45 |
| tor8 | Robin_Watts_: one .h file per CMap resource? | 17:37.49 |
| Robin_Watts_ | yes. | 17:37.55 |
| tor8 | yeah, I think we could do that easily enough | 17:37.56 |
| Robin_Watts_ | Hmm, there may be a better way. | 17:47.53 |
| | Suppose we had each cmap resource as a .c file that built to a .o, each defining a single symbol cmap_foo.c defining cmap_foo, say | 17:48.36 |
| | Then we have an fz_register_cmaps(blah) call. | 17:49.01 |
| tor8 | Robin_Watts_: that's almost what we do for the font file subsetting (letting the linker drop the unused objects) | 17:49.14 |
| Robin_Watts_ | where blah can be fz_all_cmaps, or fz_japanese_cmaps, etc. | 17:49.25 |
| | As long as fz_all_cmaps/fz_japanese_cmaps etc are defined in their own .c files, we can build static libs that have all the cmaps in, and then have them linked in according to what the programmer wants. | 17:50.35 |
| | so subsetting happens at link time, as you say, like the font ones. | 17:50.58 |
| tor8 | I was thinking something like the last commit on tor/master | 17:53.10 |
| Robin_Watts_ | tor8: Right, so that won't allow us to drop at linktime. | 17:54.32 |
| | but it's close. | 17:54.38 |
| tor8 | selecting subsets of CMaps is (IMO) less useful than for fonts | 17:54.55 |
| | either you'll likely want all of the CJK support, or you don't want any of it | 17:55.09 |
| Robin_Watts_ | instead of static pdf_cmap *table, have a separate .c file with pdf_cmap *fz_all_cmaps | 17:55.17 |
| | And another separate .c file with pdf_cmap *fz_noncjk_cmaps | 17:55.43 |
| tor8 | all except Identity-H and Identity-V are CJK cmaps. *maybe*, just *maybe* someone wants only the C or J or K CMap resources | 17:56.18 |
| | but then doing some #ifdeffery when building pdf-cmap-load.c similar to what we do in noto.c | 17:56.38 |
| Robin_Watts_ | Then fz_add_cmaps(blah) can just add the sets that the programmer wants. | 17:56.40 |
| | Having an fz_add_cmap mechanism enables people to add their own later if required too. | 17:57.35 |
| | I dunno, I like configurability like this, maybe it's overkill. | 17:57.58 |
| tor8 | the ones I build in now are the set listed in the PDF reference, and no more | 17:58.04 |
| | as well as 4 AdobeCID-to-Unicode for ToUnicode and font substitution purposes | 17:58.52 |
| | Robin_Watts_: yeah. if there was a compelling use for the configurability, that is the way I would go about it. | 17:59.24 |
| | I think I prefer a separate file for each CMap resource; that will make it easier on git when adding/removing/updating resources in the future | 18:00.24 |
| | I sort of wish the cmyk.icc profile could be smaller, but I see michael has already squeezed it a lot smaller than most CMYK ICC profiles I can find in the wild | 18:00.59 |
| Robin_Watts_ | A separate file for each CMAP resource does seem sensible, yes. If only because it makes it easier for people to add/drop ones infuture. | 18:01.55 |
| tor8 | yeah. easy to just comment out/ifdef out the ones you don't want | 18:02.22 |
| jogux | evening. can anyone tell me how to build mupdf with memento enabled? ideally on iOS but I'll settle for any hints at all :) | 18:24.56 |
| tor8 | jogux: -DMEMENTO | 18:25.33 |
| jogux | thanks | 18:25.48 |
| tor8 | 'make build=memento' should do the trick if using the makefile | 18:25.50 |
| jogux | if I've already built mudf, will building again with build=memento make it rebuild? | 18:31.57 |
| tor8 | jogux: with build=memento it will build a fresh copy in a separate build/memento directory | 18:32.58 |
| | each build configuration has its own destination directory | 18:33.07 |
| jogux | hmm. something not right then | 18:33.40 |
| | does this look like it should work: make -j1 -C ${MUPDF_PATH} OUT=$OUT XCFLAGS="$FLAGS" XLDFLAGS="$FLAGS" build=memento third libs || exit 1 | 18:33.49 |
| tor8 | jogux: yeah, you override the OUT (which build=memento normally sets to build/memento) | 18:35.37 |
| | jogux: with that command line, I'd just say XCFLAGS="-DMEMENTO $FLAGS" and rebuild | 18:35.54 |
| jogux | ahhhh. thanks. let me try that. this is Paul's build script, I don't know how/why he's doing various things :-) | 18:40.30 |
| | tor8: success, thanks. fred is carrying on looking at this, seems to be a freed object in the store or something (causing a crash in muso). | 19:10.53 |
| tor8 | Robin_Watts_: I think we may be able to use the windows resource compiler for win32 so we can skip generating files on windows at least | 22:47.29 |
| | and on linux/gcc-based systems we can use the linker | 22:47.39 |
| | Forward 1 day (to 2018/04/05)>>> | |
Log of #mupdf at irc.freenode.net.