| | <<<Back 1 day (to 2017/07/13) | 20170714 |
| mvrhel_laptop | This damn D is pissing me off. Some how we are missing an exclusion blend. | 01:23.32 |
| | Aha! | 01:47.57 |
| | damn I should have seen this | 01:48.04 |
| | Group was not isolated and in that case we should ignore the color space entry | 01:48.38 |
| | nice comment about this in ghostscript as I stepped through the file | 01:48.56 |
| | will wrap this up in the morning then. At least now I can sleep. This would have kept me up for a bit | 01:49.18 |
| | thinking about | 01:49.25 |
| Robin_Watts | Hi tor8. Any luck with the non-inverted stuff ? | 10:38.15 |
| tor8 | bashing on it now | 10:38.25 |
| | Robin_Watts: okay, so if I want a bmpcmp between robin/mvrhel_master and tor/mvrhel_master what's the magic incatations I need to do? | 11:13.28 |
| Robin_Watts | bmpcmp only ever tests again master. | 11:16.33 |
| | bmpcmp only ever tests against master. | 11:16.42 |
| tor8 | so, I've looked at the files mentioned in the commits and most other ones I could think of and inverting or not it all seems to come out the same | 11:18.19 |
| Robin_Watts | tor8: So is your branch robin/mvrhel_master with the inversion stuff removed ? | 11:19.12 |
| tor8 | I guess I'll just do a regular bmpcmp and look at that then | 11:19.15 |
| | yes, only a few very minor conflicts to resolve by just removing the inversion commit | 11:19.38 |
| Robin_Watts | tor8: Interesting. | 11:19.47 |
| | and surprising. | 11:19.56 |
| tor8 | robin/mvrhel_master writes inverted cmyk .ps files | 11:20.10 |
| Robin_Watts | probably, yes. | 11:20.22 |
| tor8 | our TIFF writer can't do CMYK output :/ | 11:20.44 |
| | mupdf can't open our own PAM files, and imagemagick inverts the colors | 11:22.11 |
| | I suspect imagemagick is using the data as RGB and ignoring the fourth channel | 11:22.42 |
| | so the only way I could look at our cmyk output is with gs :) | 11:23.04 |
| Robin_Watts | tor8: output to pam ? | 11:33.52 |
| | Then use http://ghostscript.com/~robin/pamview.htm | 11:34.15 |
| | Then use http://ghostscript.com/~robin/pamview.html | 11:34.36 |
| | That lets you view components individually. | 11:35.09 |
| tor8 | oh, we have PSD output. that works with imagemagick | 11:35.35 |
| Robin_Watts | tor8: We do indeed have PSD. | 11:36.06 |
| | latest version outputs spots too. | 11:36.14 |
| tor8 | Robin_Watts: okay, so the alpha compositing seems to work, but fz_blend_pixmap using the blendmodes doesn't | 12:07.43 |
| Robin_Watts | tor8: right. | 12:10.26 |
| | so the tradeoff in inverting the colors is that it means we don't need 2 different sets of blend_pixmap code. | 12:11.11 |
| | Urgh. /DeviceN is a pain. | 12:12.20 |
| tor8 | oh crap. makefile dependencies are broken by having source/pdf/*.c files include "../fitz/*.h" | 12:12.47 |
| | colorspace-imp.h | 12:12.54 |
| | cross-module private headers? ugh. | 12:13.37 |
| Robin_Watts | colorspace-imp.h is source/fitz/*.c, not source/pdf/*.h | 12:13.45 |
| | colorspace-imp.h is source/fitz/*.c, not source/pdf/*.c | 12:13.48 |
| tor8 | yes, but source/pdf/colorspace.c includes source/fitz/colorspace-imp.h | 12:14.00 |
| Robin_Watts | oh, ignore me. | 12:14.02 |
| | I follow. | 12:14.04 |
| | include/mupdf/fitz/imp/ ? | 12:14.26 |
| | Don't really like that. | 12:15.52 |
| tor8 | I'll make a note in the TODO to clean this up | 12:16.00 |
| Robin_Watts | source/imp/ ? | 12:16.04 |
| | Ah, no. I know how to do it. | 12:16.25 |
| | The CC commands should do -Isource | 12:16.49 |
| | that way stuff in pdf can #include "fitz/colorspace-imp.h" safely. | 12:17.08 |
| tor8 | the makefile needs an explicity dependency | 12:17.48 |
| | I was getting broken builds | 12:17.52 |
| Robin_Watts | mind you, I don't see why "../fitz/colorspace-imp.h" causes problems (though I do see that it's nasty) | 12:18.01 |
| tor8 | because the pdf source files were not rebuilding because source/fitz/*.h weren't part of their dependencies | 12:18.16 |
| Robin_Watts | Oh, I see. | 12:18.26 |
| tor8 | I have a makefile fix locally now | 12:18.38 |
| Robin_Watts | Maybe pdf/xps/etc should all have fitz/*.h has explicit dependencies. | 12:18.52 |
| tor8 | but first I need to dig through this inverted color stuff to see if I can understand just how and what needs to be done | 12:18.57 |
| Robin_Watts | s/has/as/ | 12:18.58 |
| tor8 | and then I need to find that issue with tiling patterns | 12:19.07 |
| | I don't think they should be digging through fitz internals | 12:19.22 |
| | if they need to, then the api should be public, and live in include/ not source/fitz/ | 12:19.44 |
| | right, pdfref17.pdf page 519 | 12:20.45 |
| | the blend functions assume the range for each component is 0.0 to 1.0 and that the color space is additive | 12:21.00 |
| | so the data should be complemented, blended, and complemented back | 12:21.22 |
| Robin_Watts | Right, so by keeping it complemented all the time, we save ourselves effort. | 12:21.46 |
| tor8 | I think doing that in the fz_blend_pixmap function is going to be more pleasant than making colors weirdly inverted *everywhere* else | 12:21.49 |
| | because that has knock-on effects on loading and saving CMYK data, and the public device graphics apis, etc, etc. | 12:22.08 |
| Robin_Watts | tor8: Those seem like small prices to pay for the simplicity, frankly. | 12:23.32 |
| | So I have the fz_separations structure having a list of spot names, plus an fz_colorspace for each. | 12:27.14 |
| | So we can find the "equivalent" color for each separation by mapping '1' to the required space. | 12:28.01 |
| | Unfortunately, for /DeviceN stuff that falls down. | 12:28.13 |
| | Altona has a [ /DeviceN [ /Black /Orange /None /None /None ] ...] space. | 12:30.47 |
| | so /Orange should be one of the separations, but I don't have an fz_colorspace I can easily add. | 12:31.08 |
| | (actually, in Altona, there IS a separation space for Orange, but that may not always be the case, AIUI). | 12:32.14 |
| tor8 | Robin_Watts: why do we need an equivalent color for each component in a devicen? | 12:54.38 |
| | if we have a devicen input color, and the output pixmap only has a subset of the devicen channels? | 12:55.35 |
| Robin_Watts | tor8: Suppose we want to do a CMYK rendering with overprint simulation. | 12:56.00 |
| tor8 | in that case, we could probably get by using the alternatetint transform with the components handled by the pixmap zeroed | 12:56.23 |
| Robin_Watts | We render the whole damn lot as CMYK+spots, then we map the results down to CMYK at the end. | 12:56.50 |
| | Right, but it's not quite as simple as it was for separations. | 12:57.16 |
| tor8 | even then, with CMYK+separation how would you blend the results? | 13:00.50 |
| Robin_Watts | Simple addition with clamping. | 13:01.15 |
| tor8 | or subtraction if in an additive space? | 13:01.39 |
| Robin_Watts | no additive spaces in my branch, but yes. | 13:01.50 |
| | Or rather, all spaces in my branch are additive. | 15:21.28 |
| tor8 | Robin_Watts: okay, I've got two more branches for you to look at (and shriek in horror) | 15:24.22 |
| | tor/mvrhel_master2 is a rework to hold colors in fz_pixmap additive | 15:25.34 |
| | colors in the device interface are still business as usual | 15:25.34 |
| | tor/mvrhel_master3 has a rework to complement the colors before and after applying blend modes | 15:25.35 |
| | mvrhel_master3 has the benefit of being non-intrusive | 15:25.37 |
| Robin_Watts | tor8: It'll also make spot rendering much slower. | 15:25.54 |
| | or rather... | 15:26.09 |
| | It'll also make overprint or spot rendering of files that include transparency much slower. | 15:26.39 |
| tor8 | if you use spot colors *and* transparency you deserve what you get... ;) | 15:26.58 |
| | our code is massively unready for additive colors in pixmaps. none of the output formats we do cope with it. | 15:27.41 |
| | ps, pwg, pcl, pdfwrite, psd, etc. | 15:27.50 |
| nilsont | Hi everyone, I tried to make creation of highlights with .epub files, but doesn't work.. There is a possibility to handle this creation for this type of file? Thanks in advance | 15:30.47 |
| Robin_Watts | psd copes with spots just fine (in my branch). | 15:31.01 |
| | pcl only does mono or rgb. | 15:31.14 |
| | tor8: I really dislike the idea of changing source pixmaps when blending. | 15:32.02 |
| tor8 | Robin_Watts: yes. I just wanted to see if this approach had any hope of working at all. | 15:32.39 |
| Robin_Watts | mvrhel_master2 will conflict horribly with my current work :( | 15:33.30 |
| | And mvrhel_master3 will be interesting when we have process + spot colors. | 15:34.54 |
| | cos spot colors are naturally subtractive. | 15:35.14 |
| | (and hence are held inverted in my branch) | 15:35.26 |
| | tor8: I think you've convinced me it's worth considering. | 15:45.21 |
| | When I get to a stable point, I'll have a play. | 15:46.08 |
| tor8 | mvrhel_master3 is updated to do the complementing inside the loop and not touch the source pixmap | 15:49.21 |
| Robin_Watts | tor8: Nice. | 15:49.34 |
| | tor8: I think I'd unroll it: if (complement) ... else ... | 15:50.50 |
| | that way the static inlines do the optimisation for you. | 15:51.02 |
| tor8 | yeah, that's the next step (exploding the number of functions) | 15:51.14 |
| | or just have a top if (complement) that doesn't have the optimization tree | 15:51.29 |
| Robin_Watts | tor8: But that is indeed much more palettable. | 15:52.18 |
| | Except.... when we start doing rgb+spots etc... | 15:52.44 |
| nilsont | Hi everyone, I tried to make creation of highlights with .epub files, but doesn't work.. There is a possibility to handle this creation for this type of file? Thanks in advance | 15:52.57 |
| Robin_Watts | that'll have the first 3 not wanting inverting, and the next ones wanting inverting. | 15:53.05 |
| | nilsont: Indeed, highlight annotations are PDF specific. | 15:53.22 |
| tor8 | yeah, but that shouldn't be too hard to work around. | 15:53.25 |
| | Robin_Watts: okay, new tweaked mvrhel_master3 with some static inline optimization | 15:56.31 |
| mvrhel_laptop | So when will the subtractive colors be inverted then? Right at blend time like in gs? | 15:57.30 |
| | and then inverted again after blend | 15:57.48 |
| Robin_Watts | mvrhel_laptop: right. | 15:57.58 |
| mvrhel_laptop | ok | 15:58.17 |
| | I am fine either way. You can't get away without inversion. I had thought tor8 was trying to do that | 15:58.46 |
| | Well, we could figure out some different equations perhaps for the subtractive cases to see if something falls out for some of the modes | 15:59.33 |
| | It would have been nice to make this decision a little earlier before you did all that work | 16:00.24 |
| tor8 | mvrhel_laptop: IIRC the compositing math (the basic porter-duff over operation used to blend color and backdrop) should work out the same whether we hold the colors inverted or not, right? | 16:00.33 |
| mvrhel_laptop | no | 16:00.44 |
| | I don't think so | 16:01.16 |
| | well not the blend mode calculation | 16:01.39 |
| Robin_Watts | The simple: output = src*alpha + backdrop*(1-alpha) is the same. | 16:01.47 |
| mvrhel_laptop | certainly the alpha will be the same | 16:01.52 |
| | yes | 16:01.54 |
| | that is find | 16:01.55 |
| | fine | 16:01.57 |
| tor8 | not the blend mode calculations, the ones that happen after to apply the alpha value | 16:01.59 |
| mvrhel_laptop | yes the alpha computation blend is fine | 16:02.12 |
| Robin_Watts | And how do we escape the premultiplied alpha trap for images? | 16:02.24 |
| tor8 | then I am fairly confident that what I have on tor/mvhrel_master3 should work | 16:02.31 |
| mvrhel_laptop | Robin_Watts: what trap is that? | 16:03.01 |
| tor8 | Robin_Watts: the blend loop un-multiplies the alpha before applying the blend mode. it's an icky hack. | 16:03.02 |
| | the "ugh, division to get non-premul components" comments in draw-blend.c | 16:03.29 |
| Robin_Watts | tor8: Right, but that's the price of working with pre-mul alpha. | 16:03.43 |
| tor8 | if it weren't for image interpolation failing miserably with non-premul alpha I'd be willing to consider moving to disassociated alpha | 16:04.19 |
| Robin_Watts | tor8: There is some analysis in comments in one of the files that shows that working with premul alpha is better. | 16:05.22 |
| tor8 | and the basic plotters/painting functions are simpler with premul alpha too | 16:05.43 |
| | Robin_Watts: for your earlier question about rgb+spot, I'd imagine the pixmap would hold an array of flags for each component, whether to complement for blending or not | 16:10.54 |
| | and pass the array rather than a single flag to the blend function | 16:11.07 |
| Robin_Watts | tor8: bletch. | 16:11.16 |
| tor8 | hmm, how do we do colorspaces pixmaps with rgb+spot? | 16:11.48 |
| Robin_Watts | currently, we have 'n' colorants for a pixmap. 'alpha' alpha ones at the end, 's' spots ones before them, and the rest are process ones. | 16:12.04 |
| tor8 | Robin_Watts: or a guard value, N components are not complemented | 16:12.11 |
| Robin_Watts | pix->colorspace->n = gives the number of process ones. | 16:12.23 |
| | or pix->n-pix->s-pix->alpha | 16:12.35 |
| tor8 | right, so the 'complement' value could just be pix->s and we check if k > s in the blend | 16:12.37 |
| Robin_Watts | tor8: yeah, we can tell. The question is what's the fastest way to tell :) | 16:13.12 |
| | I'm doing the premature optimisation thing ;) | 16:13.31 |
| tor8 | as long as the non-spot case is fast, I don't care about the other one :) | 16:13.33 |
| | Robin_Watts: so, mvrhel_master3 looks like a decent approach to you? | 16:14.25 |
| | I should be winding down for the weekend, but if there's anything else we should discuss I've got a few moments | 16:14.46 |
| Robin_Watts | tor8: Yeah. I'm going to look at rebasing my current work on top of that now. | 16:15.03 |
| | mvrhel_laptop: are you happy to adopt tor/mvrhel_master3 (or something very like it) and work from there? | 16:15.29 |
| tor8 | Robin_Watts: I snuck in a commit to give the colorspaces better names (that make sense in the trace device) | 16:15.55 |
| mvrhel_laptop | Robin_Watts: I am fine doing the inversion at blend time | 16:16.10 |
| tor8 | Robin_Watts: question is, do we want the fz_device_rgb colorspace to be named "DeviceRGB" when it's based on the ICC profile too? | 16:16.58 |
| | or something different (like in my commit) so we can easily tell | 16:17.17 |
| | it could have implications for the pdfwrite device, etc, as well | 16:17.39 |
| | but that's not a question you need to answer now | 16:17.53 |
| Robin_Watts | Why could it have implications in other devices? | 16:18.09 |
| | No devices should be looking at names, should they? | 16:18.37 |
| tor8 | how we name colors and if they try to detect ICC colors or devicergb | 16:18.41 |
| | I think we've moved most of the places that looked at the names away from doing so | 16:18.55 |
| Robin_Watts | I would have been happy with rgb-icc etc, rather than DeviceRGB-ICCBased etc. | 16:19.25 |
| | but basically I like your commit, I think. | 16:19.39 |
| mvrhel_laptop | Robin_Watts: so there are two small commits on my repos | 16:20.12 |
| Robin_Watts | Though, if we are going to have some of the names #defined, I wonder if we shouldn't have them ALL #defined. | 16:20.17 |
| mvrhel_laptop | If we can get that worked in, then I can switch to tor/mvrhel_master3 and then continue working from there | 16:20.48 |
| Robin_Watts | mvrhel_laptop: Gimme a mo, and I'll pull them all in. | 16:22.09 |
| mvrhel_laptop | ok. Let me know when you have it all sorted out. Then I will do a bit of testing | 16:22.36 |
| | The altona D is finally fixed. | 16:22.45 |
| | I need to look at those pgm output files for the fts tests | 16:23.01 |
| | that was ugly | 16:23.09 |
| | and they are still ugly. I will figure this out this morning | 16:31.26 |
| Robin_Watts | mvrhel_laptop: I like your first commit. I dislike your second. | 16:34.41 |
| | You're cloning the entire pixmap to a new one, then copying it. | 16:34.50 |
| | then dropping the clone. | 16:34.55 |
| | We can do better than that using fz_lookup_pixmap_converter. | 16:35.05 |
| | I'll do that now. | 16:35.08 |
| mvrhel_laptop | ok sounds good | 16:35.16 |
| | bbiab | 17:03.56 |
| Robin_Watts | mvrhel_laptop: OK, I've got an mvrhel_master up that I think I'm happy with. | 18:04.08 |
| | Just going to test it now. | 18:04.21 |
| mvrhel_laptop | ok. | 18:04.24 |
| | still working on the pgm issue. got it down to a single fill that is drawing nothing. should be able to figure this out | 18:04.55 |
| Robin_Watts | hmm. tests/Ghent_V5.0/GWG162_Transp_Basic_BM_DeviceCMYK_Isolate_X4.pdf.ppmraw.72.0 is broken with my revised mvrhel_master :( | 18:16.10 |
| mvrhel_laptop | Robin_Watts: if that is the only one, in a bit, I might be able to figure out the issue | 18:22.01 |
| Robin_Watts | I suspect there is more than one :( | 18:22.14 |
| mvrhel_laptop | I think I finally found one of the issues in the pgm | 18:22.25 |
| | file | 18:22.27 |
| | Robin_Watts: ok. well I can probably find those issues pretty quickly | 18:22.56 |
| Robin_Watts | mvrhel_laptop: If you wouldn't mind, that'd be great. | 18:23.14 |
| mvrhel_laptop | give me a couple moments to wrap up this one thing, then I can have a look | 18:23.19 |
| Robin_Watts | I'm struggling to move my stuff onto the end of tors new stuff. | 18:23.27 |
| mvrhel_laptop | yes. you work on the gittery stuff | 18:23.37 |
| | I am sure we are going to break a few things in the process | 18:23.52 |
| | and we will just have to sort them out | 18:24.05 |
| | oh shoot. I had made a mistake. ok. I am going to switch to working off of mvrhel_master | 18:27.36 |
| | and I will fix the low hanging fruit first | 18:27.46 |
| Robin_Watts | it is entirely possible that I broke the fz_copy_pixmap_rect stuff of course :( | 18:36.18 |
| mvrhel_laptop | No | 18:40.17 |
| | this is clearly a screw up some place in the separable stuff | 18:40.29 |
| | should have a fix shortly | 18:40.36 |
| | non-separable I mean | 18:40.41 |
| Robin_Watts | oh, cool. | 18:40.45 |
| mvrhel_laptop | by the way, you know you and tor8 were asking about the lines around the x's in these blend tests. Adobe shows the same lines | 18:45.26 |
| | That is acceptable | 18:45.39 |
| | ok that was easy | 18:50.10 |
| | Robin_Watts: so at the top of my blend_color branch | 18:52.22 |
| | on my repos | 18:52.29 |
| | Now let me see if I can figure out the pgm issue | 18:53.00 |
| | Robin_Watts: let me know if you see anything elsee | 18:53.06 |
| Robin_Watts | Thanks. | 19:02.28 |
| | hmm. | 19:03.35 |
| | That test should really be n-src->alpha, and then it would be correct, right? | 19:03.58 |
| | no, cos we've already done n-=sa. | 19:04.23 |
| | how can we be hitting that throw ? | 19:04.28 |
| | That throw was in the old version too. | 19:08.25 |
| | mvrhel_laptop: OK, I see where that THROW was introduced. | 19:11.46 |
| | What I don't understand is why we're hitting it. | 19:11.52 |
| | What is invalid about what the throw is saying? | 19:12.00 |
| mvrhel_laptop | uh we can handle cmyk separable blending? | 19:12.37 |
| | so we should go ahead and do it and not throw | 19:12.58 |
| Robin_Watts | blendmode >= FZ_BLEND_HUE => non-separable, right? | 19:12.59 |
| mvrhel_laptop | yes | 19:13.33 |
| Robin_Watts | So the code says: "If we're attempting to use a non-separable blend mode on something that isn't greyscale or rgb, we have a problem" | 19:14.02 |
| | Which seems reasonable to me. | 19:14.12 |
| mvrhel_laptop | no | 19:14.17 |
| | we can handle cmyk non-separable blending | 19:14.31 |
| | I added that | 19:14.42 |
| Robin_Watts | Ah! | 19:14.44 |
| | So tors renaming of that function is wrong too. | 19:14.57 |
| mvrhel_laptop | right | 19:15.09 |
| | I see the rgb | 19:15.12 |
| | that should not be there | 19:15.16 |
| | I did not notice that at the time | 19:15.23 |
| | we had this discussion earlier this week or last week didn't we? | 19:15.59 |
| | regarding rgb and cmyk and non-separable | 19:16.12 |
| Robin_Watts | Yeah, but goldfish memory, me. | 19:16.21 |
| | So if this code is supposed to cope with CMYK too, does it need inversion stuff ? | 19:16.43 |
| mvrhel_laptop | well that should have already been done? | 19:16.57 |
| | where is stuff inverted now | 19:17.04 |
| Robin_Watts | stuff is inverted *in* these routines now. | 19:17.15 |
| | but stuff ISN'T inverted in the non-separable routines, cos Tor didn't realise that they were handling spaces other than g and rgb. | 19:17.58 |
| mvrhel_laptop | oh. | 19:18.17 |
| | well this is going to get interesting | 19:18.29 |
| Robin_Watts | It's "just" a matter of adding the complement flag into that function. | 19:18.50 |
| | which I will do - but not today. | 19:19.04 |
| mvrhel_laptop | ok | 19:19.27 |
| Robin_Watts | ok, I have to run, or Helen will kill me. | 19:19.46 |
| | Are you Ok to carry on from here? | 19:19.52 |
| mvrhel_laptop | I will hopefully have a fix for this pgm stuff I think its in the lightness blending when we are in gray | 19:20.01 |
| | Robin_Watts: yes I am good | 19:20.08 |
| Robin_Watts | cool. I'll check back later for it. | 19:20.10 |
| | Thanks. | 19:20.13 |
| mvrhel_laptop | Please keep Helen happy | 19:20.16 |
| | bye | 19:20.19 |
| Robin_Watts | mvrhel_laptop: so I've got a few minutes and I'm looking at it now. | 19:49.53 |
| mvrhel_laptop | ok. | 19:50.04 |
| Robin_Watts | I need to invert all the values before feeding them into hue_rgb etc. | 19:50.10 |
| | how does this fit with premultiplied alpha... let's look at another function... | 19:50.27 |
| | unpremultiply, THEN invert. | 19:50.53 |
| mvrhel_laptop | yes. If you want to save a little time, you only need to invert CMY... | 19:52.11 |
| | K is not inverted, but you will need to unmultiply | 19:52.37 |
| | probably easier just to treat it the same | 19:52.46 |
| Robin_Watts | K is not inverted? | 19:52.51 |
| mvrhel_laptop | well K is not really used in calculations | 19:53.12 |
| | uses backdrop K for Hue, Saturation and Color | 19:53.35 |
| | and sourc K for Luminosity | 19:53.43 |
| | ok something odd goiing on when we stroke the path here in the gray case | 19:54.59 |
| | filling was fine. stroking was not fine | 19:55.17 |
| | seems a little odd | 19:56.39 |
| | does that ring any bells for you Robin_Watts ? | 19:56.51 |
| Robin_Watts | not offhand. | 19:57.01 |
| | probably points to a typo in fz_draw_stroke_path :) | 19:57.20 |
| mvrhel_laptop | yes.... | 19:57.31 |
| Robin_Watts | or in the list device. | 19:57.37 |
| | does running with -D change it ? | 19:57.42 |
| | -D disables the list device. | 19:57.53 |
| mvrhel_laptop | let me try that | 20:01.51 |
| | no. that had no effect. thanks though | 20:02.40 |
| Robin_Watts | worth ruling it out though. | 20:03.09 |
| | mvrhel_laptop: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=4a1aeb17a3d3e772d119549d5b01393c301e2703 | 20:08.01 |
| | That's on the tip of robin/mvrhel_master now. | 20:08.14 |
| | Tests running now. If it looks plausible, we can squash it back. | 20:08.29 |
| mvrhel_laptop | ok. Once we pull you DeviceN stuff in we will want to rethink some of this | 20:09.18 |
| Robin_Watts | Yeah, I'll need to rework that in lieu of spots. | 20:09.36 |
| mvrhel_laptop | but looks reasonable to me | 20:09.49 |
| Robin_Watts | The bmpcmp is still looking rough though. | 20:14.52 |
| mvrhel_laptop | Robin_Watts: ok I have a fix | 20:17.03 |
| | for the pgm stuff | 20:17.06 |
| | let me push that to you | 20:17.19 |
| | you can review and hack it ;) | 20:17.26 |
| Robin_Watts | ooh, I see a difference in pdf-op-run.c between tor's branch and mine. | 20:17.28 |
| | oh, but that's a fix you added. | 20:18.03 |
| mvrhel_laptop | Robin_Watts: so on my repos | 20:22.55 |
| | in the blend_color branch | 20:23.33 |
| | That commit fixes issues that were coming up in the pgm output | 20:23.48 |
| | Robin_Watts: so what should I look at next? I need to go get Ethan at bus stop in a bit | 20:26.19 |
| | hmm are the bmpcmp results of yours the most recent? | 20:27.32 |
| | or is that your DevN stuff? | 20:27.38 |
| | I am hoping its your DevN stuff | 20:27.56 |
| | have to step out. bbiaw | 20:34.04 |
| Robin_Watts | no, it's not the DevN stuff :( | 22:56.24 |
| | Forward 1 day (to 2017/07/15)>>> | |
Log of #mupdf at irc.freenode.net.