| | <<<Back 1 day (to 2012/07/24) | 2012/07/25 |
| ray_work | Robin_Watts: I'll mention that to mvrhel later when I talk to him about another color related issue | 00:28.01 |
| mvrhel | cmd_put_color? | 04:44.44 |
| | oh | 04:45.27 |
| | that should never be called if we have a devn color | 04:46.01 |
| | if you have an case file where it is, please share it with me Robin_Watts | 04:47.21 |
| ray_laptop | mvhel: (for the logs) I'll chat with you in the morning about color_usage, etc. | 06:06.10 |
| chrisl | kens: are you noticing any problems with gmail this morning? | 07:03.00 |
| kens | chrisl no, I've received mail overnight, and it 'seems' to be OK. I'll go log in | 07:03.24 |
| | Nothing in my Inbox, so it seems to have worked | 07:03.58 |
| | What problem are you seeing ? | 07:04.35 |
| chrisl | I'm getting mail to my inbox, but I have filters which direct gs-bugs, gs-commits etc into "labels" automatically - via imap, the labels/folders aren't being updated (I can see new mails in webmail) | 07:04.50 |
| kens | Oh, well I don't have any of that, I pull all my mail into Eudora locally | 07:05.16 |
| chrisl | So, Eudora doesn't see your gmail spam folder, or any of those automatically created labels? | 07:06.24 |
| kens | No, I'm afraid not | 07:06.32 |
| | Only my Inbox goes to Eudora | 07:06.42 |
| | I do all my sorting locally too | 07:06.53 |
| chrisl | Oh, well, I'll use webmail for a day or two, and if it doesn't start to work again, I'll brave the google support system...... | 07:07.13 |
| kens | shudders | 07:07.24 |
| chrisl | Yep, doesn't fill me with joy, either :-( | 07:07.38 |
| ray_laptop | I also use a local email tool (download via POP) that way I can search/read email offline | 07:16.24 |
| | I use Thunderbird. I know Miles (at least used to) use Eudora | 07:16.51 |
| | I don't trust web mail that much yet (even when my laptop was crashing it was more available and responsive than web mail) | 07:17.38 |
| kens | I don't have a problem with web mail but I like to be able to search mail when not online | 07:18.06 |
| chrisl | ray_laptop: I have thunderbird configured to work over imap, *and* store mails locally - so changes I make in thuderbird are automatically reflected on the gmail server, but I can also still access mails offline. | 07:18.07 |
| ray_laptop | chrisl: yeah, I thought about IMAP but decided POP was OK for me | 07:18.45 |
| | since I send through gmail, my gmail 'sent' folder mirrors my local sent folder | 07:19.25 |
| chrisl | ray_laptop: I primarily use tbird, but I also use the webmail at times, so it's nice to have both in sync - although, at the moment, tbird isn't seeing folder updates on the server :-( | 07:19.55 |
| ray_laptop | I didn't want google training on my local 'delete to trash' acitions -- most of the regression reports go to trash, but I want to see them before they go | 07:20.50 |
| | since gmail spam, etc. heuristics are a black box, I don't want it getting too aggressive. As it is I still occassionally end up with real email in "Spam" | 07:22.13 |
| chrisl | Hmm, does gmail learn that way? That would be a really bad way to learn about spam! | 07:22.44 |
| kens | chrisl looks like testing LZW is going to be more involved than I had hoped. | 07:49.11 |
| | THe compression stuff for non images isn't set up for LZW, it looks to see if the compression is Flate and if its not, it assumes (and sets up for) uncompressed | 07:49.45 |
| | There is no provision for LZW encoding pages and resoruces at all | 07:50.06 |
| chrisl | kens: I feel I should be surprised at that, but somehow, I'm not..... | 07:51.42 |
| kens | Pretty much how I feel :-( | 07:51.56 |
| chrisl | I don't suppose it's hackable, just to see the results? | 07:52.29 |
| kens | No, there's a bunch of setup that needs to be done, take a look at 'none_to_stream' in gdevpdfu.c at about line 885 | 07:53.18 |
| chrisl | Oh, how about using hacking pdfinflt.ps to write out lzw streams, instead of plain? | 07:53.34 |
| | s/hacking/a hacked | 07:53.51 |
| kens | Possible, but I'd rather do the work in pdfwrite because I'm not sure what else that might do | 07:54.07 |
| chrisl | It's just, given that it's rather a long shot, you might not want to spend too much time just to try it out | 07:55.03 |
| kens | You're right, and I don't :-) | 07:55.13 |
| | the Flate options may be more fruitful | 07:55.22 |
| | I see we are using Z_DEFAULT_COMPRESSION | 07:55.33 |
| | the defaults may not be the best.... | 07:55.55 |
| | Well chaning to BEST_COMPRESSION saves us 5k out of 350k | 08:00.43 |
| | Doesn't really seem worht it. | 08:00.54 |
| chrisl | Maybe the data type setting will help more? | 08:01.54 |
| kens | The Strategy ? | 08:02.06 |
| | I read the zlib.h and it looked like 'default' was likely to be the best as it does maximum string matching | 08:02.23 |
| chrisl | No, Z_TEXT | 08:02.40 |
| kens | Hmm, missed that, let me look at zlib.h again | 08:02.56 |
| chrisl | It's the block after the strategy settings | 08:03.09 |
| kens | Yes I see it | 08:03.14 |
| | We don't seem to be setting it | 08:03.19 |
| chrisl | So, probably using Z_BINARY then | 08:03.37 |
| kens | I would guess so, I need to find out where teh flags in the stream structure are being passed to zlib I think | 08:03.56 |
| | So I can figure out how to change this stuff | 08:04.06 |
| chrisl | It still might be worth trying the strategy settings - maybe the larger window size is working against us, in this case..... | 08:04.59 |
| kens | I gues that's possible | 08:05.09 |
| | I'm more interested in trying the Z_TEXT | 08:05.20 |
| chrisl | I must admit, I can't remember what that will do - potentially, it could improve things a lot.... | 08:06.08 |
| kens | Hmm, deflateInit2 doesn't seem to take a data type | 08:06.12 |
| | "deflate() may update strm->data_type if it can make a good guess about | 08:07.37 |
| | the input data type (Z_BINARY or Z_TEXT). In doubt, the data is considered | 08:07.37 |
| | binary. This field is only for information purposes and does not affect the | 08:07.37 |
| | compression algorithm in any manner" | 08:07.37 |
| | So it seems it doesn't actually do anything | 08:07.47 |
| chrisl | Oh, crap - pointless waste of time, then.... | 08:08.12 |
| kens | I guess it explains why tehre's no way to set it :) | 08:08.24 |
| | Trying Z_FILTERED strategy now | 08:10.34 |
| | With BEST_COMPRESSION | 08:10.44 |
| | That won another 2k | 08:11.45 |
| | For a total 0f 7k out of 350 | 08:11.56 |
| | SOmewhat 're-arranging the deck chairs' really | 08:12.19 |
| chrisl | Yep, I doubt it will be enough to keep them happy. | 08:12.36 |
| kens | Acrobat is better than half | 08:12.53 |
| | Actually 4 times better | 08:13.07 |
| chrisl | Didn't they say that our output interpreted faster than Acrobat's, though? | 08:13.27 |
| kens | I don't recall tehm saying that, but I suspect it is true | 08:13.52 |
| | a 'moveto' is quicker than a 'concat' | 08:14.02 |
| | And there are many thousand of these | 08:14.21 |
| chrisl | So for the vast majority of people, replicating Acrobat's style would be a retrograde step | 08:14.31 |
| kens | Well... | 08:14.43 |
| | I would say for most people there is little difference either way | 08:14.52 |
| | For these particular files it *may* be (i'm really guessing slightly) that Distiller's outptu compresses better, at the cost of slower processing | 08:15.26 |
| | I think you need a stupid file like this to really exhibit the 'problem' | 08:16.02 |
| | I guess I'll try and see if I can change the path emission code to be more like Distiller | 08:16.23 |
| | Its kind of nagging me slightly | 08:16.34 |
| | But I don't want to spend huge amounts of time on it | 08:16.46 |
| chrisl | I'm just thinking that it would be a lot of effort to go to, to make things (even a tiny bit) worse for most people, just for the customer in question | 08:16.55 |
| kens | I guess we could have Yet Another Command Line Parameter | 08:17.16 |
| chrisl | No, I reckon that would almost certainly end up with the Acrobat style code bit-rotting, because no one else would use it | 08:18.08 |
| kens | :) | 08:18.14 |
| | I think that's unlikely, the emission would all be in one place (I *think*) | 08:18.49 |
| | But this is pdfwrite, so I'm not going to stake anything on that claim | 08:19.04 |
| | Aha, I think I've found a way to implement LZW | 08:21.47 |
| | Oh that's much worse | 08:23.14 |
| | increases the stream size by 150Kb | 08:23.41 |
| chrisl | Yeh, nothing seems to manage better than flate :-( | 08:32.31 |
| kens | I'm inclined to change the compression to 'BEST' anyway for pdfwrite. Its minor but its probably worth having. Also maybe changing to Z_FILTERED. Even small improvements are nice to have. | 08:33.35 |
| | I cna see where the path is emitted, it'll take some recoding to get teh Acrobat style emitted instead | 08:34.00 |
| | And (at least as things currently stand) it'll affect the output of paths in all vector devices (so pdfwrite and ps2write ;-) | 08:34.36 |
| | I'm thining of deferring the 'beginpath' until we get an actual line segment, and then calling the beginpath method with teh current point at the start of the line. | 08:35.33 |
| chrisl | I don't suppose the matrix is written out anywhere near where the path is emitted? | 08:35.51 |
| kens | Don't be ridiculous ;-) | 08:36.08 |
| chrisl | Oh, well.... just a thought | 08:36.28 |
| kens | The way I'm thinking of the beginpath could either emit a concat or just a moveto | 08:36.32 |
| | I need to think some more about lineto and subsequent moveto though | 08:37.11 |
| | I can probably make something good enough for testing reasonably quickly | 08:37.46 |
| chrisl | Personally, I would favour just opting for one representation, and using that | 08:39.18 |
| kens | Well ps2write could use an rmoveto which would be more efficient than either the current method or the Distiller one (for PostScript) | 08:40.11 |
| | To be honest this looks like a place where we could make some improvements anway. | 08:40.51 |
| chrisl | I'm looking at the Acrobat output, and that part of it does look almost tailored for high compression ratios | 08:41.28 |
| kens | I'm inclined to think that's what its all about | 08:41.42 |
| | Note that it doesn't do it throughout which puzzles me slightly | 08:41.58 |
| | As I noted there are some other places where it does things slightly better than we do. | 08:42.17 |
| | It omits some pointless clip paths | 08:42.30 |
| | And does more things as rectangles (I think) | 08:42.43 |
| | But I think those are comparatively minor | 08:42.56 |
| | Its the sheer number of these tiny little strokes which seems to be the killer | 08:43.16 |
| chrisl | Well, we know Distiller has more than a few weird heuristics - we'll never really know what can trigger any given one | 08:43.36 |
| kens | I'm going to have a go at coding something similar, we'll see what happens later. Its going to take me a little while | 08:44.09 |
| | And I'm going out in about an hour, it'll take me longer than that | 08:44.29 |
| | Oh, actually 45 minutes, its later than I thought | 08:44.48 |
| chrisl | Yeh, I'll be heading out in a half hour or so, too | 08:45.20 |
| kens | Squash ? | 08:45.43 |
| chrisl | Yes, bit a training - so I can really enjoy the warm weather <sigh> | 08:46.10 |
| kens | Ah, I'm anticipating the ground being dry enough to go out today, so I'm hoping to enjoy the sunshine :-) | 08:46.32 |
| chrisl | It should be nice outside - depending on which court we end up on, it could be pleasant, or sauna-like | 08:47.31 |
| kens | suspects sauna, its hot here already | 08:47.59 |
| chrisl | There are two courts at the club which won't get direct sunshine on the outside walls until after lunchtime, those should be a reasonable temperature. The other four courts' walls will have had direct sunshine since first thing this morning, and will be *warm* | 08:49.38 |
| kens | So one in three then.... | 08:49.53 |
| chrisl | But I think you're right, and I'm expecting the worst! | 08:50.35 |
| | bbiaw | 09:15.33 |
| kens | OK I'm off for a couple of hours too | 09:25.34 |
| Robin_Watts | Mountain Lion out today. | 09:43.47 |
| tor8 | Robin_Watts: expensive upgrade? | 10:13.37 |
| Robin_Watts | tor8: 10 uid. | 11:08.00 |
| | 20 quid, sorry. | 11:08.05 |
| | As to whether it's an upgrade or downgrade... no idea yet :) | 11:08.18 |
| | too early to be a real mvrhel, right? | 11:27.05 |
| chrisl | kens: could you comment on Bug 693206, please, before I close it? The assignment to me is clearly the result of user ignorance..... but I seem to remember the behaviour changing not that long ago. | 13:18.58 |
| tor8 | Robin_Watts: ping. trivial patch on tor/master. | 13:21.13 |
| kens | chrisl I'll take a look | 13:21.23 |
| chrisl | thanks | 13:21.28 |
| sebras | tor8: lgtm. | 13:24.55 |
| tor8 | sebras: ta. | 13:25.04 |
| sebras | tor8: urw. | 13:26.25 |
| | and no, that's not a reference to the type foundry. | 13:27.06 |
| kens | chrisl commented and closed the bug | 13:47.39 |
| chrisl | thanks | 13:48.53 |
| Robin_Watts | tor8: looking now. | 14:04.52 |
| | Looks sensible to me. | 14:06.46 |
| | curses. chrisl beat me to it :) | 14:52.46 |
| chrisl | Hah! And this time it's a full cluster run, too.... ;-) | 14:53.52 |
| henrys | kens:if you count the number of lines in the -dPDFDEBUG output that would give you are ballpark idea if we are using many more operators than adobe or maybe you checked that. | 15:04.48 |
| kens | henrys what bug is this ? | 15:05.03 |
| henrys | the pdf where adobe is using the cm | 15:06.05 |
| kens | Oh, I think we are using fewer operators than Adobe, but PDFDEBUG won't give us that anyway I don't hink | 15:06.27 |
| | Because this is the contents of the page content stream | 15:06.36 |
| | Also, its vast.... | 15:06.41 |
| | We od moveto/lineto/stroke....repeat | 15:07.35 |
| | Distiller does '[]cm' then moveto/lineto/stroke...repeat | 15:08.00 |
| | Which is why our ourput is actually slightly smaller | 15:08.30 |
| | But I think the Adobe output my compress better | 15:08.39 |
| | may* | 15:08.44 |
| | Well, more accurately, I *know* it compresses better, and I *think* this is what is better compressed | 15:09.19 |
| | Mostly because there is so very much of it in the file | 15:09.29 |
| henrys | oh right our uncompressed result is smaller sorry I fourgot that | 15:09.29 |
| kens | Well our uncompressed result is comparable, page 1 is smaller, apge 2 is bigger | 15:09.45 |
| | Not a lot in it | 15:09.50 |
| henrys | kens:clearly the repetition should lead to better compression. | 15:09.51 |
| kens | henrys I believe this is the case | 15:10.01 |
| | I'm trying to get pdfwrite to emit something like that at the moment | 15:10.16 |
| | Just to see what happens | 15:10.25 |
| chrisl | henrys: As I said earlier, the Adobe output looks almost tailored for compression....... | 15:11.12 |
| kens | I'm inclined to agree, I hinted at that somewhere along the line I think | 15:11.40 |
| | Given that Distiller doesn't *always* produce output like this, its probably a heuristic that got added. At a guess, when Adobe added support for AutoCAD | 15:12.25 |
| chrisl | For example, there are hundreds, maybe thousands of lines that start with the exact pattern: "S 1 0 0 1 0" | 15:12.47 |
| kens | Definitely thousands, maybe tens of thousands | 15:13.06 |
| henrys | I wish we'd see a few more complaints before you spend lots of time on it though... do you think it is really something we should do? | 15:14.24 |
| kens | henrys I'm not at all certain, which is really why I wanted your input, and commented that this is a 'zero time' customer | 15:14.55 |
| | I'm mainly looking at it because I want to satisfy myself about the problem | 15:15.12 |
| Robin_Watts | Actually, in the adobe output the following is repeated many times: "0 cm 0 0 m\n 0 .72 l\nS 1 0 0 1 " | 15:15.26 |
| kens | And because I don't want to do anything significant until after the release | 15:15.26 |
| | Robin_Watts : yes, because the strokes are of constant width. | 15:15.45 |
| | sory length | 15:15.50 |
| | Which is one major reason I think this is a specific heuristic for the bonkers pattern which has been produced (I believe) by AutoCAD | 15:16.17 |
| Robin_Watts | yes. so flate is really going to have an easy time with that. | 15:16.24 |
| henrys | it should not be done for the customer... | 15:16.27 |
| | should be done if we think it is valuable | 15:16.49 |
| kens | That I'm less certain of | 15:16.56 |
| | Its clearly valuable for a specific type of file, almost certainly only for files produced by AutoCAD | 15:17.18 |
| | Altering the Flate parameters I'm more certain of, though the effect (at least on this file) is minimal | 15:17.39 |
| | I'm inclined to switch our Flate from 'default' to 'best' | 15:17.54 |
| henrys | but I don't think these are folks that do a tremendous amount of fretting about file size. | 15:17.59 |
| kens | henrys then why are the customer asking ? | 15:18.12 |
| | s/are/is/ | 15:18.22 |
| henrys | that's the point - if were plural I'd be all in. | 15:18.47 |
| | s/if/if it/ | 15:18.57 |
| chrisl | I was going to say that we do have a few other customers who handle files from CAD applications, but I think they are rendering, not conversion | 15:18.59 |
| Robin_Watts | I bet there are customers for whom "output size being comparable to acrobat" is a factor. | 15:19.00 |
| henrys | Robin_Watts:yes but I'm not sure about AutoCAD folks who are very accustomed to huge files. | 15:20.01 |
| | kens:I'd feel a lot better about if we had a few more requests but if you think there is a need out there have at it. | 15:21.02 |
| kens | henrys its really me scratching an itch at the moment | 15:21.20 |
| | I'm putting a very quick test together to see what happens | 15:21.32 |
| | If it produces very much smaller files, we could think about a proper fix | 15:21.47 |
| | Form the customer email: | 15:22.26 |
| | "Both PDF files come from the same Revit/Autodesk design, but ******* consistently produces a larger PDF. ******* is a bit faster, and uses much less memory. But the architects care about the end file size" | 15:22.26 |
| kens | is finding it too hot to think.... :( | 15:23.28 |
| henrys | it gets hot there? | 15:23.48 |
| kens | Hot by my standards | 15:23.56 |
| Robin_Watts | has a cunning scheme to judge how hot it is. Go for a run with a full water bottle, and then see how much water is left after 7 miles. | 15:24.33 |
| | Today I ran out, so it's hot. | 15:24.45 |
| tor8 | glad I'm not the only one stewing in my own sweat... | 15:25.01 |
| Robin_Watts | I'm not stewing in your sweat :) | 15:25.33 |
| chrisl | Robin_Watts: that sounds less disgusting than my "after a matchm, throw my squash shirt onto the wall: if it stays there, it's hot" ;-) | 15:25.36 |
| kens | Well at least its not just me that thinks its hot | 15:26.44 |
| henrys | we've had a pretty long stretch of 37's - but it is a "dry incindiary" heat ;-) | 15:26.52 |
| | Robin_Watts:we have single digit humidity here, you'd probably need 2 bottles. | 15:28.22 |
| chrisl | I think it may be time to find out if my air-con still works..... | 15:28.33 |
| kens | supposed to be cooler tomorrow | 15:29.02 |
| Robin_Watts | chrisl: You got a portable AC thing too ? | 15:29.25 |
| chrisl | Robin_Watts: For all it's worth, yes. | 15:29.38 |
| Robin_Watts | Mine works well, but it deafens me. | 15:29.52 |
| | Noise cancelling headphones are required too. | 15:30.01 |
| chrisl | Yes, same here - I need it on full to combat the computers! | 15:30.20 |
| | kens: I thought the BBC site said tomorrow should be the same as today, cooler on Friday...... | 15:30.51 |
| kens | :*( | 15:31.03 |
| chrisl | That chap from Debian is not making many friends around here :-( | 15:31.57 |
| henrys | anything agains esp-gs should be closed immediately | 15:33.33 |
| | chrisl:is that what he's been reporting against all along? 693213 refers back to an esp bug. | 15:36.27 |
| chrisl | henrys: Hmm, I didn't really pay attention to that..... | 15:37.22 |
| henrys | well now you can make him go away temporarily - until he upgrades. | 15:38.22 |
| chrisl | henrys: these are mostly patches that Debian have been using *since* 8.15esp, Debian is more up to date | 15:39.19 |
| henrys | ah | 15:40.44 |
| tor8 | Robin_Watts: bug 692930 looks difficult to track down... | 15:47.00 |
| Robin_Watts | tor8: really? | 15:47.34 |
| | It involves XML, so blindness sets in quickly for me. | 15:47.51 |
| tor8 | two nested visualbrushes with a softmask making stuff disappear | 15:50.10 |
| henrys | tor8:I asked at the meeting yesterday don't know if you saw it, are you good with just skipping the meeting and not rescheduling? | 15:50.23 |
| tor8 | possibly bugs in tiling logic | 15:50.27 |
| | henrys: yes, I'm okay with that | 15:51.00 |
| kens | OK I'm off its definitely too hot | 16:37.51 |
| | Goodnight all | 16:37.55 |
| | Oh chrisl 2 files started producing seg faults on your latest code, not that I think your code did it | 16:38.52 |
| | Both are psdcmyk output | 16:39.04 |
| kens | runs away quickly | 16:39.12 |
| Robin_Watts | Aha. | 17:08.35 |
| | ray_laptop: I'm looking into a clist problem at the moment. | 17:08.53 |
| | Somehow, I'm getting the bytes "05" "ff" in the clist, which corresponds to "set_tile_colors" and then "illegal". | 17:09.29 |
| | I cannot where the set_tile_colors byte is being set. | 17:10.02 |
| ray_laptop | Robin_Watts: I presume you've looked at -ZL output ? | 17:10.12 |
| Robin_Watts | ray_laptop: Do you have any clever tricks for debugging the clist. | 17:10.19 |
| | I have. | 17:10.22 |
| ray_laptop | Robin_Watts: what is the sequence right BEFORE the 05 ? | 17:10.36 |
| Robin_Watts | And all -ZL does is show me that there is indeed a set_tile_colors and then the illegal thing. | 17:10.49 |
| | Before the 05 is a create_compositor operation. | 17:11.03 |
| | And I have found and walked through where that is written. | 17:11.36 |
| ray_laptop | mvrhel and I have seen the clist get confused because color spaces are confused and a color gets written with the wrong num_components and either doesn't consume enough ot eats too much data | 17:11.47 |
| Robin_Watts | We then write a sequence of other compositor operations for other bands. | 17:12.05 |
| | so it's (presumably) the next time something gets written for this particular band that something is written badly. | 17:12.28 |
| ray_laptop | I'd be glad to look at it -- is this with HEAD or with a oatched version ? | 17:12.44 |
| Robin_Watts | but I can't see how to trap that nicely under the debugger. | 17:12.50 |
| | It's with head. | 17:12.56 |
| | Let me update the bug with the cutdown file etc. | 17:13.07 |
| | 5 mins. | 17:13.12 |
| ray_laptop | I usually have better luck looking at the reading -- but if you know what is written wrongly it is possible to track it in the writing phase (but tricky) | 17:14.17 |
| Robin_Watts | Right. But the reading looks like it's doing the right thing - there is just garbage in the clist. | 17:15.13 |
| | The question is, what put the garbage there? | 17:15.27 |
| ray_laptop | Robin_Watts: BTW, in going in to fixing the color_usage stuff for POLARITY, I noticed that color types have a method to return a bit mask of components used for a particular color. It was used by overprint | 17:15.50 |
| Robin_Watts | ah. | 17:16.10 |
| ray_laptop | grep for get_nonzero_comps | 17:16.47 |
| | overprint needs this for the PDF OPM (overprint mode) that ignores components that are 0 | 17:18.02 |
| | so I'm going to 'normalize' the color_usage logic to use that, supplementing it a bit (it's broken as well for pure colors in an additive space) | 17:20.41 |
| Robin_Watts | ray_laptop: Sounds reasonable. | 17:21.41 |
| | bug 693220 updated with details of the clist problem. | 17:21.54 |
| | ray_laptop: get_nonzero_comps returns an "int" as the bitmask though. | 17:23.28 |
| ray_laptop | goes to look at that | 17:23.35 |
| Robin_Watts | And an int is not wide enough. | 17:23.36 |
| | You'll need to make it return something like a gx_color_index (or a gx_color_usage, which is defined to be the same thing). | 17:24.11 |
| ray_laptop | Robin_Watts: in gxdcolor.h it is supposed to be gx_color_index *pcomp_bits -- the 'int' return is informational | 17:24.38 |
| Robin_Watts | oh, sorry! | 17:24.53 |
| ray_laptop | np | 17:24.57 |
| Robin_Watts | my bad, you are right of course. | 17:24.59 |
| ray_laptop | Robin_Watts: OK, so the thing that is _supposed_ to follow 05 is a set or delta color so the 'ff' is the problem, right ? | 17:31.24 |
| | 05 _should_ be followed by one of { 0c 0d 10 20 } (I think) | 17:31.58 |
| | or could be 1f or 2f | 17:35.57 |
| | if the color is 'gx_no_color_index' | 17:36.10 |
| | Robin_Watts: I'm building HEAD now to dig into it... but I need coffee. bbiab | 17:37.00 |
| Robin_Watts | Urm... | 17:37.19 |
| | My reading of the code was that 05 was a single byte code that wasn't followed by any data. | 17:37.47 |
| | case cmd_opv_set_tile_color: | 17:38.16 |
| | set_colors = state.tile_colors; | 17:38.18 |
| | if_debug0('L', "\n"); | 17:38.20 |
| | continue; | 17:38.21 |
| | So at first glance it looks like the FF is the problem, yes. | 17:38.36 |
| | BUT... I can't ever see that we've legitimately written an opv_set_tile_color instruction. | 17:39.07 |
| | which makes me think the 05 is garbage too. | 17:39.20 |
| mvrhel | Robin_Watts I am here now | 17:41.25 |
| Robin_Watts | mvrhel: Hi. I've committed 2 fixes to gs today for cmd_write_color etc. | 17:42.02 |
| | cmd_write_color writes a gx_color_index to the clist, right? | 17:42.18 |
| | only we have no idea about how many bytes are actually used within a gx_color_index, so we look at the cdev->color_info.depth to get a worst case scenario and write that many bits. | 17:43.07 |
| mvrhel | cmd_write_color? | 17:43.37 |
| | or cmd_put_color | 17:43.41 |
| Robin_Watts | For deep color, cdec->color_info.depth can be > the number of bits in a gx_color_index and that made stuff confused. | 17:43.47 |
| | cmd_put_color, sorry. | 17:43.51 |
| | goldfish memory at work again. | 17:44.01 |
| mvrhel | I am surprised to see cmd_put_color even being used with the psdcmyk device | 17:44.17 |
| | generally the hl level filling methods should be used | 17:44.30 |
| Robin_Watts | So I simply tweaked the code to write a maximum of 8*sizeof(gx_color_index) bits. | 17:44.48 |
| mvrhel | which would use the methods for putting and getting the devn color | 17:44.50 |
| Robin_Watts | In this case, it's for us doing a copy_mono_plane. | 17:45.03 |
| mvrhel | with a devn color though? | 17:45.15 |
| Robin_Watts | No, it's a pure color. | 17:45.26 |
| | 4e4e4e if memory serves. | 17:45.40 |
| mvrhel | I would really like to see where that pure color came from | 17:45.53 |
| | that is why I was hoping for the file | 17:46.27 |
| | I am a little worried that this is masking some other issue | 17:46.53 |
| Robin_Watts | Where have I put the damn file... | 17:47.10 |
| | cutdown file is 12-07C.PS in my home dir on casper. | 17:47.34 |
| mvrhel | so the same name as the original? | 17:47.48 |
| Robin_Watts | yes. | 17:47.55 |
| mvrhel | ok got it | 17:49.05 |
| ray_laptop | Robin_Watts: OK, back now. | 17:51.49 |
| | I saw your comments and agree that the 05 might be the problem. | 17:52.07 |
| | firing up the debugger now | 17:52.16 |
| mvrhel | oh a type 3 image... | 17:52.22 |
| | and image_render_frac | 17:53.50 |
| | ok this is not the right solution for this | 17:55.30 |
| | we are filling with a separation color | 17:55.44 |
| | and we should certainly not be packing that into a pure color in this case | 17:56.00 |
| | Robin_Watts: so I need to do a bit of work here | 17:56.19 |
| Robin_Watts | ok, have at it :) | 17:56.29 |
| mvrhel | since if it were the 9th colorant we would have some issues | 17:56.54 |
| | does that make sense? | 17:57.12 |
| Robin_Watts | It does. | 17:57.36 |
| ray_laptop | Robin_Watts: I don't get a failure :-( | 17:57.40 |
| Robin_Watts | ray_laptop: What command line? | 17:58.00 |
| ray_laptop | gswin32c -r300 -Z:L -sDEVICE=tiffsep -o x.tif /temp/SALSA3.pdf | 17:58.46 |
| Robin_Watts | tiffsep1 | 17:58.57 |
| ray_laptop | oops tiffsep1 -- my bad | 17:59.18 |
| | trying again | 17:59.22 |
| | OK. got the b.p. this time | 18:00.29 |
| | Robin_Watts: OK, so I traced the two ext_create_compositor commands. The second one looks funny. | 18:21.20 |
| | mvrhel: are you here ? | 18:21.27 |
| | mvrhel: the begin_transparency_group params look funky. The group_color was 6 (UNKNOWN) and the group_color_num_comps is 0 | 18:24.57 |
| | mvrhel: that looks like it just says "use previous group color space" | 18:26.44 |
| | great :-( VS "stopped working" | 18:32.52 |
| | and won't close :-( | 18:33.13 |
| | time to restart :-( | 18:35.15 |
| | now to get back where I was ... | 18:49.35 |
| mvrhel | ray_laptop I am here now | 18:52.19 |
| | that sounds correct | 18:52.39 |
| ray_laptop | mvrhel: I'm trying to track when the begin_trans_group gets written, then see what happens after that. | 18:59.06 |
| mvrhel | gets written in the clist? | 19:02.06 |
| | what bug are you working on? | 19:02.28 |
| | ray_laptop: ^^ | 19:02.40 |
| Robin_Watts | mvrhel: ray_laptop is looking at bug 693220 | 19:03.12 |
| | I've been looking at it all day, and the compositor thing didn't seem to be the problem to me. | 19:03.55 |
| mvrhel | ok. if you guys want me to work on this one let me know as it is likely something that I did. I will see about fixing this issue with pure color | 19:05.06 |
| | hmm image_render_frac is treating the separation space as a gray space | 19:10.53 |
| ray_laptop | sorry -- I'm tracking a clist error | 19:10.57 |
| mvrhel | and ends up mapping it to RGB | 19:11.46 |
| | this is a bit wrong.... | 19:11.54 |
| | I don't understand how this could have worked properly | 19:12.33 |
| | ever | 19:12.35 |
| | when going out to a separation device | 19:12.58 |
| | ugh this has to worry about transparent color too | 19:19.54 |
| | ok. now we are properly creating the devn color types here | 19:33.47 |
| | sep space was getting treated as gray and mapped to rgb | 19:34.04 |
| | Robin_Watts: Now we are not encountering cmd_put_color | 19:34.56 |
| | with devn colors | 19:35.00 |
| | and the file ran fine | 19:35.10 |
| ray_laptop | mvrhel: you aren't working on the same bug as I am, right ? | 19:35.59 |
| mvrhel | I don't know. Am I? | 19:36.14 |
| ray_laptop | this bug only happens with tiffsep1 | 19:36.33 |
| mvrhel | I am working on one assigned to me | 19:36.34 |
| ray_laptop | OK. this one is still assigned to support | 19:36.47 |
| | I guess I should assign it to myself | 19:36.59 |
| mvrhel | I am working on 693144 | 19:37.09 |
| | Robin_Watts: had chopped down the file quite a bit | 19:37.23 |
| | but the issue that he was seeing smelled of something going wrong earlier in the process | 19:38.12 |
| | bbiab | 19:38.24 |
| Robin_Watts | mvrhel: I don't think I can have chopped the file "too much" :) | 19:45.09 |
| | There is lots of PS crap still in there, but hopefully few drawing operations. | 19:45.26 |
| mvrhel | Robin_Watts: no I mean you did a good job | 19:53.15 |
| | it was easy to catch the issue with your file | 19:53.28 |
| | have to run out for a sec. I will see how my fix behaves on the whole original file when I get back | 19:53.54 |
| ray_laptop | OK, when it is writing the data for the band (band 4) the begin_trans_group is followed by a 'set_color0' (op 0x10 + 7) -- next I need to look at when that is written to the collected block of band 4 commands... | 19:59.17 |
| Robin_Watts | mvrhel: This file is one of the ones that gives differences when I bump the max components. I'm hoping that your fix will knock a lot of the problems on the head. | 20:05.14 |
| ray_laptop | ooh. this doesn't look good. cmd_put_color is writing with num_bytes == -3 | 20:22.06 |
| | mvrhel: are you there. I have a smoking gun I'd like to describe to see what else I should look at... | 20:27.32 |
| | the color_info has max_components == 8, num_components == 4, but the color it is trying to write is 0xff00000000000000 | 20:29.46 |
| | it sure takes a while before it steps into the mud | 20:34.35 |
| | oh. tiffsep1 is still using compressed color encoding :-( | 20:51.14 |
| | this is strange. The target device (tiffsep1) does NOT use compressed encoding, but the pdf14 device _does_ | 20:57.02 |
| sebras | Robin_Watts: Christian Birch, who is that? he's reported a lot of bugs, so I guess he's an app dev for some thing..? | 20:59.35 |
| | I vaguely remember the name, but I can't pinpoint from where. | 21:00.03 |
| Robin_Watts | sebras: Likewise. | 21:02.15 |
| sebras | Robin_Watts: btw, I've been contemplating reviewing the code looking for instances where we don't handle parsed ints that are negative very well (like you did for stream Length's). | 21:03.27 |
| Robin_Watts | mvrhel_laptop: Ping | 23:15.31 |
| mvrhel_laptop | hi Robin_Watts | 23:15.45 |
| Robin_Watts | If you don't get a chance to test your fix today, can you mail it to me please? | 23:15.58 |
| | Then I can test it tomorrow. | 23:16.04 |
| mvrhel_laptop | yes. definitely. | 23:16.07 |
| | I will be working on it tonight some | 23:16.14 |
| Robin_Watts | I'm hoping that it will solve the max components = 32 problems. | 23:16.28 |
| mvrhel_laptop | that would be nice | 23:16.33 |
| Robin_Watts | indeed :) | 23:16.47 |
| | At the moment, the bmpcmp's are showing that the current code is drawing yellow bits where we are supposed to be having grey's :) | 23:17.18 |
| mvrhel_laptop | Robin_Watts: question for you | 23:21.33 |
| | can you look at my regression results from my last push | 23:21.44 |
| | that was from just making the change in the remap struct to 32 | 23:22.06 |
| | I am wondering about Bug688845.eps.pgmraw | 23:22.26 |
| | and 09-52.PS.plank | 23:22.32 |
| | do these occur now and then | 23:22.55 |
| | seems to be fine to me | 23:35.11 |
| | pushed and now moving back to 12-07C.PS | 23:37.34 |
| sebras | Robin_Watts tor8: sebras/master has a few negativity patches. | 23:40.13 |
| Robin_Watts | back. | 23:40.19 |
| mvrhel_laptop | does 12-07C.PS need any special jobserver settings to run all the pages? | 23:41.25 |
| Robin_Watts | mvrhel_laptop: I was clearly too late to see Bug688845.eps | 23:41.26 |
| | mvrhel_laptop: Not that I know of. | 23:41.35 |
| mvrhel_laptop | hehe | 23:41.36 |
| | ok | 23:41.38 |
| | with my changes it runs just fine | 23:41.46 |
| Robin_Watts | Fab. | 23:41.50 |
| mvrhel_laptop | I will push this and see what explodes | 23:42.09 |
| Robin_Watts | So you opted for '32' rather than 'MAX_COMPONENTS_IN_DEVN' or something. | 23:43.26 |
| mvrhel_laptop | well I suppose I should have put in a def | 23:43.44 |
| | I will fix that tonight | 23:43.54 |
| Robin_Watts | Magic numbers are bad (and I'm massively guilty of it :( ) | 23:44.03 |
| mvrhel_laptop | yes | 23:44.06 |
| | I agree | 23:44.10 |
| | thanks for shaming me :) | 23:44.17 |
| Robin_Watts | :) | 23:44.20 |
| | This is all looking much more solid though. | 23:44.31 |
| mvrhel_laptop | have to run right now. last baseball game of the season | 23:44.38 |
| Robin_Watts | have fun. I'm off to bed. Night. | 23:44.45 |
| mvrhel_laptop | want to push this thing though | 23:44.47 |
| | have a good night | 23:44.50 |
| | ok pushed. I will see what the aftermath is later | 23:50.12 |
| | Forward 1 day (to 2012/07/26)>>> | |
IRC Logs