| | <<<Back 1 day (to 2011/08/03) | 2011/08/04 |
| wetg | ghostbot: help | 00:16.13 |
| | how do i list words in dict? | 00:21.34 |
| Robin_Watts | tor8: ping | 10:52.56 |
| | When we do clipping by a non rectangular path in the fitz renderer, we create a new destination, draw to that, and plot back through a mask. | 10:53.54 |
| | That will fail for any non-zero blend mode used with a non-isolated group. | 10:54.46 |
| | Hmm. Badly expressed. Let me try another run at that. | 10:55.04 |
| | When we have a non rectangular clip path to clip with, we create a new (completely blank) destination, and draw to that. When we pop the clipmask, we then draw that destination back through the mask. | 10:56.08 |
| | Effectively, we create an isolated group, draw into it, and then clip that isolated group back as we blend. | 10:56.45 |
| | That will fail if we ever plot into that group with a non-zero blend mode, as that won't have a background color to blend with. | 10:57.54 |
| | What we *ought* to do is to copy the background into new destination when we create it. Then it'd be a non-isolated group, and all the blendmodes would work fine. | 10:59.42 |
| | But that will have the same problem with tiling as I described yesterday. | 11:00.44 |
| tor8 | yup. that's the bug I've entered "blending across clip masks" | 11:04.09 |
| Robin_Watts | Ok, just added a set of comments to that effect to the code. | 11:17.35 |
| | tor8: New patch on casper. | 11:34.21 |
| | oops. actually, let me sane it. | 11:40.40 |
| | ok, no changes. | 11:43.23 |
| | tor8: Suppose I draw a white circle at 50% opacity. dest should be written with pixel values of 128,128,128. | 12:17.21 |
| | What should the shape plane be written with values of ? | 12:17.42 |
| tor8 | shape should be 100% if my understanding of the shape/opacity alpha duo is correct | 12:27.44 |
| Robin_Watts | ok, tor8, can you spare me some time to walk through a simple file to tell me if your understanding agrees with mine ? | 12:43.50 |
| tor8 | my understanding of knockouts is practically useless, but sure :) | 12:44.37 |
| Robin_Watts | Not knockouts. | 12:44.48 |
| | actually, I have to get lunch now. | 12:44.56 |
| tor8 | or non-isolated | 12:44.58 |
| Robin_Watts | Can we do it afterwards ? | 12:45.02 |
| tor8 | okay, ping me when you're back | 12:45.04 |
| Robin_Watts | Thanks. | 12:45.07 |
| | tor8: OK. http://ghostscript.com/~robin/hate2.pdf | 13:20.51 |
| | and http://ghostscript.com/~robin/0001-Work-in-progress.patch | 13:22.13 |
| | If you take the latest mupdf (as in my repo on casper), add that patch to it, and then do: | 13:22.44 |
| | win32\Debug\pdfdraw.exe -r100 -o out.png hate2.pdf 1 | 13:23.04 |
| | we'll have the same results to look at. | 13:23.10 |
| tor8 | Robin_Watts: okay. | 13:25.54 |
| | argh, this new lion has so many bugs | 13:26.29 |
| Robin_Watts | Various 'dumpXX.png' files will be produced in your current directory. | 13:26.34 |
| tor8 | the compiler/linker is seriously broken | 13:26.44 |
| Robin_Watts | tor8: Yes. | 13:26.49 |
| tor8 | ld: in build/debug/libmupdf.a, malformed archive TOC entry for _pdf_load_system_cmap, offset 1600481379 is beyond end of file 5960352 | 13:26.52 |
| Robin_Watts | yeah, I get that kinda shite too. | 13:27.00 |
| tor8 | Robin_Watts: probably because you need to manually run "ranlib" again... | 13:27.36 |
| | it used to be they fixed that shite, when you had to rerun ranlib if you even so much as sneezed on the lib⦠like mv it to a different location | 13:28.13 |
| | okay, I have an out.png and dump00-27.png | 13:28.38 |
| Robin_Watts | ok, so you should have had some helpful stdout too, describing what the different dumpXX.pngs are. | 13:29.11 |
| tor8 | yes | 13:29.25 |
| Robin_Watts | Blending 00/01 onto 02/03 (alpha 0.5) to get 04/05 | 13:29.29 |
| | The latter value in each pair is the shape plane. | 13:29.40 |
| | So the file does a grey rectangle, then starts a group to draw over the top of it. | 13:30.06 |
| | all of the groups are non-isolated. | 13:30.31 |
| | hence they have the background in. | 13:30.38 |
| tor8 | yup. | 13:30.41 |
| Robin_Watts | So all the dump values look reasonable to me until we get to the last set. | 13:31.08 |
| tor8 | dump02 is the initial solid background before transparency is set, right? | 13:31.14 |
| Robin_Watts | Do you agree ? | 13:31.16 |
| | dump02 is the background 'grabbed' from the whole page when the first group is set up. | 13:32.13 |
| | (not the page group). | 13:32.37 |
| tor8 | ah, right. I see that now when I got to dump20 :) | 13:32.44 |
| | is the shape for that supposed to be all black though? | 13:33.03 |
| | or should the shape be copied from the backdrop as well? (just curious how things work) | 13:33.32 |
| Robin_Watts | Currently, I have no shape plane at the topmost level. | 13:34.00 |
| | I think I tried having the page group create a shape plane and set it to 255, but that didn't change the results. Let me recheck that. | 13:34.46 |
| tor8 | Robin_Watts: okay, I've got hate2.pdf open in acrobat x to compare results with as well | 13:37.15 |
| | up to dump18 everything looks correct | 13:37.46 |
| | apple preview on lion renders the same as acrobat | 13:38.15 |
| | Blending 18/19 onto 20/21 (blend 8) to get 22/23 looks like where it goes wrong | 13:39.55 |
| Robin_Watts | Ok. 03 has an 'empty' shape because we're inside a clipping group. | 13:40.14 |
| | which forces us to be isolated. | 13:40.35 |
| | 18 and 19 look correct to me. | 13:41.09 |
| | as does 20. | 13:41.37 |
| | 21 could arguably be white rather than black (I have it as white here, by forcing the top level page to have a shape). | 13:42.16 |
| | but both ways we get the same results for 22/23 | 13:42.28 |
| | Do you agree with 18/19/20 being correct ? | 13:43.05 |
| tor8 | yes | 13:43.33 |
| Robin_Watts | So, WTF am I doing in the blend to cock it up... | 13:43.53 |
| tor8 | you get the same results with 21 being full white as well as mostly black with a white rectangle? | 13:44.31 |
| Robin_Watts | yes. | 13:45.02 |
| tor8 | perhaps you're not supposed to blend there? | 13:45.35 |
| Robin_Watts | Then where should the blend go? | 13:45.59 |
| | That's the only place we do a 'Darken' blend. | 13:46.09 |
| tor8 | maybe the clip group forces two blends (primitive and group) when you should only blend for primitives? | 13:46.20 |
| Robin_Watts | Sorry, it's "Hard Light" | 13:46.50 |
| | All the clips are rectangular, so no clipping groups are produced. | 13:47.08 |
| tor8 | ah, right. just tossing out wild ideas. | 13:47.45 |
| Robin_Watts | believe me, any straw is worth clutching at at this point :) | 13:48.11 |
| | I don't see how we can get quite the results from the blend that we do... | 13:48.39 |
| tor8 | try reversing the blend order, just for kicks | 13:49.32 |
| | it looks as if the hard light is applied in the wrong order | 13:49.44 |
| ray_laptop | chrisl: how is the 9.04 release looking ? still any 'blockers' ? | 13:54.00 |
| chrisl | ray_laptop: no, we're looking pretty good. I'm going to make the archives tomorrow, and do the "official" release on Monday | 13:54.39 |
| Robin_Watts | tor8: I completely lose the right hand side if I do that. | 13:55.09 |
| chrisl | ray_laptop: I need to make the changes you suggested in the News.htm file, though | 13:55.21 |
| Robin_Watts | and the colour change effect too. | 13:55.23 |
| | I stared at the code a while ago, and I came to the conclusion it was the right way around. | 13:55.47 |
| tor8 | right. | 13:55.58 |
| Robin_Watts | Actually, I take back what I said about 03 being black. | 13:59.07 |
| | I have no idea why that's black. | 13:59.17 |
| | (at least in my hacked version here) | 13:59.39 |
| | oh, maybe I do. | 14:00.27 |
| | If I change the blendmode to normal, we get exactly the same results as Acrobat does. | 14:09.07 |
| chrisl | tkamppeter: I've now also fixed Bug 691586 so the RIP_MAX_CACHE env setting should work as expected now. | 14:11.11 |
| ray_laptop | off to have fun at Disney World :-) | 14:18.10 |
| Robin_Watts | chrisl: Nice one. | 14:21.07 |
| chrisl | Robin_Watts: Ta, good to get it fixed, finally! | 14:22.55 |
| Robin_Watts | while you're on a roll, you don't want to look at mupdf transparency blendings do you? :) | 14:23.26 |
| chrisl | just the thought makes me shudder - I doubt they could have made PDF transparency more over complicated if they tried! | 14:24.11 |
| Robin_Watts | ooooh. | 14:24.36 |
| | tor8: http://ghostscript.com/~robin/hate3.pdf | 14:24.57 |
| | 2 identical groups, with the difference that the left one has "normal" rendering, and the right one has "HardLight". | 14:25.31 |
| | Can you tell the difference in Acrobat ? | 14:25.39 |
| tor8 | yes, the top left bit where all colors (red, blue, yellow, gray) intersects is brighter on the right than left image | 14:27.06 |
| | and the yellow/red intersection is a bit darker orange on the left | 14:27.31 |
| Robin_Watts | ok. | 14:27.38 |
| | but it's a much less pronounced difference. | 14:27.48 |
| tor8 | acrobat renders the same as lion | 14:27.50 |
| | yeah, at a first glance they look the same :) | 14:27.59 |
| Robin_Watts | mvrhel2: As the companys color expert, can you spare me a few minutes to walk through a (simplish) PDF file please? | 14:46.58 |
| | The transparency/blending in it, is confusing me. | 14:47.08 |
| tkamppeter | chrisl, works on all command lines. Thank you very much. | 14:51.57 |
| chrisl | tkamppeter: cool, thanks for testing! It's in 9.04 as well. | 14:52.27 |
| Robin_Watts | has scared mvrhel2 away :( | 15:05.23 |
| henrys | chrisl:nice work on cups! | 15:07.17 |
| chrisl | henrys: thanks. Are you okay with my plan to make the 9.04 archives tomorrow, and do the rest of the release stuff on Monday? | 15:09.09 |
| henrys | yes that sounds right to me. | 15:09.37 |
| chrisl | Good, that's the plan, then | 15:10.15 |
| chrisl | is off to play squash | 15:11.02 |
| tkamppeter | OK, so I can make the final 9.04 packages for Oneiric Monday or Tuesday. | 15:11.41 |
| chrisl_away | tkamppeter: I can make the release archives available for you tomorrow if you prefer, I just don't want to have to rush through the website updates/changes. | 15:12.33 |
| Robin_Watts | tor8: If I HardLight blend any screen colour onto a backdrop colour of white, I should get white, as far as I can see. | 15:14.52 |
| | Ah, no. If I *Screen* any colour with a background color of white I should get white. | 15:16.01 |
| | Which means HardLight of any colour of more than 1/2 intensity with white should give me white. | 15:16.20 |
| tor8 | and hardlight is screen/multiply based on brightness of backdrop | 15:16.23 |
| | or was it source? | 15:16.33 |
| Robin_Watts | Source. | 15:16.37 |
| | So, how can acrobat be giving the results it is ? | 15:16.59 |
| tor8 | no idea. probably something we've missed in when/where the blends are going to be applied. | 15:17.25 |
| | need to prepare for dinner, I'll be back later. I hope mvrhel2 can help you out in the meanwhile. | 15:18.02 |
| Robin_Watts | ok, have a good one. | 15:18.45 |
| mvrhel2 | Hi Robin_Watts | 15:26.12 |
| Robin_Watts | Hi | 15:26.19 |
| mvrhel2 | let me finish up a couple breakfast things here | 15:26.24 |
| | I will be back in 10 / 15 mintues | 15:26.34 |
| Robin_Watts | mvrhel2: Thanks. | 15:26.41 |
| tkamppeter | chrisl_away, OK, let it do this way. If the archives are final, I can then make the package already tomorrow. | 15:33.11 |
| mvrhel2 | Robin_Watts: ok I am back | 15:55.47 |
| | I am not super familiar with all the wacky blend modes though | 15:56.00 |
| Robin_Watts | mvrhel2: Inspiration may have struck. | 15:56.02 |
| mvrhel2 | oh good. | 15:56.09 |
| Robin_Watts | so bear with me for 5 mins in case I can avoid wasting your time. | 15:56.16 |
| mvrhel2 | Next time you ask a question I will leave for 15 minutes :) | 15:56.28 |
| Robin_Watts | Damn. | 15:57.26 |
| | I just changed a whole lot of code, and arrived back with the same results. | 15:57.52 |
| mvrhel2 | and that was not your intention I assume | 15:58.24 |
| Robin_Watts | indeed. | 15:58.29 |
| | OK. If you look at http://ghostscript.com/~robin/dump.zip | 15:58.57 |
| | you'll find a variety of things inside. | 15:59.06 |
| | hate2.pdf is the pdf file in question. | 15:59.14 |
| | out.txt is the debugging text that mupdf gives me while it runs. | 15:59.42 |
| | It shows the structure of the groups, and the blending operations, and provides a key to what the different png files are. | 16:00.22 |
| | out.png is what mupdf gives. | 16:00.35 |
| | Where we have lines like: | 16:01.03 |
| | Blending 00/01 onto 02/03 to get 04/05 | 16:01.17 |
| | 00 = the source image, 01 = the source shape plane | 16:01.33 |
| | 02 = the background image, 03 = the background shape plane etc. | 16:01.47 |
| mvrhel2 | 16 looks pretty good | 16:04.31 |
| | almost anyway | 16:04.41 |
| Robin_Watts | Yes, I reckon it all goes wrong in the "Blending 18/19 inro 20/21 (blend 8) to get 22/23" stage | 16:05.18 |
| mvrhel2 | yes | 16:05.58 |
| | so is 20/21 the the same gray fill that you have in 18? | 16:07.11 |
| | s/the the/the | 16:07.21 |
| | or is it some other object? | 16:07.46 |
| Robin_Watts | The same thing. | 16:07.51 |
| | None of the groups are isolated ones. | 16:08.00 |
| mvrhel2 | why is it getting applied twice? or is that in the document? | 16:08.27 |
| Robin_Watts | so when we start the group, we allocate a new background pixmap to render to, and we copy the contents of the previous background into it. | 16:08.28 |
| | The first thing the doc does is draw the grey rectangle. | 16:08.46 |
| | Then it sets the blend mode to 8 (HardLight). | 16:08.55 |
| | Which (in mupdf terms) starts a group. | 16:09.03 |
| | so we copy the grey rectangle in, but have an empty shape plane. | 16:09.36 |
| | Does that make any sense ? | 16:10.53 |
| mvrhel2 | I think so. I am a little confused by the output of 21 though | 16:11.26 |
| | and 20 | 16:11.41 |
| Robin_Watts | 20/21 aren't outputs. | 16:11.51 |
| mvrhel2 | and how/why that is leading to 22/23 | 16:11.52 |
| | when I say output I mean the image file | 16:12.12 |
| Robin_Watts | It's quite possible that the blend operation I am doing to go from 18/19 + 20/21 -> 22/23 is wrong. | 16:12.18 |
| | but I'd hope that 18/19 and 20/21 are correct. | 16:12.38 |
| | Why are you confused by 20/21? What would you expect ? | 16:12.49 |
| mvrhel2 | I am confused since it would seem that the blend with the gray object is going to occur twice | 16:13.19 |
| | but maybe there is something I am not following in your output | 16:13.49 |
| Robin_Watts | The structure of the file is such that we have a grey rectangle, with something HardLight blended onto it. | 16:14.27 |
| | That something is another group of objects. | 16:14.36 |
| | Those objects are blended together using the 'Normal' blending modes. | 16:14.54 |
| mvrhel2 | so what is the gray rectangle doing in the earlier blendings? | 16:15.11 |
| Robin_Watts | That something is NOT an isolated group. | 16:15.15 |
| | Would you rather have seen 02/03 as being completely transparent and shapeless ? | 16:16.00 |
| mvrhel2 | I am not sure what I would prefer. What does GS give with this file? Did you run it with its debug output | 16:16.28 |
| Robin_Watts | mvrhel2: I haven't looked at gs. | 16:16.42 |
| | And I wouldn't understand it's debug output. | 16:16.54 |
| mvrhel2 | Let me look real quick if it does it correctly | 16:16.55 |
| Robin_Watts | mvrhel2: Thanks. | 16:17.01 |
| mvrhel2 | you would understand it as well as I understand mupdf debug output :) | 16:17.13 |
| | btw: when are you heading off Robin_Watts? | 16:18.20 |
| Robin_Watts | Monday afternoon. | 16:18.27 |
| mvrhel2 | ok. I want to chat with you a bit about the planar device halftoning/ pattern stuff | 16:18.44 |
| | but let me look at this first | 16:18.51 |
| Robin_Watts | though I doubt I'll be working monday morning. | 16:18.53 |
| | ok. | 16:18.55 |
| mvrhel2 | ok gs seems to give the correct output | 16:22.30 |
| | let me look at the debug output | 16:22.51 |
| henrys | hi marcosw | 16:24.23 |
| marcosw | morning | 16:25.14 |
| henrys | miles may call | 16:26.06 |
| marcosw | for the support meeting? | 16:26.14 |
| henrys | yes he's lonely. | 16:26.37 |
| marcosw | if he calls you first please tell him to call me at 510 979 0101 | 16:27.11 |
| henrys | okay | 16:27.18 |
| mvrhel2 | Robin_Watts: ok so gs is also doing this blend of the gray rect with the blending object | 16:27.50 |
| henrys | marcosw:are you comfortable with removing devices? It might be easier for you to do it. | 16:28.17 |
| Robin_Watts | ah, good. I figured it had to. | 16:28.17 |
| mvrhel2 | However, the blended object has a interesting alphs | 16:28.27 |
| | alpha | 16:28.29 |
| | channel | 16:28.33 |
| Robin_Watts | mvrhel2: Ah, go on... | 16:28.39 |
| henrys | marcosw:or I can do it, let me know. | 16:28.41 |
| | marcosw:anyway that is the answer for all the recent device bugs AFAICT. | 16:29.13 |
| marcosw | I've added and remoed devices by modifying the makefile. | 16:29.32 |
| mvrhel2 | Robin_Watts: so the gray object has an alpha of 255 where it was gray and 0 where it was not gray | 16:29.33 |
| | The blended object has an alpha of 1 where the gray rectangle was | 16:29.57 |
| | 255 I mean | 16:30.03 |
| | or 1 | 16:30.04 |
| | and the right side of the blended object (where there was no gray rectangle) has the alpha values for the blended objects | 16:30.42 |
| marcosw | we probably don't want to remove the bbox device :-) | 16:30.59 |
| Robin_Watts | mvrhel2: Do you mean alpha or shape ? | 16:31.15 |
| henrys | marcosw:I am going to have a meeting with miles talk to you in a bit. | 16:31.16 |
| marcosw | no problem, I'm here. | 16:31.32 |
| mvrhel2 | the alpha plane | 16:31.35 |
| Robin_Watts | So gs doesn't count the backdrop of the page as being solid ? | 16:32.28 |
| mvrhel2 | oh your png output has the alpha packed into the format | 16:32.38 |
| Robin_Watts | mvrhel2: Yes. | 16:32.48 |
| mvrhel2 | makes it harder to see to me | 16:32.57 |
| Robin_Watts | The png's are "rgb + alpha" and "shape". | 16:33.05 |
| mvrhel2 | what if you were in cmyk? | 16:33.12 |
| Robin_Watts | Sadly, that's the format I have inside mupdf. | 16:33.16 |
| | No cmyk in mupdf :) | 16:33.22 |
| mvrhel2 | what about cmyk blend modes | 16:33.28 |
| | blend color spaces I mean | 16:33.39 |
| Robin_Watts | We have pixmaps in mupdf that are 'n' components. | 16:33.45 |
| | If that includes alpha, then plane n-1 is alpha. | 16:34.05 |
| | The shape plane is always separate. | 16:34.13 |
| mvrhel2 | ok | 16:34.18 |
| Robin_Watts | And the debugging function I have to dump pngs just lets me save a png from a pixmap. | 16:34.37 |
| | hence I get the alpha pickled into the PNGs. | 16:34.53 |
| mvrhel2 | gotcha | 16:34.58 |
| Robin_Watts | but I'm still confused by what you said earlier. | 16:35.21 |
| | You say that the grey rectangle has an alpha of 1, but the background has an alpha of 0 ? | 16:35.40 |
| mvrhel2 | yes | 16:36.32 |
| Robin_Watts | That's... odd, surely. | 16:36.47 |
| mvrhel2 | I am just telling you what I see... | 16:37.00 |
| | when the blend occurs the incoming group basically takes over where the gray rectangle has not been drawn | 16:38.06 |
| | it acts like the mask that you have | 16:38.28 |
| | I would think | 16:38.33 |
| Robin_Watts | So walk me through the file... | 16:39.41 |
| | We start off with the page being entirely transparent? | 16:39.59 |
| | and we draw the grey rectangle onto it. | 16:40.08 |
| mvrhel2 | hold on let me clear and start off with the start | 16:40.21 |
| Robin_Watts | Ok, thanks. | 16:40.27 |
| mvrhel2 | yes | 16:41.17 |
| | all is transparent | 16:41.29 |
| | then we push a group | 16:41.48 |
| | and there is a background init | 16:42.18 |
| | with the gray rectangle | 16:42.21 |
| Robin_Watts | Ok. That's the page group (specified in /Page entry) | 16:42.46 |
| mvrhel2 | which has alpha on 1 where the gray rect is drawn and 0 elsewhere | 16:42.57 |
| Robin_Watts | it's non-isolated and non-knockout. | 16:43.13 |
| | OK, so the alpha is behaving like the shape plane. | 16:43.23 |
| mvrhel2 | then another group is pushed and the back ground initialized with a part of the gray fill | 16:44.03 |
| Robin_Watts | Next thing that should happen is that the blendmode should be set. | 16:44.07 |
| mvrhel2 | likely getting ready to draw a circle | 16:44.17 |
| Robin_Watts | AFter the blendmode is set, we start a group, yes. | 16:44.35 |
| mvrhel2 | ok then we draw the red rectangle | 16:44.52 |
| | red circle | 16:44.57 |
| | sorry | 16:44.59 |
| Robin_Watts | another non-isolated, non-knockout group for the red circle, yes. | 16:45.04 |
| mvrhel2 | then we do this again for another circle | 16:45.41 |
| | we do the init of the background | 16:45.46 |
| | which includes the gray rect and the red circle part | 16:45.58 |
| Robin_Watts | Ok, so gs is copying in the background each time, same as we do. | 16:46.02 |
| | That's good to know. | 16:46.12 |
| mvrhel2 | but it just copies the part that is has to work on | 16:46.22 |
| Robin_Watts | likewise mupdf. | 16:46.30 |
| mvrhel2 | ok then the yellow circle is drawn | 16:46.59 |
| | then it does all of this for the blue circle | 16:47.27 |
| | now it is going to start to pop all of these groups | 16:47.59 |
| Robin_Watts | I believe it should have popped some already ? | 16:48.23 |
| mvrhel2 | oh yes | 16:48.48 |
| | sorry | 16:48.49 |
| Robin_Watts | start group, draw red circle, pop group, start group, draw yellow circle, pop group, start group, draw blue circle,... OK. | 16:48.54 |
| mvrhel2 | it is popping the last one | 16:48.55 |
| Robin_Watts | :) | 16:48.56 |
| | Right, now every one of those groups has been drawn internally with blendmode = 0 (Normal) | 16:49.21 |
| mvrhel2 | so when the blue one is popped, then I have something that has the rgb colors plus an alpha plane | 16:50.05 |
| | where the alpha is 1 where the gray rect was drawn and some alpha values outside | 16:50.23 |
| Robin_Watts | OK. | 16:50.34 |
| mvrhel2 | for the various color circle overlaps | 16:50.36 |
| Robin_Watts | So the alpha values are intermediate for those circle overlaps? | 16:51.05 |
| | i.e. it's not just a sillhouete ? | 16:51.11 |
| mvrhel2 | no | 16:51.15 |
| Robin_Watts | OK. But you don't have a shape plane per se ? | 16:51.30 |
| mvrhel2 | not at that stange | 16:51.39 |
| Robin_Watts | When do you have a shape plane ? | 16:51.52 |
| mvrhel2 | hold on | 16:51.58 |
| | Robin_Watts: I have a call in 8 minutes with customer 532 about CRDs, so you may lose me in a bit | 16:52.25 |
| Robin_Watts | ok. | 16:52.30 |
| mvrhel2 | let me back up one step here | 16:53.03 |
| | as there is an extra plane of data | 16:53.13 |
| | hmm. on that final blend the alpha of the circle fills (with the gray rect) have an alpha of 1 where the gray rect was and various values outside | 16:55.41 |
| Robin_Watts | Maybe, the smart thing to do would be for you to tell me how to do what you're doing in gs is? | 16:55.54 |
| mvrhel2 | but there is another plane that has alpha values that show only the circlies | 16:55.57 |
| Robin_Watts | mvrhel2: Right. That sounds like a shape plane. | 16:56.11 |
| mvrhel2 | but it is not shape | 16:56.18 |
| | as it is not binary | 16:56.22 |
| Robin_Watts | oh, right. wierd. | 16:56.33 |
| mvrhel2 | hold on | 16:56.43 |
| | Robin_Watts: to view this stuff you need photoshop or a way to view n-channel images | 16:57.03 |
| Robin_Watts | ah, no luck there then. | 16:57.33 |
| mvrhel2 | I can make screen snapshot though | 16:57.46 |
| | for you | 16:57.48 |
| Robin_Watts | Thanks. | 16:58.46 |
| mvrhel2 | It will be the information of the final group blend | 16:59.20 |
| | phone | 17:01.54 |
| henrys | marcosw:back from the meeting - yes the bbox is a problem. Do you want to go through the bugs? | 17:09.33 |
| | tor8:are you around? | 17:09.54 |
| | in all the hurry we forgot about a mupdf release. | 17:10.16 |
| Robin_Watts | henrys: tor8 and I spoke about that the other day. | 17:10.40 |
| | He'd like a bit longer to keep bashing on the text stuff. | 17:10.53 |
| henrys | I need something for the newletter. | 17:11.11 |
| | okay so you want to skip this release period entirely? | 17:11.33 |
| Robin_Watts | "Forthcoming release of mupdf to include..." | 17:11.37 |
| | no, I thought he'd like to release in a month or so. | 17:11.48 |
| henrys | "forthcoming" is fine for the newletter. | 17:12.11 |
| | if you see him before I do will you ask him to send something, he can send it to me or chrisl_away's gs addressees. | 17:13.12 |
| Robin_Watts | I have a whole batch of evil plans for mupdf that tor8 is not so keen on :) | 17:13.21 |
| | mvrhel2: For when you come back from the phone. http://ghostscript.com/~robin/hate6.pdf is a new version of the file that puts a large white rectangle behind everything. This should hopefully result in the alpha on the copied in background being all 1, so being the same as I have here. This makes no difference to the rendering in acrobat. | 17:15.50 |
| marcosw | henrys: yes, in a minute. | 17:16.40 |
| | make that 15 minutes | 17:28.16 |
| henrys | okay I can also do it myself if you have other stuff to do, no big deal. | 17:28.53 |
| marcosw | I | 17:29.03 |
| | I'm ready now. I was just distracted by some make issues | 17:29.24 |
| | do we want to go back one or two weeks? | 17:29.45 |
| henrys | okay so 692386 looks like it should go to alexcher | 17:29.49 |
| | can we do this week first then go back? | 17:30.05 |
| mvrhel2 | Robin_Watts: I am back now | 17:30.17 |
| marcosw | sounds good | 17:30.19 |
| mvrhel2 | let me put my images up real quick | 17:30.27 |
| Robin_Watts | mvrhel2: Thanks. | 17:30.32 |
| henrys | you can drive 692 to alexcher | 17:30.35 |
| | 386 | 17:30.40 |
| marcosw | done | 17:30.51 |
| | i can look at 389, if it's a pdfwrite issue I'll assign to Ken | 17:31.32 |
| henrys | right. | 17:31.42 |
| marcosw | 390 looks good as is | 17:32.02 |
| | or maybe it should be closed? | 17:32.46 |
| mvrhel2 | http://www.ghostscript.com/~mvrhel/Group1.png | 17:32.47 |
| | http://www.ghostscript.com/~mvrhel/Group2.png | 17:32.53 |
| henrys | alexcher are you around? | 17:33.12 |
| | I'd close it but either way. | 17:33.20 |
| mvrhel2 | Robin_Watts: so that is what is in the planes of data on the final blend in gs | 17:33.27 |
| henrys | 392 I'd like p1 | 17:33.28 |
| Robin_Watts | mvrhel2: Right. | 17:33.52 |
| marcosw | I should have made 392 P2, since it's a regression, but I've now made it P1. | 17:34.20 |
| Robin_Watts | mvrhel2: I have an even more simplified file http://ghostscript.com/~robin/hate7.pdf | 17:35.27 |
| henrys | 394 is fine | 17:35.38 |
| marcosw | 394 may or not be a pdfwrite issue, but let's let Ken decide | 17:35.46 |
| | 395 may or not be a pdfwrite issue, but let's let Tor decide | 17:36.30 |
| henrys | okay | 17:36.43 |
| mvrhel2 | Robin_Watts: can we talk for a sec about the planar halftone stuff | 17:36.53 |
| | basically where we are | 17:36.57 |
| marcosw | who is responsible for the bbox? | 17:37.03 |
| mvrhel2 | did you have a simple file that has the issue? I can't recall | 17:37.20 |
| henrys | 396 a regression | 17:37.24 |
| | ? | 17:37.25 |
| | and is snowflak the only file that crashes? | 17:38.05 |
| Robin_Watts | mvrhel2: hate7.pdf is the simplest file I've made so far that shows it. | 17:38.08 |
| marcosw | I don't think it's a regression (or at least it's not recent, since 8.53 also locks up). | 17:38.30 |
| mvrhel2 | Robin_Watts: I mean with respect to the planar hafltone pattern issue | 17:38.33 |
| | sorry | 17:38.36 |
| henrys | I'll take the bbox give it to me. | 17:38.43 |
| marcosw | I believe the only file in examples that locks up is snowflak.ps | 17:38.49 |
| Robin_Watts | Sorry, stepped out and missed the change of subject :) | 17:38.58 |
| marcosw | should it be higher than P4 since it's a lockup? | 17:39.01 |
| henrys | p1 | 17:39.08 |
| Robin_Watts | mvrhel2: I don't believe I had a 'simple' file, no. | 17:39.25 |
| marcosw | done | 17:39.28 |
| Robin_Watts | I'm struggling to remember what the problem was... | 17:39.46 |
| mvrhel2 | Robin_Watts: ok. me too. I may just do a cluster push and see what seg faults and go from there | 17:40.24 |
| henrys | so for these devices - we should look through the source for an email address and ping them it is broken and disable it. | 17:40.26 |
| mvrhel2 | oh wait | 17:40.31 |
| Robin_Watts | I know I tried to use lj4700 or something to do some timings, but for some reason that lead me to somewhere else. | 17:40.31 |
| | all-rops.pxl if memory serves. | 17:40.38 |
| mvrhel2 | we dont do plank device in regression testing do we | 17:40.55 |
| Robin_Watts | mvrhel2: We don't, no. | 17:41.03 |
| henrys | marcosw: you can assign the device stuff to me. | 17:41.18 |
| mvrhel2 | it would be handy to add that and to be able to pick only that device for regression testing | 17:41.26 |
| marcosw | I'll disable the imsdi and the wts devices. | 17:41.37 |
| Robin_Watts | mvrhel2: But what would it compare to? :) | 17:41.40 |
| mvrhel2 | well with and without the new stuff on | 17:41.52 |
| | plank works with the current code yes? | 17:42.07 |
| henrys | marcosw:be careful to do the other languages which use those devices. | 17:42.14 |
| Robin_Watts | A neat trick would be to somehow make the plank device appear to be the pkmraw device. | 17:42.36 |
| marcosw | thanks for the warning | 17:42.38 |
| henrys | assign any of the device problem you don't want to do to me. | 17:43.01 |
| mvrhel2 | Robin_Watts: oh the plank device can't output a ppm type output? | 17:43.17 |
| marcosw | will do. | 17:43.17 |
| Robin_Watts | yes, it should work with the current code. (Can't see why not) | 17:43.20 |
| mvrhel2 | cant we enable that? | 17:43.21 |
| marcosw | does that include 405? | 17:43.22 |
| henrys | yes | 17:43.29 |
| Robin_Watts | plank outputs pkm. | 17:43.30 |
| | plan outputs ppm. | 17:43.38 |
| mvrhel2 | ok so why can't we compare that? | 17:43.43 |
| Robin_Watts | planb outputs pbm | 17:43.43 |
| | mvrhel2: The cluster only compares a device to the results it gave on the previous run. | 17:44.03 |
| mvrhel2 | yes | 17:44.07 |
| henrys | marcosw:so that's it for this report | 17:44.08 |
| mvrhel2 | well if the head has one output | 17:44.16 |
| | and I change to turn on the thresholding | 17:44.26 |
| | it should compare | 17:44.28 |
| marcosw | btw, I'll have x11 and x11alpha testing added to the regression stuff soon, though I wasn't planning on doing all the other x11 variants. Should I? | 17:44.31 |
| Robin_Watts | So, first we need to check that plank is giving the same results are pkmraw. (i.e. check that the planar device itself isn't broken). | 17:44.40 |
| | Then we need to compare the planar device with/without halftoning gives the same results. | 17:44.58 |
| mvrhel2 | Robin_Watts: I thought since you made the plank device, it was already checked to be ok | 17:45.16 |
| | that that the issue was my stuff | 17:45.26 |
| henrys | I'd say x11alpha and x11cmyk would be two good choices. | 17:45.28 |
| Robin_Watts | mvrhel2: No, no clustertesting has been done on it. | 17:45.35 |
| henrys | marcosw:we don't break 24 bit often. | 17:45.55 |
| marcosw | since x11 is now the default device I figured we should test it. | 17:46.14 |
| Robin_Watts | There are definite issues with your stuff. | 17:46.15 |
| mvrhel2 | right and it is those that I want to catch | 17:46.25 |
| Robin_Watts | but I wouldn't like to swear there aren't issues with my stuff too. | 17:46.27 |
| henrys | marcosw:x11alpha is the default | 17:46.33 |
| mvrhel2 | and I think I can if we do what I mentioned | 17:46.35 |
| | which is just add the device now | 17:46.43 |
| henrys | x11 is default for pcl. | 17:46.44 |
| mvrhel2 | and make it so that I can do a clusterpush to test just that device | 17:47.00 |
| | with my stuff | 17:47.09 |
| | against not my stuff | 17:47.14 |
| henrys | marcosw:I have brough up the 7/28 report | 17:47.18 |
| marcosw | sorry, I checked the 902 release build and x11 was the default, didn't realize it had changed. | 17:47.20 |
| Robin_Watts | If we just add the device, then we can certainly test your stuff against not your stuff, yes. | 17:47.21 |
| mvrhel2 | exactly | 17:47.27 |
| | I guess being the only planar device, that is the only one that will really have diffs | 17:47.53 |
| marcosw | what's the the first bug number on that report? | 17:48.03 |
| mvrhel2 | but to make the cluster run faster it would be nice to just test it | 17:48.05 |
| henrys | 369 | 17:48.24 |
| mvrhel2 | when marcosw and henrys are done with their meeting I will ask marcosw about this | 17:48.44 |
| henrys | 369 I'll check in a fix today and close it. | 17:49.07 |
| marcosw | speaking of x11alpha | 17:49.08 |
| mvrhel2 | I want to get this wrapped up before our meeting | 17:49.12 |
| marcosw | 375 is mine | 17:49.30 |
| Robin_Watts | I fear it will be hard for marcosw to add a device just for user clusterpushes. | 17:49.42 |
| marcosw | hold on | 17:50.19 |
| Robin_Watts | Let's wait for marcosw to finish his meeting with henrys before dancing in his peripheral vision :) | 17:51.02 |
| henrys | 378 is michael's customer bug. | 17:51.09 |
| marcosw | I'm back. | 17:51.35 |
| Robin_Watts | mvrhel2: Can we look back at hate7.pdf while we wait? | 17:51.55 |
| marcosw | 386 looks okay as is. | 17:52.07 |
| henrys | marcosw:I don't see anything else with that report. | 17:52.17 |
| marcosw | and that brings us back to Do | 17:52.37 |
| | (or perhaps Doe) | 17:52.45 |
| Robin_Watts | D'Oh. | 17:52.53 |
| henrys | marcosw:did we do the 21st report? | 17:53.08 |
| marcosw | I don't recall, we can take quick look. | 17:53.35 |
| Robin_Watts | http://www.youtube.com/watch?v=mvph0eSb-Hg | 17:53.47 |
| marcosw | I should deal with 344 | 17:55.09 |
| henrys | well 343. are we wrong or is the file bogus? | 17:55.34 |
| Robin_Watts | mvrhel2: http://ghostscript.com/~robin/dump7.zip | 17:56.26 |
| henrys | marcosw:344 has "the customer reports" and no customer number. | 17:56.32 |
| mvrhel2 | hold on brb | 17:56.43 |
| marcosw | If I try to open the first file attached to 343 with evince it asks for a password. | 17:57.37 |
| henrys | alexcher are you around? | 17:58.02 |
| Robin_Watts | mvrhel2: I gotta walk the dogs, back later. IF you're available then, can we pick it up then? If not, never mind. Thanks. | 17:58.33 |
| henrys | well you can put a note in there we'd like clarification, bug or no for alexcher. | 17:58.48 |
| mvrhel2 | ok I am back | 18:00.27 |
| | oops | 18:00.30 |
| marcosw | done. | 18:00.36 |
| mvrhel2 | sorry Robin_Watts | 18:00.48 |
| henrys | he's walking the dogs. | 18:01.08 |
| marcosw | I think the rest of the bugs from that bug report are all correctly assigned. | 18:02.23 |
| henrys | okay. I think mvrhel2 and Robin_Watts want some of your time. I might add a few comments in here. | 18:02.59 |
| | in the bugs that is. | 18:03.09 |
| marcosw | okay. | 18:03.19 |
| mvrhel2 | hi marcosw: I wanted to see if we could add the plank device to the tested devices | 18:04.47 |
| | as I am hoping to fix my thresholding issues | 18:05.01 |
| marcosw | what is the plank device? Is it even enabled by default? | 18:05.28 |
| mvrhel2 | it is a planar CMYK device | 18:06.24 |
| | it is built in by default I believe | 18:06.33 |
| | I believe it dumps out ppm output. let me double check | 18:06.50 |
| | pkm output | 18:06.56 |
| marcosw | does one enable it by editing the Makfile? | 18:07.37 |
| henrys | I think it is just in pcl now, yes just add it. | 18:08.34 |
| marcosw | it appears to generate a PAM file. | 18:10.13 |
| mvrhel2 | ok yes | 18:10.20 |
| | marcosw: I don't know if this is easy or possible but it would be really nice to be able to do a cluster push and just pick that device for me | 18:10.56 |
| | as my changes will only affect it | 18:11.09 |
| | as I work through this | 18:11.19 |
| | if not if is fine | 18:11.32 |
| | if not, it is fine | 18:11.37 |
| marcosw | it's hard to just add devices to clusterpush and not the the commit regression. Also bmpcmp couldn't handle that format (I don't think), but I suppose that could be fixed. | 18:12.07 |
| | I have to run for a Skype call/meeting. I'll back in 30 minutes or so. | 18:13.11 |
| mvrhel2 | ok | 18:13.27 |
| Robin_Watts | bmpcmp can handle it. | 18:37.58 |
| | I believe. | 18:38.09 |
| | oh, 1bpp, maybe not. | 18:38.21 |
| | mvrhel2: Back now - any chance we can look at hate7.pdf please? | 18:38.57 |
| | It's a simpler file, and I'd love to know what gs makes of it. | 18:39.10 |
| | mupdf can't do plotting operations that involve blendmodes, so we fake it using groups. | 18:39.43 |
| | It's possible that that is what is going wrong. | 18:39.52 |
| | Gah. The formulae in adodes docs contradict one another :( | 18:48.31 |
| Robin_Watts | pops downstairs, but will keep checking back in case mvrhel2 returns. | 19:11.38 |
| | I can't even see how to make this work on paper :( | 19:17.09 |
| | mvrhel2: Well, I can view the gs debug stuff in a hex editor. | 20:40.06 |
| | Assuming you mean the RAW_DUMP stuff. | 20:40.26 |
| | I'll try and understand the actual maths its doing tomorrow. | 20:40.51 |
| | henrys: Did you get the Memento memory squeezing stuff working ? | 20:41.05 |
| henrys | Robin_Watts:not yet I should do that before you leave though in case I have questions. | 21:04.40 |
| | Forward 1 day (to 2011/08/05)>>> | |
IRC Logs
