| | <<<Back 1 day (to 2012/05/30) | 2012/05/31 |
| sebras | tor8: http://libgit2.github.com/ | 00:16.49 |
| jen_ | Hello. Where can i get some instructions on compiling GS on Mac Lion OS? | 02:31.54 |
| kens | chrisl I replied to that pushy support email from the free user and also informed Scott and Miles that maybe they should be contacted about support contracts | 07:17.27 |
| chrisl | kens: I saw your reply - you were considerably more polite than I was feeling at that point - my thoughts were more a paraphrase of "go forth and multiply"....... | 07:21.10 |
| kens | Yeah well I thought I should be polite, and I'm feeling reasonably generous, since its the morning | 07:21.38 |
| | I tend to be less polite by the end of the day | 07:21.46 |
| | I was less polite on the bug report | 07:21.57 |
| chrisl | I seem to be getting less tolerant of people like that | 07:23.01 |
| kens | :) Comes with age.... | 07:23.13 |
| chrisl | You may well be right | 07:23.55 |
| kens | Well, I'm less tolerant than I was once, I'msure | 07:24.12 |
| | And more cynical.... | 07:24.25 |
| chrisl | Well, being more cynical probably comes from a) working for Global for so long (with a certain R&D manager!), and b) being alive...... | 07:27.05 |
| | Surely, it can't be legal to try to prohibit class action law suits in a software license, that would be crazy...... | 07:31.20 |
| | http://tech.slashdot.org/story/12/05/30/1427252/windows-8-more-eula-fewer-rights | 07:31.43 |
| kens | Oh yeah so that in the Register yesterday | 07:47.13 |
| | I imagine the first thing that will happen is a class action against the EULA :) | 07:47.37 |
| vivek_ | Ghostscript conversion error | 10:20.35 |
| Robin_Watts | Fair enough. | 10:30.42 |
| tor8 | Robin_Watts: odd, pdf_copy_array/dict aren't used. wonder why they remained when some of the other functions got purged... | 11:15.21 |
| Robin_Watts | tor8: Eh? | 11:15.35 |
| | pdf_write uses them. | 11:15.50 |
| | so does mupdfposter | 11:15.58 |
| tor8 | ah, right, I was only grepping for copy_array | 11:16.33 |
| Robin_Watts | Hmm. Maybe pdf_copy_array is only used in my linearisation stuff. | 11:16.43 |
| tor8 | still haven't had my morning coffeine :) | 11:16.49 |
| Robin_Watts | I had it all working yesterday. | 11:17.06 |
| | Then I tried to update the bubblesort to heapsort. And now it doesn't work. | 11:17.18 |
| tor8 | copy_array may have been a remnant from deep_copy_dict & friends | 11:17.22 |
| | which were never used | 11:17.37 |
| | shellsort? it's almost as easy as bubble sort :) | 11:17.51 |
| Robin_Watts | heapsort: O(n log n) worst case. | 11:18.11 |
| | And it'd be dead easy if I could get the comparison function right. | 11:18.30 |
| tor8 | pdf_write_doc doesn't use copy_dict (maybe it does in your linearization work though) | 11:19.14 |
| Robin_Watts | copystream uses it for me. | 11:19.31 |
| | and in various other places. | 11:19.48 |
| tor8 | oh, did you add it when making the write_document non-destructive? | 11:21.05 |
| Robin_Watts | possibly, yes. | 11:21.13 |
| tor8 | I may be sitting on stale code here on my viewer branch | 11:21.16 |
| Robin_Watts | Though I won't swear that saving is entirely non-destructuve yet. | 11:21.33 |
| | zeniko threw the toys out of the pram yesterday over shellys commit. | 11:43.44 |
| tor8 | :/ | 11:47.46 |
| Robin_Watts | unleashes linearisation onto casper. | 11:47.58 |
| | Damn. Should have let you review it first :( | 11:48.10 |
| tor8 | it's on robin/master isn't it? | 11:48.32 |
| Robin_Watts | Have a look and if you see anything you dislike I'll fix it. | 11:48.37 |
| | on master, I believe. | 11:48.57 |
| tor8 | s/file/flag/ in the commit message :) | 11:49.03 |
| Robin_Watts | D'Oh. | 11:49.31 |
| tor8 | I only see it in your repo | 11:49.39 |
| Robin_Watts | I see it in the master one too. | 11:49.50 |
| tor8 | odd, git fetch didn't fetch origin. maybe because I'm on a tracking branch on another repo. | 11:50.21 |
| | but yes, I do see it on casper now | 11:50.34 |
| Robin_Watts | Hmm. Is there an accepted term to use for the main casper repo? I have it as a remote here called 'golden' | 11:50.47 |
| tor8 | my remote is called 'origin' | 11:51.45 |
| Robin_Watts | origin = my personal repo on casper | 11:52.09 |
| tor8 | pdf_new_ref should use pdf_create_object and pdf_update_object I think | 11:55.46 |
| | I have all personal repos on casper under their owner's username | 11:56.07 |
| | so robin, paul, tor, sebras, etc | 11:56.14 |
| | and the local repos on my machines in the office under their host names | 11:57.02 |
| | Robin_Watts: ^ about pdf_new_ref. also not thrilled about pdf_set_int but I can't think of a more elegant solution. | 12:00.42 |
| Robin_Watts | ok. will get those fixed. | 12:04.22 |
| tor8 | my gripe with pdf_set_int is that I liked the non-array/dict objects to be immutable | 12:06.38 |
| | but it's no biggie, as long as it stays private and nobody but the linearisation uses it | 12:07.04 |
| Robin_Watts | tor8: So, to be clear... you'd like me to reimplement pdf_new_ref so it calls pdf_create_object, then pdf_new_indirect, then pdf_update_object ? | 12:12.01 |
| | I suspect that will end up with more code being used :( | 12:12.30 |
| tor8 | { num = pdf_create_object(); pdf_update_object(num, obj); return fz_new_indirect(num); } | 12:12.58 |
| | three lines :) | 12:13.14 |
| | and reduce the number of places that depend on the inner workings of the xref_entry | 12:13.35 |
| Robin_Watts | ok. Means lots of shuffling we don't need, but... ok. | 12:13.59 |
| tor8 | you can keep the new_ref wrapper function. not sure what you mean by shuffling. | 12:14.26 |
| Robin_Watts | Never mind. | 12:15.17 |
| | fz_dict_put should presumably be pdf_dict_put ? | 12:18.06 |
| | tor8: fixes pushed. | 12:21.59 |
| kens | Robin_Watts : yourlinearization code seems to have broken the MuPDF build on the cluster | 12:22.45 |
| tor8 | Robin_Watts: yes, that one must've slipped through the net | 12:23.12 |
| Robin_Watts | thanks. | 12:23.13 |
| | kens^ | 12:23.19 |
| kens | I wasn't sure if that was the fixes you were referring too | 12:23.34 |
| | to* | 12:23.37 |
| Robin_Watts | Bugger. | 12:25.15 |
| | tor8: I'm going to roll the last 2 commits together with the fix for the cluster compile failure and force push it, so we have a nice history. | 12:25.45 |
| tor8 | Robin_Watts: can't compile on linux. log2 conflict | 12:25.56 |
| | Robin_Watts: okay. | 12:26.04 |
| Robin_Watts | tor8: Yes, I have that fix here. | 12:26.07 |
| tor8 | line 1178 has an unused variable | 12:26.32 |
| Robin_Watts | and that. | 12:26.41 |
| | Where is "PDFusingtransparency" defined ? | 14:18.50 |
| kens | MuPDF, Ghostscrtipt ? | 14:19.16 |
| Robin_Watts | ghostscript pdf interpreter postscript | 14:19.28 |
| kens | pdf_main.ps I think | 14:19.40 |
| Robin_Watts | hmm, that was perhaps less than clear. | 14:19.44 |
| | Where in pdf_main.ps | 14:19.48 |
| | I can see lots of places where it's used, but can't see where it's defined. | 14:20.00 |
| kens | Ah, now the difficutl questions :) | 14:20.04 |
| Robin_Watts | This may be my postscript crapness showing here. | 14:20.17 |
| kens | Line 1815 | 14:20.23 |
| | dup pageusestransparency dup /PDFusingtransparency exch def { | 14:20.43 |
| Robin_Watts | Ah. | 14:20.48 |
| | Thanks. | 14:21.17 |
| kens | NP | 14:21.24 |
| paulgardiner | Confused: what are xobj->contents and xobj->me ? | 14:21.35 |
| Robin_Watts | Ah, are you merging? | 14:23.41 |
| | xobj->contents = the contents object for the xobject. | 14:24.22 |
| | previously, we used to load the contents object to get a buffer, and store that with the xobject | 14:24.59 |
| | That was because we used to always preload streams to buffers before executing them. | 14:25.43 |
| | That meant we used a lot of memory. | 14:25.49 |
| | Now we load them and interpret them on the fly. | 14:26.02 |
| | And me is the object that represents the xobject. | 14:27.09 |
| | For instance suppose we have "/Im0 10 0 R" in the PDF file. | 14:27.27 |
| paulgardiner | From the code I cannot see how ever me != contents (other than in some code I've added that is probably wrong) | 14:27.28 |
| Robin_Watts | That says that xobj->me will be object number 10. | 14:27.54 |
| | Inside object 10 there should be /Contents [12 0 R 13 0 R] or something. and I'd imagine that contents should = [12 0 R 13 0 R] ? | 14:28.37 |
| | BUT... you're right, the code doesn't look to be doing that. | 14:29.07 |
| paulgardiner | It may be that we don't need both any longer. In any case, I think I can see where I'm going wrong. | 14:31.41 |
| Robin_Watts | I can't see how this is working. | 14:32.31 |
| paulgardiner | Are you sure xobjects have /Contents ? | 14:33.06 |
| Robin_Watts | Ah, indeed they don't. | 14:33.27 |
| | hence me == contents at all time. | 14:33.34 |
| | Probably my fault then, sorry. | 14:33.47 |
| paulgardiner | Good. I'll make sure my code obeys that too :-) | 14:33.59 |
| Robin_Watts | We should simplify to only have ->me, I guess. | 14:34.01 |
| | sorry. | 14:34.21 |
| henrys | zeniko's bugzilla comments to shelly border on what I think is appropriate for a comment. | 14:47.14 |
| kens | Yes, it is a trifle rude there | 14:47.26 |
| Robin_Watts | yes. zeniko is prone to explosions of inappropriate rage. | 14:47.57 |
| paulgardiner | Robin_Watts, tor8: I'm calling pdf_update_stream on a xref item that (until the call) has stm_buf == NULL. I think I need to make pdf_update_stream do something to signify that the item is now a stream. What's the best thing to do? | 14:58.48 |
| Robin_Watts | When you call that function, it sets xref->table[num].stm_buf to be your new buffer. | 15:00.08 |
| | Any object for which stm_buf is non NULL is a stream. | 15:00.19 |
| paulgardiner | AH ok. There are still tests for stm_ofs > 0 in places | 15:00.42 |
| Robin_Watts | There are? | 15:01.07 |
| paulgardiner | So I should chante those to stm_ofs > 0 || stm_buf != NULL ? | 15:01.08 |
| | pdf_open_image_stream | 15:01.42 |
| | Maybe I'm not up to date, or I've messed up the rebase though. | 15:02.05 |
| Robin_Watts | pdf_is_stream tests for: xref->table[num].stm_ofs != 0 || xref->table[num].stm_buf; | 15:02.28 |
| paulgardiner | Makes sense. So probably best if I make pdf_open_image_stream call that. | 15:03.16 |
| Robin_Watts | sorry, paulgardiner, irc blipped for me. | 15:10.46 |
| paulgardiner | Robin_Watts: np. Nearly sorted I think. I just need to make sure I remove filters when updating existing streams. | 15:11.28 |
| Robin_Watts | I think I see the problems with bug 692870. | 15:12.24 |
| | Need to talk to mvrhel when he arrives. | 15:12.31 |
| tor8 | paulgardiner: oh. I might've missed 'manual' stm_ofs tests that don't call is_stream (which they ought to do instead) | 15:18.53 |
| | paulgardiner: the only caveat is to nuke or update the /Filter field in the dict as well | 15:19.12 |
| paulgardiner | tor8: So just removing it in the simplest case? | 15:19.50 |
| | Wheee! All back working. :-) | 15:21.49 |
| Robin_Watts | paulgardiner: Excellent. | 15:22.19 |
| paulgardiner | Makes much more sense having the streams stored in the xref and no longer in the xobjects. | 15:22.44 |
| | That was a hellish rebase. I may merge from now on. I'll be creating loops only in my own repo. We can collect the lot as a single commit when it goes to the main repo | 15:23.50 |
| Robin_Watts | mvrhel: Aha. | 15:25.56 |
| mvrhel | good morning | 15:26.23 |
| Robin_Watts | mvrhel, mvrhel_laptop: either of you got a mo to talk about bug 92870? | 15:26.36 |
| mvrhel | hold on a sec | 15:26.59 |
| Robin_Watts | I think I know both why it's not working for some files. Holding. | 15:27.25 |
| mvrhel | Robin_Watts: ok I am back now | 15:29.10 |
| Robin_Watts | right, so the postscript code says "if we are using transparency then push a transparency group, sets the alpha to 1, draws the thing, then pops the transparency group. | 15:31.24 |
| | and because of that, you're not setting the lop bit. | 15:32.02 |
| | If differing alpha levels was all that was going on, we'd have no problem with that approach. | 15:32.31 |
| | The problem is, we have blend modes too. | 15:32.42 |
| mvrhel | I think I disabled the lop setting also | 15:32.43 |
| Robin_Watts | You did, and I don't believe you should have. | 15:32.52 |
| | Essentially that lop setting code just sets whether any rendering operation can be considered idempotent. | 15:33.36 |
| | If alpha != 0 or 1 then it's not idempotent. | 15:33.53 |
| mvrhel | yes I understand | 15:34.02 |
| Robin_Watts | and also if the blendmode is non 0, it's non idempotent too. | 15:34.10 |
| mvrhel | I was thinking the blending would happen when the group was popped | 15:34.33 |
| | with what ever mode | 15:34.48 |
| | was set | 15:34.51 |
| Robin_Watts | Does pushing a group set the blendmode to 0 then ? | 15:35.05 |
| mvrhel | that may be the missing piece | 15:35.19 |
| | similar to what we did with the alpha value | 15:35.31 |
| Robin_Watts | exactly. | 15:35.36 |
| | I wasn't sure that the blending could happen at group pop time - but if it can, then that sounds perfect. | 15:35.54 |
| mvrhel | let me double check that | 15:36.13 |
| | hold on | 15:36.15 |
| | yes. it uses the mode and the blending procs during the group pop | 15:38.02 |
| Robin_Watts | Ok. | 15:38.10 |
| | next question, when we push a blending group, does that reset the blending mode to 0 automatically ? | 15:38.29 |
| | (I can't think of a case when we wouldn't want it to) | 15:38.40 |
| mvrhel | I dont believe so | 15:38.43 |
| | it is part of the graphic state | 15:38.46 |
| | let me check though | 15:39.12 |
| | hold on | 15:39.14 |
| Robin_Watts | if we have to manually reset it to 0 each time, then wouldn't we need to do that for the fill/stroke knockout group stuff too? | 15:39.35 |
| | Otherwise we'd see the blendmode being applied twice ? | 15:39.56 |
| mvrhel | which one are you talking about? | 15:40.04 |
| | if its a knockout, there is no blending going on | 15:40.33 |
| Robin_Watts | /B | 15:40.34 |
| | now I'm confused. | 15:41.02 |
| mvrhel | me too :) | 15:41.06 |
| | I see your point | 15:41.15 |
| | about /B | 15:41.17 |
| Robin_Watts | We've just been talking about /S, /f and /f*. We are relying on them blending when the group is pushed back, right? | 15:41.53 |
| mvrhel | I *think* I had to set alpha to 1 for the /B command due to some issue with getting the clist in sync with its parameters and the graphic state | 15:42.24 |
| Robin_Watts | And those are isolated knockout groups - so I'm confused as to how 'if it's a knockout, there is no blending going on' can fit with that. | 15:42.39 |
| | Wow. I'm now confused on 3 counts rather than the 1 count that I was confused on when we started this conversation :) | 15:44.59 |
| mvrhel | I don't see how the blend mode is a factor in the case that we are talking about right now. I suspect there is some other issue going on with patterns and transparency. Where we are not doing the knockout but should | 15:45.00 |
| Robin_Watts | Hold on. | 15:45.40 |
| mvrhel | Look at the very simple file that is the pattern file that fails | 15:45.42 |
| | which I made | 15:45.45 |
| Robin_Watts | Can we consider an even simpler example, without patterns to muddy the water ? | 15:46.21 |
| mvrhel | We (or you :) ) can I suspect that patterns are the issue here | 15:46.50 |
| Robin_Watts | just imagine a stroke that goes from 0,0 to 0,100 then to 100,100 with a linewidth of 5, and a blendmode of Darken. | 15:47.24 |
| mvrhel | rather than imagine. please create the file | 15:47.41 |
| Robin_Watts | ok. | 15:47.47 |
| mvrhel | and then lets run it through | 15:47.50 |
| | it is too easy in this stuff to convince one's self | 15:48.12 |
| Robin_Watts | gives up trying to make a ps file that shows what I want. Will try again with a pdf file. | 15:59.49 |
| mvrhel | Robin_Watts: tell me what you want | 16:00.09 |
| | I can probably make it pretty quick with in-design | 16:00.17 |
| Robin_Watts | ooh, I can use Xara. | 16:00.45 |
| | mvrhel: This may take me a while to experiment. Don't wait for me! | 16:09.41 |
| mvrhel | ok. I am working on the overprint stuff | 16:10.02 |
| | Robin_Watts: if you do want me to make a trans file let me know | 16:10.17 |
| kens | Goodnight all | 16:16.15 |
| Robin_Watts | night kens | 16:16.32 |
| | mvrhel: OK. Very simple example http://ghostscript.com/~robin/out2.pdf | 16:41.04 |
| | a 50% grey background with a simple stroke on top of it. No alpha used anywhere, but the stroke is stroked with a 'Multiply' blend mode. | 16:41.54 |
| | If you don't call 'update_pdf14_for_lop' then you can see problems at the corner of the stroke where the two segments overlap. | 16:42.43 |
| mvrhel | ok | 16:43.00 |
| Robin_Watts | So, I've got it calling update_pdf14_for_lop in my version. | 16:43.23 |
| mvrhel | What if we set the blend mode to normal within the knockout group? | 16:43.37 |
| | like we talked about | 16:43.52 |
| Robin_Watts | Let me try that. | 16:44.04 |
| | Do I need to restore the blendmode before popping the group? | 16:45.33 |
| mvrhel | is it wrapped with a graphic state save and restore? | 16:46.11 |
| | hold on | 16:46.13 |
| Robin_Watts | There is a gsave/grestore outside of the transparency group push/pop. I can put another one inside. | 16:46.47 |
| mvrhel | you should not need another one | 16:47.11 |
| | it looks like it should work | 16:47.19 |
| | that is how we get away with the setting of the opacity Robin_Watts | 16:47.34 |
| | well no | 16:48.31 |
| | you are correct I think | 16:48.35 |
| Robin_Watts | am I? I'm still getting the stroke called with a blendmode of 1. Something is wrong here. | 16:50.01 |
| mvrhel | that is what you want yes? | 16:50.49 |
| | normal blend mode? | 16:50.55 |
| Robin_Watts | Normal is 0 isn't it ? | 16:51.03 |
| mvrhel | oh yes | 16:51.40 |
| | 1 is multiply | 16:51.45 |
| | did you do a .setblendmode | 16:52.10 |
| | or something like that | 16:52.19 |
| Robin_Watts | /Normal .setblendmode | 16:52.47 |
| | but I can't see it being called. | 16:52.54 |
| mvrhel | and you have it near the alpha setting? | 16:53.29 |
| Robin_Watts | When you say "you are correct I think", what do you mean? | 16:53.31 |
| | Just after the .begintransparencygroup | 16:53.44 |
| mvrhel | oh no | 16:53.52 |
| Robin_Watts | and before the stroke call. | 16:53.56 |
| mvrhel | oh wait | 16:54.02 |
| | yes I think this is correct | 16:54.07 |
| Robin_Watts | Let me do a complete rebuild in case this is a build gotcha. | 16:54.24 |
| henrys | bbl - heading to the coffee house. | 16:54.41 |
| Robin_Watts | ooooh. | 16:58.36 |
| | Having a blendmode set, but no opacity means we still go through the slow case. | 16:58.54 |
| | oh, ignore me. I'm such a fool. | 16:59.11 |
| | mvrhel: OK, so ignoring my slight detour down moron lane, it seems to be doing what I'd expect with us setting the blendmode to NORMAL inside the transparency group (and not restoring it before the pop). Does that fit with your expectations too ? | 17:01.22 |
| mvrhel | sounds like what we want | 17:01.43 |
| Robin_Watts | Fab. So I'll test that. | 17:01.57 |
| | I wonder whether we have the same issue in the /B code. | 17:02.36 |
| mvrhel | that used the slow code | 17:02.54 |
| Robin_Watts | I mean, I think we'll get double blending won't we? | 17:03.15 |
| mvrhel | I think you are correct | 17:03.30 |
| Robin_Watts | If we have a non-zero blendmode, then it'll be blended once when it draws it, and once when the group pops. | 17:03.36 |
| | ok. | 17:03.47 |
| mvrhel | if we are not doing the slow case | 17:03.53 |
| Robin_Watts | "slow case"? | 17:04.15 |
| mvrhel | lop_pdf14 | 17:04.21 |
| | with lop_pdf14 we dont have the overlap issue do we? | 17:04.32 |
| Robin_Watts | 2 separate issues, I think. | 17:05.07 |
| mvrhel | yes. but I don't think the /B code is broken now as it is correct? | 17:05.28 |
| Robin_Watts | I think the /B case is broken. | 17:05.38 |
| mvrhel | but lop_pdf14 is used if blend mode is not normal | 17:06.03 |
| | and so there will be no overlaps | 17:06.10 |
| Robin_Watts | Right. This is completely independent of stroking and overlaps. | 17:06.17 |
| mvrhel | and so no self blending in the group | 17:06.18 |
| | So how is /B broken in the head? | 17:06.31 |
| Robin_Watts | Suppose we are in blend mode 1, we push a transparency group, we draw a square, then we pop the transparency group. | 17:06.53 |
| | AIUI (and it's quite possible I'm not following something here), when we draw the square, it will be blended with blend mode 1. | 17:07.25 |
| mvrhel | with what? | 17:07.32 |
| | nothing has been drawn in the new knockout group? | 17:07.42 |
| Robin_Watts | OK. slightly more complex example required then. | 17:07.59 |
| mvrhel | for every /B a fresh group is made | 17:08.12 |
| | it is the only thing drawn | 17:08.22 |
| Robin_Watts | Suppose we are in blend mode 1, we push a transparency group, we draw a square, then stroke the square, then pop the transparency group. | 17:08.25 |
| mvrhel | that is not how it works | 17:08.41 |
| Robin_Watts | Is it not? I thought that was exactly what /B did ? | 17:08.59 |
| mvrhel | hold on | 17:09.06 |
| | oh ok | 17:09.25 |
| | I see | 17:09.31 |
| | yes. this could be an issue | 17:09.44 |
| Robin_Watts | OK, ignore any self intersections of the stroke, and just consider the fact that the stroke and the fill will have some common pixels. | 17:09.54 |
| mvrhel | yes | 17:10.06 |
| | I understand now | 17:10.09 |
| Robin_Watts | Ok. Like I say, I will test setting the blend in there back to normal. | 17:10.14 |
| mvrhel | the overlap of the stroke and the fill | 17:10.20 |
| Robin_Watts | yes. | 17:10.23 |
| mvrhel | would get double blend | 17:10.27 |
| Robin_Watts | yeah. | 17:10.32 |
| mvrhel | sorry for being a bit slow | 17:10.44 |
| Robin_Watts | I was just typing: "sorry for making heavy weather of explaining this" :) | 17:10.57 |
| | I have the complexity test in and working. | 17:11.42 |
| mvrhel | great! | 17:11.49 |
| Robin_Watts | That was the detour down moron lane - the complexity test meant that it wasn't going through the slow case :/ | 17:12.02 |
| | s/slow/pdf14/ | 17:12.21 |
| mvrhel | right | 17:12.26 |
| Robin_Watts | I have 1 last concern with /B | 17:13.43 |
| | you do: 1 .setopacityalpha outside the .begintransparencygroup | 17:14.05 |
| | Surely that means that we can never correctly render a stroke'n'fill with alpha ? | 17:14.36 |
| mvrhel | hmm that doesnt seem right. but I know I saw this working correctly in the fts tests | 17:15.33 |
| | There are some great fts tests that have overlapping stroke/fills with different blend modes and alphas | 17:16.11 |
| | it took me a while to get them working correctly | 17:16.19 |
| | feel free to change it and see what changes | 17:16.39 |
| Robin_Watts | ok. | 17:16.55 |
| | good on shelly for managing a nice calm response. | 17:24.13 |
| mvrhel | henrys: I see that it looks like we need to get copy_alpha working with tiff_sep | 18:00.37 |
| | according to marcos' comments on bug 693048 | 18:01.07 |
| | priority wise, do I keep working on cust 532 issue with the overprint RGB stuff? | 18:01.26 |
| | I am guessing yes.... | 18:01.36 |
| henrys | mvrhel:is rayjj_ around? | 18:02.50 |
| mvrhel | he called me a bit ago | 18:03.55 |
| | I know he is working on cust 532 stuff with the transparency banding stuff | 18:04.16 |
| henrys | mvrhel:I'd like to hear what rayjj_ has to say. It seems to me the 532 stuff really is an enhancement whereas the alpha stuff is a regression. | 18:04.20 |
| | would Robin_Watts be interested in doing copy_alpha | 18:05.50 |
| | ? | 18:05.50 |
| Robin_Watts | Possibly, with several provisos: | 18:06.20 |
| mvrhel | I don't mind doing it. It just might be a bit | 18:06.23 |
| Robin_Watts | 1) I have no idea how mvrhel has done the other high level color stuff. | 18:06.34 |
| mvrhel | it would make more sense for me to do it | 18:06.50 |
| Robin_Watts | 2) It'll involve clist hackery, and that'll be horrid and slow. | 18:06.52 |
| Robin_Watts | agrees. | 18:06.55 |
| mvrhel | I already dumped one thing on Robin_Watts | 18:07.08 |
| Robin_Watts | 906 differences :( | 18:07.23 |
| mvrhel | which he seems to have finished up already... | 18:07.25 |
| | oh | 18:07.27 |
| Robin_Watts | I'm hoping they may be rounding differences; will have a look when the bmpcmp finishes | 18:08.01 |
| henrys | marcos changed that back to being a bug and it looks like Robin_Watts sped up the code at the same time. Has marcosw timed with Robin_Watts latest changes - do we really need the alpha? | 18:08.29 |
| mvrhel | this overprint stuff should not take me to long henrys. I will post a comment on the bug that I should be able to get started on the aa issue next week | 18:08.31 |
| henrys | okay fair enough. | 18:08.51 |
| Robin_Watts | henrys: Yes, marcosw was testing with my speedups in. | 18:09.01 |
| | It's probably worth profiling to see where the time is spent. | 18:09.24 |
| henrys | Robin_Watts:and you don't feel there is low hanging front on more performance improvements? | 18:09.31 |
| Robin_Watts | If significant time is in the downscaler, then there may be other things to consider (like assembly or SWAR). | 18:09.45 |
| henrys | s/front/fruit/ | 18:09.48 |
| Robin_Watts | but I fear the time is elsewhere. | 18:10.05 |
| | (having it all in one place would be too nice :) ) | 18:10.18 |
| henrys | mvrhel:sounds like a comment and continue on with 532 and we'll talk next week. | 18:10.50 |
| mvrhel | ok | 18:11.03 |
| | oh interesting | 18:40.18 |
| | my overprint test seems to work | 18:40.33 |
| | This may end up being less work than I had thought | 18:40.59 |
| Robin_Watts | nice | 18:41.13 |
| mvrhel | of course I am always an optimist. You would think I would learn with ghostscript by now | 18:41.36 |
| | ok. I had to enable -dUseFastColor to make sure color management is turned off | 18:44.25 |
| | else we end up with some stuff color managed and the overprint stuff not | 18:44.42 |
| Robin_Watts | Presumably whether it works or not is only the first step? 532 are going to want it to work fast, right? | 18:49.51 |
| mvrhel | just found out they use fast color | 19:03.30 |
| | so all is well | 19:03.32 |
| | need to check clist and I need to make a K overprint test case | 19:03.46 |
| Robin_Watts | Bah. Still getting way too many differences with this. It looks like I'm not seeing alpha working any more. | 19:08.46 |
| | I'll have to debug through it tomorrow. | 19:08.52 |
| mvrhel | ok . ping me in my morning if you need anything | 19:10.25 |
| | ok made my funky black overprint example | 19:13.52 |
| | now to watch my stuff explode | 19:13.58 |
| | and sure enough the black was drawn as white | 19:14.49 |
| | ok. time for lunch on that note | 19:15.21 |
| | ugh overprint of black is going to be difficult | 19:54.05 |
| | or at least take a bit more work | 19:54.30 |
| | on the plus side the clist is ok | 19:58.46 |
| | actually the K stuff is going to be not too hard | 20:57.12 |
| | bbiaw | 20:57.13 |
| | henrys: so I should be able to wrap up this overprint RGB stuff somewhat reasonablly | 20:57.47 |
| henrys | that's really good news | 21:32.12 |
| | Forward 1 day (to 2012/06/01)>>> | |
IRC Logs