| | <<<Back 1 day (to 2015/04/07) | 20150408 |
| mvrhel_laptop | ok I have the links always active now, and the button only highlights them | 00:01.18 |
| Robin_Watts | mvrhel_laptop: That's the simplified english way :) | 00:01.25 |
| mvrhel_laptop | I have ctrl mouse wheel doing zoom | 00:01.32 |
| Robin_Watts | Nice. | 00:01.37 |
| mvrhel_laptop | ctrl mouse wheel doing shift | 00:01.38 |
| Robin_Watts | ? | 00:01.49 |
| mvrhel_laptop | shift mouse wheel doing shifts | 00:01.59 |
| | hehe | 00:02.01 |
| Robin_Watts | shift mouse wheel doing horizontal scroll? right. | 00:02.13 |
| mvrhel_laptop | yes | 00:02.17 |
| | I actually needed that yesterday | 00:02.25 |
| | looking at some drawings of property lines zoomed in | 00:02.40 |
| rayjj | you added CUPS to the mupdf printer output (which I didn't know it did, at least not mudraw) and you took it out of GS, which is definitely does | 00:03.15 |
| | Robin_Watts: ^^^ | 00:03.25 |
| Robin_Watts | I added a paragraph that says both do it. | 00:03.46 |
| | (I intended to take it out of MuPDF) | 00:03.56 |
| rayjj | yes, later | 00:04.13 |
| Robin_Watts | yeah, we can lose the 'and CUPS' from the MuPDF line. | 00:04.42 |
| rayjj | Robin_Watts: after the Banding section you added some blank lines. I generally prefer not having this, but if this was intentional, fine by me | 00:08.01 |
| Robin_Watts | It all gets normalised when rendered. | 00:08.49 |
| | I prefer blank lines before each secton delimiter, personally. | 00:09.07 |
| | but it all looks the same in the end, I think. | 00:09.33 |
| rayjj | Robin_Watts: having to modify the code to get mupdf to do multi-threading is not what I read into "slightly more integration" | 00:09.40 |
| Robin_Watts | rayjj: It's pretty trivial. | 00:10.09 |
| rayjj | OK, I guess. But it isn't documented -- I see everyone asking you (or maybe tor) how to do it here on IRC | 00:10.57 |
| Robin_Watts | But don't take my word for it. Michael has done it for gsview. | 00:11.01 |
| | That *is* documented. | 00:11.08 |
| | see docs/multithreaded.c for an example. | 00:11.39 |
| | and docs/overview.txt for information on how to do it. | 00:12.07 |
| | We have customers who have used it for multi-core rendering on ipads etc. | 00:12.29 |
| rayjj | Robin_Watts: sorry -- I had out of date docs | 00:12.48 |
| Robin_Watts | np. | 00:12.53 |
| | I'm quite pleased with the way the threading stuff works in MuPDF. | 00:13.37 |
| rayjj | Robin_Watts: should we mention in the PDF Manipulation that both allow a password to be set when creating a PDF ? | 00:13.43 |
| Robin_Watts | MuPDF does not allow passwords to be set. | 00:13.58 |
| | Cos we don't write encrypted files. | 00:14.09 |
| | That could be a tick in the gs column. | 00:14.21 |
| rayjj | Robin_Watts: oh, so I'll add that for the GS section. That's was a commonly needed function | 00:14.28 |
| | it used to be done by a PS post processor program (pdf_sec.ps) until kens added it to pdfwrite | 00:14.57 |
| | Robin_Watts: OK, I added that statement. | 00:18.12 |
| | Have to run an errand. bbiab. Feel free to wordsmith my quick addition. | 00:18.36 |
| | what a mess. I've gotten the transfer function sorted out except for the need for the transfer function in the pdf14_put_image call to the device proc. Not sure how to solve that one without changing the params to dev_proc_put_image. mvrhel and I have discussed it briefly and may do just that | 04:16.16 |
| | but now I've discovered that if PDF sets a page level transfer function using the 'gs' operator (the /TR key to an ExtGState). Then we fail to apply the transfer function because the pdf14 device resets to the default transfer functions *BEFORE* the put_image | 04:21.41 |
| | if the page is banded, then the bands that skip the pdf14 compositor have the transfer function applied and the bands that use transparency don't | 04:22.24 |
| | I can fix (hack) the clist case by not updating the transfer function in the clist upon POP_DEVICE, but for the page mode, the imager state (gstate and ExtGState) is popped by the final 'Q' on the page (I think) so that when the pdf14_put_image is called the pis is different to the one that had the changed transfer function | 04:43.21 |
| | hmm... actually, it isn't the final 'Q'. It's in the PDF interpreter doing a grestore or restore. Even worse. | 04:45.44 |
| | Well, a workaround is to force clist mode :-/ | 04:46.17 |
| | mvrhel_laptop: (for the logs) Are we _sure_ that the pdf14 compositor should ignore the pis->effective_transfer in its cmap_procs ? If it applied it during rendering, it would avoid much of this tomfoolery (and we would reset the transfer function during pdf14_put_image and wouldn't have to change the device call) | 04:54.08 |
| | in any case, I'm running a test with my current approach | 04:55.01 |
| | and since it's "after hours" marcosw's systems are offline so it takes longer | 04:55.51 |
| | BTW, I'm pretty sure that the HEAD code applies transfer functions, if set as the default prior to starting the PDF, twice to color images and only once to monochrome images (if so, that's the same as bug 695904) | 04:59.26 |
| | or maybe it's once for color images and other graphics and not at all for monochrome images. Either way it's not right | 05:01.57 |
| | like I said, it's a mess | 05:05.40 |
| | just a reminder to whoever gives the newsletter info to Scott, make sure and mention 9.17 (not 9.16) | 05:32.19 |
| | that'll make the customer think they are getting something better (which they are since it includes Luratech decoders) | 05:32.59 |
| | of course some of our customers will probably request 9.16 since it is a day or two more stable ;-) | 05:33.51 |
| Robin_Watts | tor8: We forgot to update the docs based on the context changes. | 10:09.12 |
| | I'm looking at that now. | 10:09.18 |
| tor8 | ah, oops. | 10:10.52 |
| | maybe we should add the examples to the makefile... | 10:11.13 |
| Robin_Watts | the examples are fine, I think. | 10:11.49 |
| | It's the textual docs. | 10:11.54 |
| tor8 | docs/example.c doesn't build | 10:12.17 |
| Robin_Watts | no, the examples are borked too :( | 10:12.19 |
| | urgh. | 10:12.54 |
| | The examples will never build on windows either :( | 10:13.01 |
| tor8 | I'll fix the examples | 10:13.06 |
| | and add a 'make examples' makefile target so we can test them easily | 10:13.31 |
| Robin_Watts | tor8: Ok. | 10:13.39 |
| | All the declarations of variables should be moved to the top of blocks. | 10:13.52 |
| | tor8: Documentation update on robin/master. | 10:23.09 |
| tor8 | examples update on tor/master | 10:24.30 |
| | LGTM | 10:26.03 |
| Robin_Watts | lgtm. will push yours. | 10:32.19 |
| | Do you want to tag that as 1.7-rc1 ? | 10:32.42 |
| | I'll do the windows builds when I get back from running. | 10:32.58 |
| tor8 | need to update docs/thirdparty as well | 10:33.58 |
| Robin_Watts | oh. | 10:34.23 |
| chrisl | tor8: Sorry, I didn't get around to that yesterday.... I'll leave it to you | 10:34.38 |
| Robin_Watts | oh, right yes. | 10:34.40 |
| tor8 | which version of openjpeg are we on? | 10:35.06 |
| Robin_Watts | tor8: How would you feel about us changing the binding for backspace in the mupdf viewer? | 10:35.21 |
| | Instead of doing 'back one page', it should do 'back 1 history' (or back 1 page if there is no more history). | 10:35.46 |
| tor8 | Robin_Watts: I should backport the history handling from my opengl-based viewer... | 10:36.24 |
| Robin_Watts | tor8: there is already history handling in the viewer. | 10:36.46 |
| | see the code for 'm' and 't'. | 10:36.52 |
| tor8 | yeah, but it's funky and has odd corner cases | 10:36.54 |
| Robin_Watts | yeah, I could believe that. | 10:37.02 |
| tor8 | which have been fixed when I wrote the opengl based viewer | 10:37.03 |
| Robin_Watts | OK, that sounds like something for the next release then? | 10:37.16 |
| tor8 | I'm hoping to get the opengl based viewer in by next release | 10:37.29 |
| | but my holiday may make a mess of that plan... | 10:37.37 |
| Robin_Watts | runs. bbs. | 10:38.48 |
| chrisl | tor8: it looks like mupdf is still using openjpeg 2.0.0 (with patches) | 10:40.25 |
| tor8 | chrisl: thanks. | 10:40.40 |
| | so only the freetype version needs updating since last release | 10:40.50 |
| | jbig2dec looks like it's a few commits behind jbig2dec.git | 10:41.06 |
| chrisl | The openjpeg is a commit behind openjpeg.git, but I wouldn't change that right now - IIRC, there are build changes needed for the change to 2.1.0 | 10:42.01 |
| tor8 | yeah, not feeling the need to upgrade that now | 10:42.20 |
| | jbig2dec should be a simple update though | 10:42.29 |
| chrisl | The important thing is removing v8 and putting in mujs.... | 10:42.58 |
| tor8 | v8 is still optional, but I suspect it's bit-rotted to the point that it's even more trouble to get to work than before | 10:43.35 |
| chrisl | Well, at least put mujs in as the *highly* recommended default..... and move v8 somewhere off the bottom of the page | 10:44.27 |
| tor8 | I'll just nuke mention of v8 and add in 'mujs' to the note at the bottom next to jbig2dec | 10:45.08 |
| chrisl | I'm going out for some fresh air - maybe I can shake this headache before it grows roots.... back in a half hour or so. | 10:57.11 |
| kens | chrisl that's a right muppet you are dealing with there..... | 12:51.30 |
| chrisl | kens: I was beginning to wonder if it was you under a pseudonym having a laugh at me | 12:52.50 |
| kens | Cruel thought :-) | 12:53.04 |
| Robin_Watts | tor8: So, any more code changes to come? | 13:09.04 |
| tor8 | Robin_Watts: I got a jbig2dec update on tor/master but other than that, I hope not | 13:09.34 |
| Robin_Watts | ok. looks good to me. | 13:10.43 |
| | did you cluster test it? | 13:10.48 |
| tor8 | I have not | 13:14.18 |
| | but I am now | 13:14.39 |
| Robin_Watts | I just did. It's fine. | 13:17.34 |
| | So I'll push. | 13:17.51 |
| tor8 | thanks. | 13:17.57 |
| Robin_Watts | OK, so I'll tag that as 1.70rc1 and do the windows builds ? | 13:18.22 |
| | 1.7-rc1 | 13:18.28 |
| tor8 | Robin_Watts: okay | 13:19.27 |
| Robin_Watts | crap. | 13:33.36 |
| | windows builds are broken with epub. Trivial fix. | 13:34.10 |
| | Fix on robin/master | 13:35.34 |
| tor8 | ah, oops. | 13:36.15 |
| | LGTM | 13:36.17 |
| Robin_Watts | OK. Pushed, and I moved the tag. | 13:36.48 |
| tor8 | make sure to git fetch --tags to get updated tags | 13:37.33 |
| Robin_Watts | Hmm. | 13:42.14 |
| | mudraw, mupdf and mutool are all over 9Meg. | 13:42.25 |
| | I thought you'd tweaked mutool so that it didn't pull in the data again? | 13:42.54 |
| tor8 | the dependencies are too pervasive now, with the forms and annotation synthesis, to be easily cut | 13:43.21 |
| Robin_Watts | ok. | 13:44.46 |
| tor8 | I can give it another bash, but I am not hopeful | 13:44.58 |
| Robin_Watts | no, that's fine. I don't think it's a big deal. | 13:45.13 |
| | just didn't want to ship something that we thought we'd fixed. | 13:45.31 |
| tor8 | I think pdfclean pulling in the interpreter is the biggest culprit | 13:45.48 |
| | we could probably excise some of the contortions we did to separate the dependencies now | 13:46.17 |
| | the pdf-xref-aux.c file etc | 13:46.24 |
| | and the _no_run functions | 13:46.27 |
| | this is sort of why I asked if we should merge mutool and mudraw | 13:46.46 |
| Robin_Watts | ok. windows builds done. uploading to casper now. | 13:48.15 |
| | Android builds next I guess. | 13:48.27 |
| kens | This muppet is about to get his buig closed as 'worksforme' | 13:53.20 |
| Robin_Watts | OK. mupdf-1.7-windows.zip and mupdf-1.7-windows-64bit.zip are in my home dir on casper. | 13:57.31 |
| tor8 | kens: muppet still can't spell to -sDEVICE | 14:01.11 |
| | he went from -dEVICE to -sDEVIC | 14:01.19 |
| kens | Oh God..... | 14:01.21 |
| | I must have missed that, thanks tor8 | 14:01.32 |
| | How he can manage to get a simple command line wrong three times is beyond me. | 14:01.55 |
| Robin_Watts | kens: Just close the bug with "3 strikes and you're out". | 14:03.52 |
| kens | I was pretty close to that before tor8 pointed out this last blunder | 14:04.12 |
| chrisl | "Dear Sir, it is with regret that I have to inform you that you have proven too stupid to permitted to use our software. Please uninstall it immediately, and go stick your head in a bucket full of very cold water for at least 45 minutes" | 14:05.16 |
| kens | These people do medical devices, I'm tempted to mail them and say 'your developer should not be permitted anywhere near any kind of medical device' | 14:06.12 |
| Robin_Watts | chrisl: "If you wish to complain about this judgement please feel free to phone us up while your head is in the bucket" | 14:06.14 |
| kens | Hmm, his name's not Marvin..... | 14:06.27 |
| chrisl | He certainly does *not* have a brain the size of a planet....... | 14:06.50 |
| kens | Not even a dwarf planet | 14:07.08 |
| chrisl | I seriously hope this guy is not a developer! | 14:07.36 |
| kens | I suspect he probably is <shudder> | 14:07.49 |
| | That's 4 failed attempts..... | 14:13.56 |
| | Robin, a weirdness for you. If I use ctrl-wheel to zoom MuPDF 1.7, then the keyboard does nothing until I refocus the window by cliking on it. SO I can't zoom and then use left/right arrows for instance. | 14:16.13 |
| | Using just the mouse wheel I cna continue to scroll thorugh the document however. | 14:16.43 |
| Robin_Watts | kens: hmm. I think I've seen that too, but hadn't quite isolated the chain of events. | 14:16.59 |
| kens | I get the same just by using the mouse wheel | 14:17.12 |
| Robin_Watts | ok, will look into it. ta. | 14:17.39 |
| kens | I can use left/right, then I scroll through with teh wheeel, then I try left/right and it doesn't do anything | 14:17.43 |
| | But he executI wouldn't have noticed it except that I knew the zoom was new so I tried it | 14:18.18 |
| rayjj | morning, all | 14:39.40 |
| kens | Morning | 14:39.54 |
| Robin_Watts | morning rayjj | 14:40.00 |
| | tor8: I am confused by some code in win_main.c | 14:40.12 |
| | in handlekey. | 14:40.20 |
| | We call 'GetCapture' to get the handle of the window that has the mouse focus. | 14:40.40 |
| | And if that's our window, we bale. WTF? | 14:40.51 |
| xace | does mupdf have support to open a pdf and jump to a specific page? i've seen some pdf readers handle example.pdf#page=3 | 14:41.08 |
| Robin_Watts | xace: not currently. | 14:43.11 |
| tor8 | xace: the x11 viewer can take the page number as an optional command line argument | 14:44.58 |
| | but nothing for the mobile or windows viewers | 14:45.14 |
| Robin_Watts | stands corrected. | 14:45.14 |
| xace | tor8: that's fine, im linux... checking the man page once more | 14:45.31 |
| tor8 | Robin_Watts: trying to understand the GetCapture stuff | 14:45.37 |
| xace | tor8: how do you invoke mupdf with a page number? mupdf example.pdf 3 ? | 14:46.19 |
| Robin_Watts | Normally it seems cap returns NULL. | 14:46.30 |
| tor8 | Robin_Watts: I suspect it's to do with event cascading through the window hierarchy | 14:46.50 |
| xace | yeah, mupdf example.pdf 3 worked. tahnks | 14:46.52 |
| Robin_Watts | if (cap != NULL && cap != hwndview) return; would make some kind of sense to me. | 14:47.16 |
| rayjj | xace: congratulations on finding the answer yourself | 14:47.19 |
| xace | rayjj: my first attempts where on a single page pdf, realised my error after a while | 14:47.57 |
| rayjj | xace: yeah, it's a bit hard to got to page 3 of a 1 page file :-) | 14:49.10 |
| | hurray! Good morning, mvrhel_laptop | 14:49.53 |
| xace | yeah, confused file names: test1.pdf vs test.pdf | 14:49.58 |
| rayjj | mvrhel_laptop: I need to chat about PDF and transfer functions some more. Do you prefer here or on the phone ? | 14:50.46 |
| mvrhel_laptop | rayjj: here is better. kids are sleeping right now due to spring break and I would likely be too loud on phone | 14:51.16 |
| rayjj | mvrhel_laptop: yeah, same for my house | 14:51.29 |
| tor8 | Robin_Watts: I honestly have no clue, and git blame isn't helpful :( | 14:51.43 |
| | the change is hidden in commit 93cb0dacf164ac3e9d3e7089fc7d2f0beb7715b4 | 14:52.12 |
| | Robin_Watts: try just removing the line completely and see if anything breaks? | 14:53.06 |
| rayjj | mvrhel_laptop: so the problem with the current code is that transfer functions don't get applied to everything during during pdf14 compositing. I /thought/ the problem was that the pdf14 device really doesn't want the transfer function applied so that blending isn't borked | 14:53.58 |
| tor8 | if (cap != NULL && cap != hwndview) we wouldn't be called in the first place | 14:54.14 |
| Robin_Watts | tor8: Yeah, I'll fiddle. On the whole it seems to work without that line, but I get some wierdness with the mouse which may or may not be related. | 14:54.18 |
| tor8 | it might be that the function is called twice for every event if there's a capture | 14:54.56 |
| | once for the containing frame, and once for the view | 14:55.21 |
| Robin_Watts | I wondered that, but page up/page down is only being triggered once. | 14:55.22 |
| rayjj | mvrhel_laptop: if I disable transfer functions if the pdf14 device is in place, and it gets applied during the 'image' processing of pdf14_put_image, then things work somewhat | 14:55.23 |
| tor8 | do we redirect some mouse events to handlekey? there's also the difference between regular and special keys in the windows message queue | 14:55.58 |
| rayjj | mvrhel_laptop: but the cluster shows lots of problems with that. | 14:56.05 |
| Robin_Watts | tor8: We used to redirect mouse wheel events to keys. We don't any more. | 14:56.53 |
| rayjj | mvrhel_laptop: _and_ if the transfer function is not the default, but one set by and ExtGState /TR then it goes away before the pdf14_put_image | 14:57.03 |
| mvrhel_laptop | rayjj: just reading the spec about transfer functions and transparency | 14:58.37 |
| rayjj | mvrhel_laptop: and, BTW, as we discussed, relying on the transfer function to be applied during pdf14_put_image means that the dev_proc_put_image needs to get the pis or at least the pis->effective_transfer | 14:58.48 |
| mvrhel_laptop | very interesting | 14:59.04 |
| | reading | 14:59.27 |
| | and it sounds very tricky to do what they say | 15:00.38 |
| rayjj | mvrhel_laptop: yeah, I see that even a SMask has an optional TR, so clearly disabling TR during pdf14 composition won't work | 15:00.39 |
| mvrhel_laptop | page 573 of pdf vers 1-7 | 15:01.00 |
| rayjj | mvrhel_laptop: I'm reading 7.6.4 now | 15:01.10 |
| mvrhel_laptop | in section 7.6.4 | 15:01.20 |
| Robin_Watts | tor8: Ok, so button down and button up 'SetCapture' and 'ReleaseCapture'. | 15:02.14 |
| | And my mouse wheel changes cause a button down with no corresponding button up. | 15:02.36 |
| | So that's the issue there. | 15:02.40 |
| | ok. I have a fix then. | 15:04.09 |
| mvrhel_laptop | so each rect fill could potentially have a different transfer function but they are only applied if they are opaqe | 15:04.37 |
| | so we really need to be applying at the time of drawing | 15:04.51 |
| | but only if the object is opaque | 15:05.05 |
| | so doing the transfer function at the time of put image is not going to work | 15:05.31 |
| | we need to somehow turn that one off I am afraid to tell you rayjj | 15:05.52 |
| rayjj | mvrhel_laptop: right, I've come to that conclusion as well. Right now, we _sometimes_ get the transfer function applied twice doing it during put_image | 15:06.23 |
| mvrhel_laptop | sounds odd. | 15:06.48 |
| rayjj | it's easy to turn off the transfer function during put_image, AND that means we don't need it for the dev_proc_put_image | 15:07.01 |
| mvrhel_laptop | right | 15:07.19 |
| Robin_Watts | tor8: 1 commit on robin/master then. | 15:08.09 |
| rayjj | is re-reading 573-574 "Halftone and Transfer Function" ... | 15:08.31 |
| mvrhel_laptop | so what is interesting is that we need to do the application if the elementary object is opaque | 15:09.43 |
| | but not otherwise | 15:09.53 |
| Robin_Watts | mvrhel_laptop: That's an interesting titbit. | 15:10.08 |
| mvrhel_laptop | not sure what if means if I have a softmask gradient thrown in there | 15:10.23 |
| tor8 | Robin_Watts: LGTM | 15:10.31 |
| mvrhel_laptop | I suspect that is treated as not being opaque | 15:10.41 |
| | otherwise you would have an odd effect | 15:10.46 |
| chrisl | So are we applying the transfer pre-blending? | 15:11.09 |
| Robin_Watts | tor8: I'll update the tag and rebuild for windows. | 15:11.15 |
| | the android apps will be unchanged. | 15:11.24 |
| mvrhel_laptop | where at the points of opaqeness (is that a word) do you apply the transfer function | 15:11.30 |
| rayjj | mvrhel_laptop: the SMask must be None according to the third bullet | 15:11.48 |
| mvrhel_laptop | ah ok good | 15:11.56 |
| rayjj | (second bullet on p 574) | 15:12.13 |
| | mvrhel_laptop: the word is opacity, I think | 15:12.58 |
| mvrhel_laptop | yes ;) | 15:13.24 |
| | rayjj: to me it looks like there is some work to do in the interpreter for these conditions | 15:14.24 |
| | item 4 seems like it would be difficult to know otherwise | 15:15.19 |
| | about the conditions at the time of the Do operator | 15:15.34 |
| rayjj | mvrhel_laptop: OK, so first I'm going back to the master branch and disable transfer function during put_image | 15:15.35 |
| mvrhel_laptop | right. that def. needs to be done | 15:16.05 |
| rayjj | mvrhel_laptop: so we _could_ reset the transfer function to identity every time one of the no-no conditions occurs | 15:18.29 |
| mvrhel_laptop | rajj: we need to construct some cases with different transfer functions on different elementary objects with different opacities including patterns and overprinting, as well as having different alpha values at the time that the groups are created | 15:18.40 |
| rayjj | mvrhel_laptop: I suppose so. | 15:20.03 |
| mvrhel_laptop | rayjj: that could work. we would need to be able to restore it though? | 15:20.04 |
| rayjj | mvrhel_laptop: now, I have a concern about: For portions of the page whose topmost object is not fully opaque or that are never painted at all, the default halftone and transfer function for the page are used. | 15:20.36 |
| mvrhel_laptop | oh crap | 15:20.59 |
| | missed that | 15:21.04 |
| rayjj | mvrhel_laptop: if there is a non-identity xfer function for the page, we need to use that (that is the case for 1-bit devices and cust 532's device) | 15:22.18 |
| mvrhel_laptop | that implies we need to do something at the time of put image | 15:22.21 |
| | and it is going to be ugly... | 15:22.31 |
| rayjj | mvrhel_laptop: so that means we have to have a mask telling us where to apply the transfer function ??? | 15:23.08 |
| mvrhel_laptop | that is the way I am reading it | 15:23.18 |
| | and thinking why did they do it this way | 15:23.24 |
| rayjj | mvrhel_laptop: probably because they forgot about transfer functions when spec'ing transparency :-/ | 15:24.06 |
| mvrhel_laptop | rayjj: if put image still has the alpha channel, we could perhaps use that as our mask | 15:24.43 |
| | but it implies that we need to do a special pixel by pixel process right before the begin image | 15:25.27 |
| | but no that wont work | 15:26.00 |
| | due to the soft mask | 15:26.09 |
| | so we really need a separate mask | 15:26.18 |
| | ick | 15:26.23 |
| rayjj | mvrhel_laptop: when pdf14_put_image is called, the top most alpha channel still exists, but as you say, if we have an area that had SMask with alpha 1.0 it would fool us | 15:26.56 |
| mvrhel_laptop | yes | 15:27.00 |
| | this sucks | 15:27.23 |
| rayjj | ya think ? | 15:27.40 |
| mvrhel_laptop | brb | 15:28.04 |
| rayjj | needs to learn some curse words in French so I can say "pardon my French" ;-) | 15:28.27 |
| | merde is about the only one that comes to mind | 15:28.46 |
| kens | "Va te faire foutre, trouduc" | 15:29.31 |
| Robin_Watts | recommends Braquo and Engrenages. | 15:29.33 |
| | tor8: New windows builds uploaded. | 15:30.15 |
| henrys | Robin_Watts: ron's lookin' for ya on skype | 15:30.31 |
| Robin_Watts | Are you going to do the news update for mupdf.com ? | 15:30.33 |
| rayjj | google recommends C'est des conneries | 15:31.49 |
| Robin_Watts | henrys: Thanks. | 15:32.24 |
| | tor8: the question about the mupdf.com news update was for you, in case that wasn't obvious. | 15:32.43 |
| | henrys: I need to make ron an account on casper. | 15:35.06 |
| mvrhel_laptop | rayjj: I am on the hook to make breakfast for the natives. bbiab | 15:38.22 |
| rayjj | mvrhel_laptop: thanks for the discussion | 15:39.51 |
| | mvrhel_laptop: at least it simplifies things a bit in that for bands where we skip the transparency compositor, we can apply the transfer function normally since we know there are no "special" conditions in those bands | 15:48.37 |
| mvrhel_laptop | rayjj: yes | 16:39.37 |
| rayjj | mvrhel_laptop: interestingly, _some_ of the pdf14 device cmap_procs used gx_map_color_frac(pis, cm_comps[i], effective_transfer[i]) which takes the transfer function into account (deviceN and separation) | 16:47.31 |
| | strange | 16:47.38 |
| Robin_Watts | tor8: I have all the mupdf-1.7rc1 archives in place on mupdf.com/downloads. | 17:42.05 |
| | tor8: And I've updated the news as well. | 17:51.26 |
| | All that remains, I think, is for the archives to be copied to other download sites, and I don't know how to do that. | 17:51.50 |
| | mvrhel_laptop, rayjj: That transfer function vs transparency stuff sounds like a nightmare. | 18:09.33 |
| | I've been considering a revamp of MuPDFs transparency stuff, and this completely throws it all up in the air again. | 18:10.00 |
| mvrhel_laptop | yes. it is horrid what they did | 18:10.14 |
| Robin_Watts | It sounds like we need to keep track of what transfer function is in use at every possible pixel position. | 18:10.33 |
| | (and if overprinting is in use, for every single component at every single position) | 18:10.45 |
| mvrhel_laptop | well, no we really just need to know at the end, if we need to apply the page transfer function to certain pixels | 18:11.15 |
| | so we will need to keep a map | 18:11.20 |
| Robin_Watts | Is that your understanding? Or is there a simpler way of looking at it that I'm missing? | 18:11.22 |
| mvrhel_laptop | but each pixel would need to be touched | 18:11.38 |
| | or checked in the map | 18:11.45 |
| | and then if it needs the transfer function applied it would be applied | 18:12.09 |
| Robin_Watts | Ah, so when an object is opaque, we apply the current transfer function to it immediately. | 18:12.27 |
| mvrhel_laptop | yes | 18:12.32 |
| Robin_Watts | and for all other opacities we set pixels in the map and apply the page transfer function to it later? | 18:13.07 |
| | Suppose I have a solid shape A in the background. | 18:13.39 |
| | then an opaque shape B on top of that. | 18:13.48 |
| | s/opaque/semi-opaque/ | 18:14.01 |
| | Then C on top of that. | 18:14.09 |
| mvrhel_laptop | and what is C's opacity? | 18:14.18 |
| Robin_Watts | Solid. | 18:14.24 |
| | The only one of those that should have its local transfer function applied is C, right? | 18:14.52 |
| mvrhel_laptop | yes. C would have the local applied. and the map should be set so that the page one is not applied | 18:15.29 |
| | when the group is popped | 18:15.36 |
| Robin_Watts | OK. Now think about a pixel that is covered by A and B, but not C. | 18:15.49 |
| mvrhel_laptop | at least that is my understanding | 18:15.51 |
| Robin_Watts | A should be plotted without use of a transfer function, right? | 18:16.07 |
| mvrhel_laptop | well, is A the initial back drop or was it draw in the group? | 18:16.30 |
| Robin_Watts | In the group. | 18:16.38 |
| mvrhel_laptop | it if was opaque, it has a transfer function applied to it | 18:17.03 |
| | if one was defined | 18:17.08 |
| | but when B is drawn, B does not, which seems wrong | 18:17.24 |
| Robin_Watts | but it's not the topmost object in the group. | 18:17.27 |
| mvrhel_laptop | as it is going to be blended | 18:17.30 |
| | oh right. its not the top most | 18:17.36 |
| | but you don't know that when you draw it | 18:17.46 |
| | thats messed up | 18:17.53 |
| Robin_Watts | indeed. That's what's hurting my head. | 18:17.59 |
| chrisl | Rather worryingly, these rules apparently apply to halftones as well - I can't imagine how that's supposed to work....... | 18:18.04 |
| mvrhel_laptop | ok, so the blending is going to need to account for the transfer function | 18:18.18 |
| | ick | 18:18.24 |
| Robin_Watts | I think a test file is called for. | 18:18.55 |
| Robin_Watts | walks dogs. bbs. | 18:19.16 |
| chrisl | mvrhel_laptop: isn't this going to have *horrid* side effects if you have a highly non-linear transfer function?? | 18:19.54 |
| mvrhel_laptop | yes | 18:20.34 |
| | luckily this only is valid for the normal blending case | 18:20.55 |
| chrisl | agrees with Ray - whoever wrote the transparency spec didn't consider transfer functions and halftones properly..... | 18:21.07 |
| mvrhel_laptop | no they did not | 18:21.13 |
| | they should have had it turned off and applied to the whole group | 18:21.24 |
| chrisl | In the Postscript world, transfer functions and halftones are really applied at the device level, so only applied to the final page canvas | 18:22.34 |
| mvrhel_laptop | yes | 18:22.39 |
| | that is why I was a bit shocked to read what I read in the pdf spec | 18:22.55 |
| | or one of the reasons | 18:23.01 |
| | the other is that it is just dumb | 18:23.09 |
| chrisl | Well, it *is* PDF..... ;-) | 18:23.22 |
| mvrhel_laptop | chrisl have you read the office spec? | 18:23.37 |
| chrisl | I have avoided that! | 18:23.49 |
| mvrhel_laptop | I would suggest you keep doing that | 18:24.03 |
| chrisl | But I thought the office spec was not originally for public consumption, which is not an excuse, but is a reason | 18:24.29 |
| | It *would* be interesting to see if Acrobat (and CPSI) actually applies these rules | 18:25.13 |
| tor8 | Robin_Watts: thanks! I had to pop out for dinner, so missed your message about updating the news. | 18:48.13 |
| | we usually wait for the real release before mirroring the downloads on ghostscript.com download site | 18:48.36 |
| Robin_Watts | tor8: So... the rc1 is done? | 18:51.28 |
| tor8 | Robin_Watts: I would say so. just need to poke people to try it out. | 18:52.53 |
| | the 32-bit version ran fine on my WinXP virtual box | 18:53.04 |
| fredross-perry | was there any unanimity on keystrokes for page historry? I am using command-[ and command-] (control for non-mac) to step thru the history, along with enu items called Back and Forward. This follows Preview. Adobe does command-arrows. | 19:05.53 |
| Robin_Watts | fredross-perry: No unanimity, no. | 19:06.21 |
| fredross-perry | It would be easy enough to add backspace to what Iâve got. Also, in AR, command-right arrow, when it reaches the end of the history, takes you to the next page, and extends the history. That seems nice. | 19:07.50 |
| | Perhaps command-arrows are more intuitive than command-[ and command-] | 19:08.27 |
| mvrhel_laptop | chrisl the office spec is an ECMA spec | 19:35.59 |
| | it is just insanely large. part 4 is 5000+ pages | 19:36.27 |
| | and it is so badly written | 19:36.36 |
| chrisl | mvrhel_laptop: Yeh, I do have it here, somewhere. I just assumed it started life as an MS internal only document, and morphed into the ECMA spec. Whilst the PDF spec was always intended to be publicly available. | 19:40.37 |
| mvrhel_laptop | well that could very well be | 19:40.53 |
| | I suspect the EU pressured MS to open things up to avoid some monopoly fairness fine and they threw everything in there making it almost unusable | 19:41.34 |
| chrisl | IIRC, the EU planned/threatened to standardize on the format that OpenOffice uses - whatever that's called.... | 19:43.59 |
| mvrhel_laptop | hmm maybe I am mixed up open office is the ecma spec | 19:46.58 |
| chrisl | Office Open (OOXML) is ECMA 376 | 19:51.37 |
| | OpenDocument is an ISO spec | 19:54.22 |
| mvrhel_laptop | ah ok | 20:06.45 |
| fredross-perry | I just uploaded 3 new gsview installers with the above-mentioned page history changes. | 20:11.16 |
| mvrhel_laptop | oh great a customer overprint bug | 21:22.11 |
| | there went the rest of my week | 21:22.18 |
| | and this file really really stinks I can tell already | 21:50.59 |
| | with its 27 spot colors | 21:52.00 |
| | Acrobat is even doing banded rendering drawing this thing | 21:54.38 |
| | at 17% zoom factor | 21:54.59 |
| | fredross-perry: are you there? | 22:00.41 |
| | hmm This may be as simple as abandoning our overprint simulation on additive devices. That really wont work the way it is done and we should disable it | 22:06.18 |
| | ok with overprint simulation off it looks ok | 22:12.51 |
| | whew! | 22:12.55 |
| fredross-perry | yes i am here. | 22:19.54 |
| | mvrhel_laptop: I am here. | 22:21.08 |
| mvrhel_laptop | Hi fredross-perry | 22:37.05 |
| | silly question for you | 22:37.09 |
| fredross-perry | âsup? | 22:37.13 |
| | go | 22:37.16 |
| mvrhel_laptop | I was finally getting the linux installer | 22:37.20 |
| | but I am not sure what to do with it :0 | 22:37.37 |
| fredross-perry | give it execute permissions and launch it | 22:37.52 |
| mvrhel_laptop | ah! | 22:38.03 |
| fredross-perry | 32 or 64? | 22:38.15 |
| mvrhel_laptop | 64 | 22:38.19 |
| fredross-perry | ok | 22:38.24 |
| mvrhel_laptop | ok that worked thanks fredross-perry | 22:41.46 |
| fredross-perry | good | 22:41.53 |
| mvrhel_laptop | marcos: for the logs, bug 695916 works fine for me | 23:11.47 |
| | fredross-perry: I may have a few comments on the viewer that I will write up later tonight | 23:12.07 |
| fredross-perry | ok thank you | 23:12.19 |
| mvrhel_laptop | fighting with some zoom update issues with the windows viewer | 23:12.26 |
| | very painful | 23:12.39 |
| | due to the way the scroll position information of the ui object is not really getting updated properly | 23:13.03 |
| | off to the baseball game now though. bbiaw | 23:13.33 |
| fredross-perry | batterrrrrrup | 23:15.34 |
| | Forward 1 day (to 2015/04/09)>>> | |
IRC Logs