| | <<<Back 1 day (to 2013/11/14) | 2013/11/15 |
| Robin_Watts | ray_laptop, mvrhel_laptop, henrys: I've written the proposed mail. Any comments or suggestions, please speak up. | 00:12.49 |
| ray_laptop | Robin_Watts: I haven't seen it yet. | 00:14.17 |
| | Robin_Watts: Do you want to review the color_usage improvements changes, or should I just commit them ? | 00:14.46 |
| henrys | Robin_Watts: reading now | 00:15.48 |
| ray_laptop | I checked and tiger is getting the right values in that I get "all colors" for the area of the face (caused by the orange) and 8 (K only) above and below it | 00:15.53 |
| | and colorcir.ps also gives reasonable results | 00:16.07 |
| Robin_Watts | ray_laptop: I'm off to bed in mo. commit away! | 00:17.42 |
| ray_laptop | Robin_Watts: BTW, on you timings, can you mention what settings you used (-dBGPrint=? -dNumRenderingThreads=?) | 00:18.29 |
| | Robin_Watts: other than that, it looks fine to send, | 00:19.11 |
| | Robin_Watts: OK, I pushed it. As I said, colorcir.ps is more interesting in that it gives some bands with 0 other bit patterns such as 3, 5, 6, and 7 | 00:20.56 |
| Robin_Watts | ray_laptop: sure. Do we want to run it by Takane-san ? | 00:21.31 |
| ray_laptop | I don't know how much he's been in the loop with the customer, in order to be able to judge. As far as I'm concerned, this is primarily a technical + support issue. I'll leave that up to henrys | 00:23.38 |
| Robin_Watts | castAR just hit $1M funding with 3 hours to go. Woo Hoo! | 00:24.30 |
| ray_laptop | Robin_Watts: is your device on you repos on casper ? | 00:25.05 |
| Robin_Watts | ray_laptop: No. | 00:25.27 |
| ray_laptop | Robin_Watts: any reason why not ? | 00:25.53 |
| Robin_Watts | I deliberately haven't checked it anywhere remotely yet until we have spoken to the customer. | 00:25.54 |
| ray_laptop | Robin_Watts: oh, OK. | 00:26.03 |
| Robin_Watts | That's why the patch is on casper. | 00:26.08 |
| ray_laptop | have to added the band skipping ? | 00:26.38 |
| Robin_Watts | I think we send the mail, wait a day, then check it in. | 00:26.40 |
| | In my local version yes. | 00:26.51 |
| ray_laptop | can you push that to casper ? | 00:27.05 |
| henrys | Robin_Watts: I've tried involving takane-san in issues of this complexity and his english just isn't good enough. | 00:27.24 |
| Robin_Watts | just checking to see if that's there yet. | 00:27.24 |
| | ray_laptop: It's there already. | 00:27.36 |
| | henrys: yeah, I suspect it would require a lot of explaining from us to make him understand the issue we are concerned about. | 00:28.10 |
| | In that case, are we happy with the mail now? Cos if I send it now, they'll get it before the weekend, and we can check stuff in on monday. | 00:28.39 |
| ray_laptop | I was thinking about adding a check for the supposedly empty planes that will paint a constant value or pattern if a plane isn't empty. If that's something customers end up relying on, I want to make sure that it's correct | 00:29.34 |
| Robin_Watts | ray_laptop: Add that where? | 00:30.21 |
| ray_laptop | we'd want the regression to establish a baseline without that, then enable that checking so that it'll spot errors going forward | 00:30.34 |
| | Robin_Watts: in the process_fn, I would assume | 00:30.48 |
| henrys | the Artifex accountant won't take scanned receipts? Seriously? Has anyone else tripped over this? | 00:30.49 |
| Robin_Watts | ray_laptop: I'd prefer to avoid complicating the device. | 00:31.27 |
| | I want to make the device simpler, not more complex :) | 00:31.43 |
| ray_laptop | Robin_Watts: that's not adding much complexity. I thought the goal of the device was to make sure our code is working correctly | 00:32.38 |
| Robin_Watts | ray_laptop: I guess. | 00:33.03 |
| ray_laptop | I'll look at doing it, and you can have final say on accepting it | 00:33.41 |
| henrys | bbiab | 00:36.12 |
| Robin_Watts | henrys: Are you happy with the email? | 00:39.15 |
| | I'm off to bed, so the email will have to wait - unless you or henrys feel like forwarding it later. | 00:59.48 |
| | ray_laptop: For the record, the timings were with the same settings I sent them before (NRT=4, no bg print). | 01:00.13 |
| henrys | Robin_Watts: I am fine with the email I thought we were waiting until tomorrow so others could have a look | 01:05.37 |
| ray_laptop | Robin_Watts: I'm curious to see how much faster (on your machine) J12 will be with -dBGPrint=true | 01:09.33 |
| | but it is not at all urgent | 01:09.58 |
| | in getting pulled off for cust 532, I had set aside getting the xxxx code to build on linux. I now have it building, so I will assemble a new tarball for the customer and put instructions in an email | 01:29.46 |
| | I still have one thing to look at, however. It doesn't run on linux | 01:30.25 |
| | I get /VMerror in --showpage-- | 01:30.53 |
| mvrhel_laptop | henrys: you just reminded me that I need to do my expense report | 01:41.25 |
| | henrys: are you around? | 02:58.40 |
| henrys | yes I am | 02:58.49 |
| mvrhel_laptop | so I was trying to generate a pxf file from acrobat. I don't see that type as an option to export from the security settings | 03:00.16 |
| | how did you generate the one on the tablet? | 03:00.25 |
| | I see *.fdf and *.cer | 03:00.54 |
| | and *.p7c | 03:01.05 |
| | henrys^^ | 03:01.14 |
| | google was not much help | 03:01.28 |
| | so I thought I would ask you next | 03:01.42 |
| henrys | ha I think paulgardiner did it. | 03:02.01 |
| mvrhel_laptop | ok. well if you give me your password then I will just use yours... | 03:02.23 |
| henrys | try 6bullfrogs | 03:02.38 |
| mvrhel_laptop | nope :( | 03:03.37 |
| henrys | hmm 5baltam | 03:03.51 |
| mvrhel_laptop | nope :( | 03:04.34 |
| | Maybe I will email paul and have him make me one... | 03:05.00 |
| henrys | dang it. I think I have some email about it. | 03:05.15 |
| | yeah can't find anything | 03:07.02 |
| mvrhel_laptop | henrys: ok. I will email paul. no worries | 03:07.15 |
| henrys | mvrhel_laptop: I remember using it and it worked | 03:07.26 |
| mvrhel_laptop | Oh yes. I see your signature on the one docs | 03:07.42 |
| | and I was seeing if I could apply it to another but it asks for the password | 03:08.02 |
| henrys | mvrhel_laptop: do you feel prepared otherwise? | 03:10.26 |
| mvrhel_laptop | I think so. The only other thing I would like to have is customer 801's device as Robin and Ray have it now | 03:10.52 |
| | henrys: ray_laptop was going to supply a patch for a branch. I am hoping for that tomorrow | 03:11.17 |
| | If they are still having issues building it would be nice to be prepared to help with that | 03:11.37 |
| | I loaded the latest version of mupdf on the tablet and we have all the numbers that we ran last august for that trip. those proved to be useful and of interest in every visit | 03:13.22 |
| henrys_ | mvrhel_laptop: well have fun too! | 03:17.56 |
| mvrhel_laptop | henrys_ : yes. I do enjoy going. Just hoping that we get some customers out of this. Last visit was very encouraging. | 03:20.49 |
| henrys | be back a little later going to eat. | 03:21.58 |
| ray_laptop | mvrhel_laptop: I just emailed the patches for cust 801 (my xxxx branch on the git HEAD) | 06:16.47 |
| | mvrhel_laptop: let me know if you have any troubles building it. I built and tested it on Windows (with VS2008) and linux (peeves.ghostscript.com:/home/ray/git/ghostpdl/gs) | 06:18.02 |
| | mvrhel_laptop: note the need to make a dummy directory in the cwd in order to run it. It will create a 9999 directory in that directory, but nothing else. It is also set for timing by a #define NO_OUTPUT in their device | 06:20.41 |
| | mvrhel_laptop: when do you leave ? | 06:21.26 |
| mvrhel_laptop | ray_laptop: Saturday morning | 06:22.58 |
| | Tomorrow evening is taken up with kids music recitals so I have to get everything wrapped up in the day tomorrow | 06:23.30 |
| | Trying to get my expense report done now. | 06:23.49 |
| | I really need to be better about these | 06:23.59 |
| ray_laptop | mvrhel_laptop: OK. It should be pretty quick to make a branch and apply the patches with git am | 06:24.12 |
| mvrhel_laptop | so does your patch create the branch or do I need to make the branch and then apply the patch | 06:24.38 |
| | ray_laptop ^^ | 06:25.30 |
| ray_laptop | I think you need to make a branch then apply the patch (I did the format-patch when I was on the branch and did git format-patch master) | 06:25.48 |
| mvrhel_laptop | so the branch can be what ever I want to name it | 06:26.13 |
| ray_laptop | and I don't see the branch name in the patch | 06:26.19 |
| mvrhel_laptop | I see | 06:26.19 |
| ray_laptop | just don't do it to your master ;-) | 06:26.49 |
| mvrhel_laptop | ray_laptop: I dont see the email | 06:27.35 |
| | did you cc support? | 06:27.47 |
| ray_laptop | mvrhel_laptop: I sent it at 10:15 | 06:27.55 |
| | 12 minutes ago | 06:28.02 |
| mvrhel_laptop | I would have thought I would have it by now | 06:28.23 |
| ray_laptop | to you, Robin and tech | 06:28.33 |
| | mvrhel_laptop: I'll put the zip file with the 3 patches on casper:~ray/public Just a sec | 06:29.06 |
| mvrhel_laptop | oh I found it | 06:29.10 |
| | it went in my general gs mailbox folder for some reason | 06:29.27 |
| | weird | 06:29.37 |
| ray_laptop | OK, well its on casper as well | 06:29.38 |
| mvrhel_laptop | ray_laptop: just so I understand, I need to apply all three of these yes? | 06:32.00 |
| ray_laptop | mvrhel_laptop: yes | 06:32.08 |
| | I guess I could have squashed them | 06:33.28 |
| mvrhel_laptop | yeah. but it was fine. they applied cleanly for me | 06:34.01 |
| ray_laptop | mvrhel_laptop: great. Make sure and build clean. And if you make changes, the dependencies are pretty much non-existent for their device. I just added $(arch_h) so that the linux build would work | 06:35.33 |
| mvrhel_laptop | ok | 06:35.57 |
| | cleaning and building now | 06:36.36 |
| | the build failed :( | 06:38.35 |
| ray_laptop | strange. Do you want to post the error on a private chat ? | 06:39.09 |
| mvrhel_laptop | I suspect my clean did not clean | 06:40.06 |
| | error C2039: 'pad' : is not a member of 'gx_device_s' was what I got | 06:40.12 |
| ray_laptop | mvrhel_laptop: was your master up to date before you did the git branch | 06:40.32 |
| mvrhel_laptop | doh | 06:40.44 |
| ray_laptop | many of the "improvements" that were developed by Robin or I on their code have been pushed to HEAD, and when I generate the patchces, it expects that stuff is already in the master | 06:42.04 |
| mvrhel_laptop | I understand | 06:42.16 |
| ray_laptop | my master was b83ce7d | 06:42.23 |
| mvrhel_laptop | darn | 06:43.11 |
| ray_laptop | mvrhel_laptop: if your branch is set to rebase off of your master, you can checkout master, update that, then checkout your branch and update that (from master) | 06:44.19 |
| mvrhel_laptop | yes | 06:44.32 |
| | ok. got it taken care of | 06:45.12 |
| ray_laptop | it builds now ? | 06:45.22 |
| mvrhel_laptop | no I got the git stuff straight | 06:45.31 |
| | now I will clean and build again | 06:45.37 |
| | building now..... | 06:46.13 |
| | ray_laptop: it built | 06:49.44 |
| | calling it a night now | 06:52.21 |
| | will run it tomorrow and finish expense report and pack | 06:52.36 |
| ray_laptop | mvrhel_laptop: Great. If I'm not online and you want to chat about it, please call | 06:54.15 |
| | mvrhel_laptop: g'nite. I'll be going to bed soon as well | 06:54.38 |
| | Don't expect anything from the office on your expense reports, BTW. Mine typically languish for 2+ weeks until I call Joann and ask about them, then she "mentions" them to Miles. | 06:55.52 |
| | But usually they just sit in Sheila's inbox until then because Miles doesn't take them home | 06:56.28 |
| Robin_Watts | chrisl, kens, tor7: Do any of you have opinions on the mail to 801? | 13:31.26 |
| kens | I htought you had sent it, it looked fine to me | 13:31.39 |
| chrisl | Robin_Watts: I only briefly scanned through it - I think the only thing I might have put differently was to use "central repository" rather than "public repository", but that's a tiny thing | 13:35.39 |
| Robin_Watts | "central public repository" maybe. | 13:41.00 |
| | For us, it's clear that our central repo is public. For other people, maybe not so obvious. | 13:41.21 |
| chrisl | My concern with "public" is my mind jumps to "public domain"..... | 13:43.20 |
| tor7 | Robin_Watts: main public repository? I expect your intent in wording it 'public' implies to them that we're going to open source the device. | 13:43.23 |
| | chrisl: public sounds like anyone has write access to it, so there is that | 13:44.00 |
| henrys | I'm with chrisl don't say public at all. | 13:44.31 |
| Robin_Watts | tor7: public is intended to see that anyone can at least see the device. | 13:44.38 |
| | s/see/imply/ | 13:44.46 |
| | henrys: I think it's important to say public. The point of the mail is to let them know that we are making the example device public, but to do so in a way that makes it seem like it's an advantage to them. | 13:46.24 |
| chrisl | "Our plan is to add this device to the central repository for Ghostscript (and thus have it included future Ghostscript release archives)"? | 13:47.09 |
| Robin_Watts | chrisl: that would work. | 13:47.23 |
| henrys | Robin_Watts: it's implicit and if it it's missing it won't get them thinking about it. | 13:47.41 |
| tor7 | s/central repository/open source repository/ and chrisl's wording for the rest? | 13:47.45 |
| chrisl | My concern is the corporate-type's reaction to words like "public", "open", "free"...... | 13:48.24 |
| Robin_Watts | Our plan is to add this device to the central repository for Ghostscript (and thus have it included in future releases), from where we can add it to our standard tests. | 13:49.28 |
| | How do people feel about that? | 13:49.52 |
| kens | I'm comfortable with any of these | 13:50.08 |
| henrys | Robin_Watts: I'm good | 13:50.31 |
| chrisl | Robin_Watts: That looks good to me. I can't think of a better way to say "public" or "open" without using those "red light" words :-( | 13:50.56 |
| Robin_Watts | paulgardiner told me he was happy with the mail this morning, so I think everyone has weighed in now. | 13:51.01 |
| | So I shall send it. | 13:51.14 |
| chrisl | Robin_Watts: is it worth asking Miles? | 13:51.19 |
| Robin_Watts | chrisl: That's up to henrys. I'll wait for Miles to be consulted if henry wants. | 13:51.42 |
| chrisl | Or will that just complicate matters.....? | 13:51.49 |
| henrys | no we're good to got | 13:52.13 |
| | s/got/go | 13:52.17 |
| Robin_Watts | fab. | 13:52.20 |
| | chrisl: Am I right in thinking that for snapshots we should "./autogen.sh" rather than "configure" ? | 13:59.12 |
| chrisl | Robin_Watts: yes, that's right. We don't commit a configure script | 13:59.34 |
| | Robin_Watts: but remember they will probably want the commercial release....... | 14:00.26 |
| Robin_Watts | Right, but at the moment, they are working from a snapshot. | 14:00.39 |
| chrisl | Robin_Watts: okay, so the additional dependency they'll have is that they'll need "autoconf" | 14:01.10 |
| henrys | chrisl: Imagine going the anticipation of working on your Phd knowing your last name is Doolittle | 14:28.06 |
| | s/going// | 14:29.48 |
| | I have a dentist appointment in 25 minutes. | 14:35.33 |
| kens | Just a chekup I hope | 14:35.56 |
| henrys | kens:a couple fillings | 14:36.23 |
| kens | :( | 14:36.28 |
| henrys | nothing major | 14:36.39 |
| chrisl | henrys: not as much as "Strangelove" or "Who"...... good luck at the dentist's | 14:38.01 |
| Robin_Watts | henrys: I was at college with a bloke called Richard D'eath. | 15:12.27 |
| | He's now Dr Dick Death. | 15:12.32 |
| chrisl | Robin_Watts: Did he know Tom Sharpe.....? | 15:16.40 |
| Robin_Watts | chrisl: Ok, the same gc question to you that I asked ray yesterday... | 15:27.18 |
| | In gdevdevn.c there is a definition for spotcmyk_device | 15:27.38 |
| | Immediately followed by the gc procs for it. | 15:28.03 |
| | It looks to me like those gc procs only work on the devn_params bit of the structure. | 15:28.38 |
| | shouldn't they also be coping with the earlier bits of the structure? | 15:28.52 |
| chrisl | I think the ENUM_PREFIX() and RELOC_PREFIX() take care of the common "printer device parts" | 15:29.31 |
| Robin_Watts | Gah! | 15:30.58 |
| | I can't see for looking. | 15:31.06 |
| | Of course, that makes perfect sense, thanks! | 15:31.13 |
| chrisl | Yes, the _PREFIX macros pull the enum and reloc functions from the st_device_printer | 15:31.31 |
| | NP | 15:31.35 |
| chrisl | questions Robin_Watts' use of "makes perfect sense" when referring to any part of the garbage collector | 15:32.33 |
| Robin_Watts | I *hate* the way gs .h files don't include all their prerequestites. | 15:42.58 |
| | I mean, who thought that was a good idea? | 15:43.03 |
| chrisl | I hate even more that *some* of the do, whilst most don't - who thought *that* was a good idea? | 15:43.41 |
| ray_laptop | I have no objection to either of you cleaning that up (and fixing the dependencies in the process) | 15:46.03 |
| chrisl | ray_laptop: I'll add that to my "someday" projects....... | 15:47.25 |
| ray_laptop | header files that include other headers sometimes don't have those identified as dependencies (how often I don't know, but I've been bitten by that on incremental builds) | 15:47.45 |
| chrisl | I guess that may be (part of) the thinking behind having to explicitly include the headers individually | 15:48.46 |
| ray_laptop | I think that the business of the headers goes back to 1987 when compiler were limited by the size of the pre-processor result. | 15:50.04 |
| | and compile times were *much* slower. | 15:50.32 |
| | that and LPD could keep all of the nested requirements in his head, so he never was inconvenienced :-) | 15:51.34 |
| | Robin_Watts: looks like Nomura-san found all the same things with the linux build that I had. Were you ever able to run their original code ? | 15:54.36 |
| Robin_Watts | ray_laptop: I never tried on linux. | 15:54.52 |
| | I replied to his email this morning. | 15:55.07 |
| ray_laptop | Robin_Watts: but you compared output on Windows ? | 15:55.20 |
| | Robin_Watts: yes, I saw your replies | 15:55.29 |
| Robin_Watts | ray_laptop: I compared output visually and (I think) by diffing the pgms. | 15:55.45 |
| | but when I saw the bug in their code I stopped looking for diffs (as setting the bandheight to 128 didn't occur to me as a solution til you pointed it out) | 15:56.34 |
| ray_laptop | Robin_Watts: the patches I sent allow you to build on linux | 16:01.31 |
| | I have to take my youngest to school now. bbiaw | 16:02.00 |
| Robin_Watts | chrisl: Another silly question. In gsgcache.c, line 50, why is that a public, not a private? | 16:25.29 |
| chrisl | I think it's because these can be called explicitly from the PS interpreter code, rather than the usual "implicit" call through the GC stuff - but I'm not totally sure | 16:26.54 |
| Robin_Watts | The sole difference between private and public is whether they are static or not. | 16:28.14 |
| | Changing it to private still works after a build. | 16:28.27 |
| | This is utterly unimportant through, just something I noticed. I was trying to find how to declare one publicly. | 16:29.05 |
| chrisl | Robin_Watts: it may well be that it's been changed or deprecated - there is a comment to the effect that the "public" versions are a hack | 16:29.16 |
| Robin_Watts | oh, really? | 16:29.28 |
| chrisl | I can't find it right now | 16:31.05 |
| ray_laptop | back now. | 16:41.34 |
| | Robin_Watts: do you want me to try and get their original code to build on linux and compare output ? | 16:42.22 |
| Robin_Watts | ray_laptop: If you want. | 16:42.51 |
| | They have 3 different output formats from their original device. | 16:43.00 |
| ray_laptop | Robin_Watts: and which of us should put together a "latest and greatest" snapshot for them ? | 16:43.02 |
| Robin_Watts | the PGM stuff, a wacky raw format of their own, and a wacky raw format of their own with added packbits fun. | 16:43.34 |
| | I have only tested the PGM stuff. | 16:43.48 |
| | so I was planning to wait to hear back from them about what they are actually wanting. | 16:44.08 |
| ray_laptop | Robin_Watts: if one of us posts the snapshot, then you could mention that in your email | 16:44.09 |
| Robin_Watts | ray_laptop: Email has been sent. | 16:44.24 |
| | Did you not get a copy? | 16:44.38 |
| ray_laptop | Robin_Watts: OK. I had seen discussion here in the logs. | 16:44.45 |
| Robin_Watts | yeah, we discussed it and agreed it, so I sent it. | 16:45.01 |
| | ray_laptop: I haven't pulled in your changes locally yet. | 16:45.25 |
| | so if you have a new snapshot worth sending them, feel free. | 16:45.40 |
| | I'd really rather they moved to a git based workflow though. | 16:45.53 |
| | It'd be MUCH easier for them to pull changes from git and merge or rebase their branch. | 16:46.10 |
| ray_laptop | Robin_Watts: Oh, I did get that. It preceded the reply to Nomura-san | 16:46.12 |
| Robin_Watts | yeah. | 16:46.20 |
| | I'm trying to extract as much of the generic devn boilerplate into reusable code as I can at the moment. | 16:47.01 |
| | It'll let me shrink psdcmykog a bit. | 16:47.12 |
| ray_laptop | Robin_Watts: I agree that it would be better to have them use git | 16:47.13 |
| Robin_Watts | and potentially 801s device too. | 16:47.20 |
| ray_laptop | Robin_Watts: that sounds like a good plan (refactoring the code) | 16:47.39 |
| | Robin_Watts: maybe it'll make it easier to finally get totally rid of compressed_colors | 16:48.47 |
| Robin_Watts | I guess the reason it hasn't gone already is because we worry that someone might have a device that uses it? | 16:49.32 |
| ray_laptop | Robin_Watts: I doubt any free user has done a device based on it, and any customer will (IMHO) be better off with the planar mode -- we can spend the time supporting any customer. However, I don't think there are any customer devices unless they are totally "stealth" | 16:51.11 |
| Robin_Watts | ray_laptop: Then we should rip the bandaid off now, and we can staunch any customer bleeding after the next release. | 16:51.47 |
| | Urm... | 16:53.15 |
| | How can spotcmyk_device not have a ret_devicen_params function? | 16:53.33 |
| ray_laptop | Robin_Watts: that's one for mvrhel_laptop I think | 16:54.01 |
| Robin_Watts | likewise the devicen device. | 16:54.01 |
| | ray_laptop: Did you put in the stuff to make the psdcmykog device check for genuinely skipped planes? | 17:11.25 |
| | If not, I will do that now. | 17:11.53 |
| ray_laptop | Robin_Watts: I have that in, untested. I can send you a patch | 17:17.55 |
| Robin_Watts | ray_laptop: Ok, ta. | 17:18.07 |
| kens2 | goodnight all | 17:18.28 |
| ray_laptop | Robin_Watts: patch is now on casper:/home/ray/public/0001-Add-checking-for-non-empty-planes-when-the-color_usa.patch Do you prefer me to email it ? | 17:20.59 |
| | Robin_Watts: I was going to go ahead and test it | 17:21.30 |
| | Robin_Watts: and I have no problem with "squashing" it into your commit -- it doesn't need to be separate. It's just easier to work on it together that way | 17:22.36 |
| Robin_Watts | ray_laptop: I can grab it from there, ta. | 17:24.27 |
| ray_laptop | Robin_Watts: As you can see, it doesn't add much complexity, although it does add some performance hit for the empty plane case compared to your original. But if the goal is a regression testing device, performance isn't super critical | 17:25.13 |
| | Robin_Watts: and recall that we _do_ want a regression run initially that "trusts" the color_usage bits so that when we turn on 'verification' we will get a raster difference for failures | 17:26.38 |
| Robin_Watts | ray_laptop: Sure. | 17:27.07 |
| ray_laptop | hmm... I just realized something. Clist colors that are in the clist as "high level" colors that go through a subsequent source_color->device_color ICC profile will fail if the device ICC profile results in different planes being written. I think | 17:29.51 |
| ray_laptop | needs to go re-read mvrhel_laptop's 9.00 color doc | 17:31.01 |
| mvrhel_laptop | I don't believe there is anything about the clist in that document | 17:31.37 |
| | ray_laptop: what is your question? | 17:31.57 |
| Robin_Watts | mvrhel_laptop breaks cover. Swoop! | 17:31.58 |
| mvrhel_laptop | ha. I am trying to do expense report and pack today | 17:32.15 |
| | I have been here the whole time... | 17:32.21 |
| ray_laptop | mvrhel_laptop: Robin first | 17:32.24 |
| | (it's later by his clock) | 17:32.39 |
| Robin_Watts | OK, quick question. How come the spotcmyk_device and devicen_device don't include a get_devn_params function? | 17:32.56 |
| mvrhel_laptop | getting snarled in deviceN color code that I didnt write sounds like something that might be a time sink | 17:33.06 |
| Robin_Watts | "I don't know" is a perfectly acceptable answer :) | 17:33.29 |
| mvrhel_laptop | Robin_Watts: I don't know the answer to that. I actually have never used those devices | 17:33.29 |
| Robin_Watts | fair enough. I will keep working then. over to ray. | 17:33.49 |
| | thanks. | 17:33.55 |
| mvrhel_laptop | Robin_Watts: it is very likely that you will find a way to clean up all of that mess. | 17:34.21 |
| | I had to fix a bunch of stuff in the deviceN color when I did the planar change for psdcmyk and tiffsep | 17:34.46 |
| | and it was messy | 17:34.50 |
| ray_laptop | mvrhel_laptop: OK, my question. When will the source->device color mapping occur post-clist ? Will it ever happen with DeviceCMYK, DeviceRGB, DeviceGray painting other than images ? | 17:34.53 |
| mvrhel_laptop | it will happen only for images and for transparency groups | 17:35.21 |
| ray_laptop | mvrhel_laptop: and if you aren't sure, that's fine. I'll re-read your doc and study the code more | 17:35.43 |
| mvrhel_laptop | ray_laptop: there are only 2 places where the icc profiles are added to the clist and that is in the image code and in the transparency code | 17:36.24 |
| ray_laptop | mvrhel_laptop: images are OK in that the only time I ever try and track color_usage is when I have a single component (DeviceGray or indexed) | 17:36.38 |
| mvrhel_laptop | all the other cases we go to device color during clist writing | 17:36.43 |
| ray_laptop | mvrhel_laptop: whew! I'll double check transparency case, then | 17:37.05 |
| Robin_Watts | mvrhel_laptop: Would it be bad of me to add the spot equivalent color handling to the spotcmyk and devicen devices? | 17:37.27 |
| ray_laptop | still I'll feel better when the regression run checks it for me :-) | 17:37.48 |
| mvrhel_laptop | Robin_Watts: it would not be bad, however, it is not necc. needed by every device. for example, the customers device does not need to even fool with it. it could use the default proc | 17:38.14 |
| | which returns 0 and does nothing | 17:38.23 |
| | i think | 17:38.26 |
| Robin_Watts | mvrhel_laptop: At the moment, I've just renamed some of the spotcmyk device functions etc and made them global instead of static. | 17:39.00 |
| | and put them in a new header file. | 17:39.04 |
| | This means the psdcmykog device can just call out to them and not worry about lots of boilerplate. | 17:39.27 |
| mvrhel_laptop | Robin_Watts: I understand | 17:39.39 |
| Robin_Watts | If I push the equiv colors stuff back in there too, then the psdcmyk and psdrgb devices can build on the same code. | 17:40.03 |
| | As far as I can tell, it will never *hurt* to have the equiv colors in there, right? | 17:40.29 |
| mvrhel_laptop | no. | 17:40.48 |
| | it would be good to go ahead and add it to the base device you are creating | 17:41.27 |
| Robin_Watts | And it should open up the way for me to make the psdcmyk/psdrgb/psdcmykog devices share the psd writing code. | 17:41.43 |
| mvrhel_laptop | nice | 17:41.50 |
| Robin_Watts | Ok. Do your accountancy/packing quickly, cos there may be more dumb questions incoming :) | 17:42.19 |
| mvrhel_laptop | :) | 17:42.25 |
| | I am so bad at keeping track of receipts | 17:42.45 |
| | especially over a period of 6 months... | 17:42.58 |
| Robin_Watts | Me too. I have to do my accounts once a quarter or the tax man fines me, so that motivates me. | 17:43.18 |
| mvrhel_laptop | I think I have everything now. so I can start to assemble and print the hard copies | 17:43.36 |
| ray_laptop | Robin_Watts: there are (AFAICT) two devices that are 'spotcmyk' devices. gdevxcf.c (Gimp DeviceN) and rinkj (which it may be time to deprecate, BTW). The rinkj device can only support CMYKcmk -- no real spot colors | 17:44.39 |
| Robin_Watts | The xcf one is not a devicen device. | 17:45.26 |
| | nor is the rinkj one. | 17:45.47 |
| | psdcmyk, psdrgb, psdcmykog and tiffsep are the only devicen printer devices I can see. | 17:48.17 |
| ray_laptop | Robin_Watts: the xcf supports SeparationColorNames It probably should be more like psdcmyk | 17:48.40 |
| Robin_Watts | possibly, but that's a new kettle of worms. | 17:49.20 |
| ray_laptop | it looks like it predates many of the changes. It even calls gscms_transform_color rather than using the gsicc_ API | 17:49.37 |
| | Robin_Watts: agreed. It probably should go on our enhancement list as 'bountiable' | 17:50.04 |
| mvrhel_laptop | Robin_Watts and ray_laptop: so is the customer up and running. I was confused by the emails | 17:52.45 |
| Robin_Watts | mvrhel_laptop: I read their last email as being "with these changes, we are up and running" | 17:53.10 |
| mvrhel_laptop | ok | 17:53.15 |
| Robin_Watts | followed by "should the output be different?" | 17:53.29 |
| ray_laptop | Robin_Watts: yes, but the linux output is different | 17:53.38 |
| mvrhel_laptop | right. that was due to band height | 17:53.43 |
| | or your offset in the table perhaps | 17:53.53 |
| Robin_Watts | mvrhel_laptop: My supposition is that it is down to band height. | 17:53.56 |
| ray_laptop | Robin_Watts: which is what I will look into. | 17:54.09 |
| Robin_Watts | Or that they are using one of the other 2 output methods. | 17:54.16 |
| mvrhel_laptop | ok. | 17:54.19 |
| ray_laptop | Robin_Watts: I thought their original code *only* worked with BandHeight=128 | 17:54.38 |
| Robin_Watts | I'm hoping that they will reply saying that the output matches if they force the band height, but ray was going to check. | 17:54.43 |
| | ray_laptop: No, their code 'works' with any bandheight, but the noise doesn't repeat nicely over band boundaries. | 17:55.12 |
| | so it only 'works nicely' with bandheight being a multiple of 128. | 17:55.36 |
| ray_laptop | Robin_Watts: oh, right. Because they didn't adjust the starting line in the BNM depending on where the band was | 17:55.50 |
| Robin_Watts | ray_laptop: Right. | 17:55.56 |
| ray_laptop | Robin_Watts: well, I'll compare their original with -dBandHeight=128 as well as without that. If we match their code with -dBandHeight=128 I'll explain why the difference (or try to) | 17:57.09 |
| Robin_Watts | ray_laptop: yeah, I tried to explain why in the mail, but wasn't sure how well it came across. | 17:57.38 |
| ray_laptop | If I send sample files where it is evident (such as tiger) they should be able to see the 'glitches' if I point out where they occur | 17:58.56 |
| | that's one good thing about the gray fill background on tiger :-) | 17:59.24 |
| Robin_Watts | ray_laptop: It's hard to see. Possibly if you force the bandheight to be 129 or something ? | 17:59.29 |
| | Or something low, like 4. | 17:59.44 |
| ray_laptop | Robin_Watts: but I can use a compare tool :-) | 18:00.11 |
| Robin_Watts | It may be easiest just to fix their old device to be right :) | 18:00.25 |
| ray_laptop | Robin_Watts: I hesitate to do that since we want them to dump their old device ;-) | 18:00.56 |
| | particularly since it won't (AFAICT) work with BGPrint | 18:01.42 |
| | and that was a clear performance benefit. | 18:02.10 |
| Robin_Watts | We want them to ditch their old device because the mechanism it uses is deeply hacky and will paint them into such a corner they will never upgrade and we'll end up with another 532 on our hands. | 18:03.34 |
| ray_laptop | Robin_Watts: agreed. But the performance win is what we can use to convince them (we hope) | 18:05.25 |
| Robin_Watts | ray_laptop: The performance win should be a big carrot. The unmaintainability should be a big stick. | 18:06.09 |
| ray_laptop | That's why BGPrint not working with their old device will be an incentive. The other fixes we've done to the graphics lib, and even moving in your new SSE code, is fairly easy | 18:06.43 |
| | henrys: did you get cust 801's original code to build on linux ? | 18:26.11 |
| henrys | yes I did | 18:26.35 |
| Robin_Watts | ray_laptop: Are you having problems? | 18:26.41 |
| henrys | what the problem? | 18:26.45 |
| ray_laptop | All kinds of screwy libraries in their Makefile (EXTRALIBS macro) | 18:28.00 |
| henrys | ray_laptop:ah I compiled and debugged their code with pcl which doesn't have any extralibs - need to get them using configure. | 18:32.34 |
| ray_laptop | henrys: I have it building now. I just ripped out most of their EXTRALIBS junk | 18:35.51 |
| | now to see if it tigers | 18:36.37 |
| | Well, it didn't error out, and it created the 9999 directory but nothing is in there. Where did the results go, I wonder. | 18:40.27 |
| Robin_Watts | ray_laptop: Their device? | 18:41.41 |
| ray_laptop | Robin_Watts: yes, the xxxx-aps device -r600 -o x | 18:43.36 |
| Robin_Watts | IIRC you need to enable a define before it will output PGMs. | 18:44.27 |
| ray_laptop | with the new code I get a bunch of xs#.pgm files in the CWD and in 9999 I see 1.raw | 18:44.27 |
| Robin_Watts | I didn't even try to look at the raw files. | 18:44.55 |
| ray_laptop | Robin_Watts: I don't see the .raw either, but I'll have a look at their original code | 18:44.59 |
| henrys | do you have /custom/print/debug/rip2pgm? | 18:48.18 |
| | ray_laptop: ^^^ | 18:48.41 |
| Robin_Watts | I didn't know about that :( | 18:49.08 |
| henrys | they didn't make it obvious | 18:49.34 |
| ray_laptop | I have the .raw files now. | 18:53.30 |
| | phone call... | 18:53.37 |
| | henrys: I changed the RIP_FILE_PATH to be ./ (more sane) | 18:56.04 |
| | henrys: is that supposed to be an executable somewhere ? | 18:57.50 |
| henrys | ray_laptop: nope just a touched file | 18:58.04 |
| mvrhel_laptop | whew. expense report done... | 18:58.33 |
| | electronic and hard copy | 18:58.40 |
| ray_laptop | henrys: I have it at the Project_0822/debug level | 18:59.03 |
| | mvrhel_laptop: 6 mo. worth should be nice and heavy. Take the hardcopy to Japan and give it to Miles to carry around ;-) | 18:59.49 |
| mvrhel_laptop | :) | 18:59.58 |
| ray_laptop | (but make sure and keep a copy in case he loses it). He did that with one of mine I gave him at a staff mtg :-( | 19:00.34 |
| mvrhel_laptop | uhoh | 19:01.35 |
| ray_laptop | I sent him my backup copy (no original receipts) and kidded him "if you find the original, you can just submit it for payment again" :-) | 19:02.08 |
| | I haven't seen the double payment yet :-( | 19:02.45 |
| henrys | ray_laptop:PGM_FLAG doesn't use the rip path - so if you changed that you'll have to change PGM_FLAG - in pms_header.h | 19:02.55 |
| ray_laptop | henrys: rebuilding now. Thanks | 19:05.50 |
| | The inverted tiger Cyan plane is rather spooky :-) | 19:11.39 |
| | Have to run an errand. bbiab | 19:13.20 |
| Robin_Watts | mvrhel_laptop: If you're interested I have the proposed devn changes on robin/master | 19:26.21 |
| | They check out in the cluster OK. | 19:26.27 |
| | I have applied them to psdcmykog, but not to psdcmyk and psdrgb yet. Will do that next. | 19:27.23 |
| | of course, I understand if you are too busy. | 19:29.38 |
| Gigs- | Robin_Watts: what would the chance be of getting my mutool tint extension added into the main repo? It may wind up being somewhat specific in that it will only support DeviceCMYK sampled colorspace definitions. | 20:01.30 |
| | On the other hand it would be pretty "clean" in that it would only add one line to the core files to basically just add the command to mutool | 20:02.00 |
| | it will do two main things, list the colorspaces in a pdf, and have the limited ability to modify cmyk sampled tints | 20:02.50 |
| Robin_Watts | Gigs-: We'd look at it, certainly. | 20:02.53 |
| Gigs- | ok, I'll get it to a more finished state and then put a copy somewhere, may take a few days to get a copyright release from the CIO but he's given them to me in the past for open source work | 20:04.24 |
| ray_laptop | I just tumbled to the fact that their original code (cust 801) *relied* on NumRenderingThreads>0 ! Duh! | 21:11.33 |
| tom | hi! | 21:51.20 |
| | somebody here? | 21:51.27 |
| | anyway ... muPDF docu says, I can post here a bug | 22:02.35 |
| | grep -A9 wincopyfile mupdf-1.3-source/platform/x11/x11_main.c | 22:03.28 |
| | void wincopyfile(char *source, char *target) | 22:03.39 |
| | { | 22:03.39 |
| | char *buf = malloc(strlen(source)+strlen(target)+4); | 22:03.40 |
| | if (buf) | 22:03.40 |
| | { | 22:03.40 |
| | sprintf(buf, "cp %s %s", source, target); | 22:03.40 |
| | system(buf); | 22:03.40 |
| | free(buf); | 22:03.40 |
| | } | 22:03.41 |
| | } | 22:03.41 |
| | imho, we should allocate one more byte for terminating \0 | 22:04.30 |
| | so the fix is: char *buf = malloc(strlen(source)+strlen(target) + 5); | 22:05.53 |
| | that's it ;-) | 22:08.06 |
| | bye! | 22:17.12 |
| | Forward 1 day (to 2013/11/16)>>> | |
IRC Logs