| | <<<Back 1 day (to 2018/09/10) | 20180911 |
| moolc | sebras: another ghostscript update just arrived.. damn | 05:24.35 |
| delrier | @sebras I'm not sure if I'm accidentally using the system lcms | 06:56.30 |
| | sebras: I wrote down my build steps in the issue :) | 06:56.59 |
| | sebras: is the lcms bundled in the ".so" file or loaded during runtime from the system? | 06:58.38 |
| kens | depends how you build and if you have a system version of lcms. Our fork of lcms is in the 3rd party libraries shipped with MuPDF sources, I believe | 06:59.24 |
| delrier | I run "make" in platform/java/ after cloning & updating the repo :p | 07:19.53 |
| kens | Yeah I can't really help you there, though that sounds correct. Note however that sebras was unable to reproduce your problem, using the code you supplied. | 07:20.24 |
| delrier | I'll try reading the make-file and see if I'm missing something | 07:20.27 |
| | yeah, hopefully I'm building it wrong :) | 07:20.47 |
| kens | Its only a theory, it could be something else, but its hard to debug a problem if you can't reproduce it :-( | 07:21.07 |
| tor8 | delrier: with those build steps you should be picking up our lcms2 fork, so that doesn't seem like it. | 09:58.55 |
| moolc | tor8: why do you keep autoconf/make/etc stuff in the forks? There's a lot of dead weight there lcms2's m4 directory alone is +300k.. and just uhm... autogened scripts are ~1.5M... | 10:05.51 |
| avih | tor8: is there a reason you don't push the mujs getopt fix to master? | 10:17.55 |
| | and unrelated, do you plan to merge the test262 PR? any comments on it? | 10:19.18 |
| tor8 | avih: I've been busy. I pushed the getopt fix just now. | 10:59.07 |
| avih | tor8: np. do you plan to consider merging the test262 PR at some stage? | 10:59.34 |
| tor8 | moolc: because we don't want to make broader adoption of our forks more difficult | 10:59.38 |
| | avih: yes. | 10:59.48 |
| avih | k, thx | 10:59.53 |
| tor8 | but I won't have time to do so this week | 11:00.05 |
| avih | np. not in a hurry, was just wondering. | 11:00.41 |
| delrier | tor8: are there any requirements on the envorinment (os, jre, etc) that might cause issues? | 11:24.51 |
| avih | tor8: huh, does adding a comment /* fallthrough */ make gcc not show warnings?! | 11:27.26 |
| | related* warnings ) | 11:28.31 |
| | :) | 11:28.33 |
| moolc | tor8: are you meaning to tell me that those configure/cmake/whatever stuff get some testing and don't get stale? | 11:29.38 |
| sebras | moolc: some of the thirdparty stuff we depend on we use their git for, so if they check in build files the thirdparty subfolder will have them too. | 11:38.25 |
| | moolc: we try to make as little changes as possible to these upstream projects to make it easier for us to update. | 11:39.07 |
| moolc | sebras: sure, but i don't think it's an excuse to ship those multimegabyte _autogenerated_ files and/or their support cruft | 11:40.01 |
| sebras | moolc: you mean in the release tarballs? | 11:41.26 |
| moolc | sebras: i mean in mupdfs git tree | 11:41.43 |
| sebras | moolc: for git clone --recursive it would be a bit difficult to get rid of... | 11:41.45 |
| moolc | sebras: for submodules host in gs's git repo - i fail to see how it's difficult | 11:42.35 |
| | s;host;hosted | 11:42.42 |
| sebras | moolc: I don't know enough about how gs build to say anything about it. | 11:43.20 |
| moolc | sebras: i meant git.ghostscript.com hosted mupdf, not gs itself | 11:43.55 |
| sebras | s/build/builds/ | 11:43.56 |
| | moolc: if you look at http://git.ghostscript.com/?p=thirdparty-freetype2.git;a=summary you will find that this is a mirror of the upstream git. | 11:44.47 |
| moolc | sebras: erm, how do i _see_ that? | 11:46.17 |
| sebras | moolc: for other thirdparty submodules such as zlib and libjpeg they are the upstream's unmodified release tarballs. | 11:47.51 |
| moolc | sebras: zlib and libjpeg do not use (auto/c)make | 11:48.25 |
| sebras | moolc: git clone git://git.ghostscript.com/thirdparty-freetype2.git && cd thirdparty-freetype2 && git remote add upstream git://git.sv.nongnu.org/freetype/freetype2.git && git fetch upstream && git log --graph --decorate --oneline --parents --branches --tags --remotes HEAD and you'll see that the origin/master and upstream/master and other branches correspond. | 11:49.10 |
| moolc | sebras: freetype does NOT use automake, bad example IOW | 11:50.54 |
| sebras | moolc: I didn't say that they were. I just wanted to explain that for some upstream projects we use a mirror of their git, and for some others we use their tarballs. if we can get away with not modifying anything in the thirdparty stuff we strive to do so. | 11:51.07 |
| moolc | sebras: and i'm just saying that it wastes space and bandwidth, that's all | 11:51.47 |
| sebras | tor8 delrier: oh, I think I may have stumbled oved a file that reproduces your issue. | 20:40.09 |
| | do you get any message along the lines of: warning: lcms error: not an ICC profile, invalid signature\nerror: cmsOpenProfileFromMem failed"? | 20:40.34 |
| | in one file I had an object that is using an ICC profile, and its background is red just like the one you reported. | 20:41.16 |
| | Robin_Watts: I need guidance for a bug in template_affine_N_near_fb0() (likely related to delrier's issue mentioned above). | 21:33.54 |
| | Robin_Watts: I'm seeing template_affine_N_near_fb0() being called with sa == 0, sn == 1, da == 1, dn == 3 this cause us to end up in the code the source's only component is copied over to the first component of the destination, next zeroing the remining two before setting the alpha to 255. | 21:35.28 |
| | no wonder that the drawn area appears as red. | 21:35.41 |
| | however, I'm not entirely sure if the error is in this function or that this function is ever called. | 21:36.03 |
| | to me it seems strange to only set the first component of an RGB destination, leaving the others zero, when the source is grayscale. | 21:37.31 |
| | Robin_Watts: I reproduced this with has-red-backgrounds-on-page-150.pdf on casper. with a patch like https://pastebin.com/raw/EdCr74TH the problem is cured, but I believe that patch is wrong. | 21:40.10 |
| | Robin_Watts: hm... we used a different paint function before. I think the problem started with commit 38620dea1512581a65350955cebb1028063ce42b which changed how eop is supplied/checked | 21:55.08 |
| | Robin_Watts: thus I blieve that this change is necessary, but I'm on very deep water here... http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=94df781c7 | 21:55.31 |
| Robin_Watts | sebras: I'll have to look tomorrow, sorry. | 23:00.35 |
| | The first patch is definitely wrong. | 23:14.15 |
| | The second one is more plausible, but I need to refresh my memory to be sure. | 23:14.32 |
| | Forward 1 day (to 2018/09/12)>>> | |
Log of #mupdf at irc.freenode.net.