| | <<<Back 1 day (to 2015/06/15) | 20150616 |
| tkamppeter | mvrhel, first, I want to tell you that I have added support for the sGray, sRGB, and AdobeRGB color spaces to the "cups"/"pwgraster" output device, to reach better compatibility with the PWG Raster data format. | 00:01.45 |
| | mvrhel, but note that I simply accept the color space codes but in reality produce simple Grayscale (DeviceGray?) and RGB (DeviceRGB?) output without special color management. | 00:03.56 |
| | mvrhel, can you have a look to get the color management correct here? | 00:04.21 |
| rayjj | mvrhel: I was under the impression that what was needed for gsview was only an rgb image for overprint preview. That is what cust 532 needs. | 01:32.45 |
| | mvrhel: if you want separations as well as the composite, then you want a device more like the "display" device with -dDisplayFormat=16#a0800 which is a true separation device that actually provides the separations and then the device "mashes" them together into the "composite" (rgb) view using the same method as the tiffsep device | 01:35.40 |
| | mvrhel: the method I am doing imposes the pdf14 compositor, forcing a "devicen" color model (so that the compositor retains the planes), then does the "mash" to RGB during the put_iimage step (when the compositor device is popped) | 01:38.09 |
| | mvrhel: it does *not* make the separation data available (neither the planes, nor the "equivalent color") to the underlying device. | 02:44.55 |
| | mvrhel: it sounds like you really want to use something like the psdcmyk or tiffsep device that keeps the planes separate all the way through to the output device and also has the equivalent color information available (the psdcmyk device writes that to the PSD file, iirc) | 02:46.44 |
| | mvrhel: the point of my enhancement is to just make a simple RGB device be able to show an overprint preview simulation w/o needing to know anything about how it was generated | 02:48.01 |
| | mvrhel: I am available tonight, briefly tomorrow morning before 7am, and then after 8:30 to discuss this | 02:48.56 |
| | tkamppeter: (for the logs). The color management relies (as of 9.00) on the ICC profile to convert to a specific variant of RGB, Gray (or CMYK). The iccprofiles directory in the Artifex distribution contain 'default_gray.icc' and 'sgray.icc' files, that are identical and are sGray, and also default_rgb.icc and srgb.icc that map to sRGB. | 04:35.09 |
| | tkamppeter: (for the logs) we don't distribute an AdobeRGB icc profile. That is easily added and a device (such as cups) can specify a different device profile. We'd have to see if mvrhel is willing to add an AdobeRGB profile (non standard) and we'd have to make sure that Adobe's license terms for bundling are acceptable (IANAL, but I think they are) | 04:44.54 |
| | tkamppeter: (for the logs) If the AdobeRGB.icc profile is in a "known" place, then the cups device will be able to specify that profile as the device output profile | 04:47.03 |
| jogux | Robin_Watts: git/cocoapods seem happy now. fwiw the parameters are --single-branch --depth 1 --branch 1.7, I can't remember which bit died with the old git. I suspect (oddly) it may have been the --depth 1 | 09:14.16 |
| kens | Maybe thats a new parameter, not supported by older Git | 09:14.44 |
| jogux | I'm sure that one has been round a few years. hohum. | 09:15.27 |
| kens | shrugs | 09:15.36 |
| jogux | kens: yeah, indeed :-) | 09:15.52 |
| | I think I also realised last night how to fix the next part of mupdf+cocoapods, need to write a script around xcodebuild to build the 4 slice library | 09:16.16 |
| | (or rather how to do it without massively reworking other parts of mupdf first :-) ) | 09:18.36 |
| kens | Robin_Watts : questoin regarding Raed and use of MuPDF when you have a minute. | 09:42.02 |
| | Robin_Watts : ping | 10:08.16 |
| Robin_Watts | pong | 10:08.35 |
| | jogux: excellent. So do we need to do the math.h -> maths.h thing? | 10:08.51 |
| kens | How much effort is involved with MuPDF if Raed needs to create a new object for an image ? If we consider an image whcih is used aby a Form, and the form is used on multple pages, and he only wants the image cahnged on one page, how much effort is it to duplciate the form content and create a new form poitning to the new image ? | 10:09.36 |
| jogux | Robin_Watts: We don't *need* to (that was one of the things I managed to work around); I suspect it might still be a worthwhile thing as it must surely have bitten other people who try to do things with mupdf in xcode. The only reason it is working for the mupdf xcode project currently is because we've not actually put the mupdf headers in the xcode project. :-) | 10:10.06 |
| Robin_Watts | kens: Creating a new object is 1 line of code. | 10:10.21 |
| | Creating a ref to it is another. | 10:10.27 |
| | Creating a form object with the image in is a few. | 10:10.49 |
| kens | I have a tentative start on an email to him, I'd like to pass it over to you for consideration. Firstly on whether I've missed anythign important, and what sort of effort you think is involed in the whole shebang from a MuPDF POV. Also when you think its likely it could be scheduled | 10:10.56 |
| Robin_Watts | kens: sure. | 10:11.24 |
| kens | OK 2 minutes while I adds that and I'll send it over. | 10:11.45 |
| | From a GS POV the more felxibility he wants the longer its going to take. | 10:12.12 |
| Robin_Watts | kens: Certainly, just replacing a given image object globally in the file is easier than trying to establish a particular instance. | 10:13.29 |
| | Remember a single graphic can be used several times on the same page. | 10:13.43 |
| | So identifying an image object number and a page is not enough for full generality. | 10:14.10 |
| kens | I know, I mentioned that too, maybe I should make more of it. Oh how about inline images ? :-) | 10:14.14 |
| Robin_Watts | kens: yeah. | 10:14.28 |
| kens | Identificaton is a problem there | 10:14.33 |
| Robin_Watts | With MuPDF we have potential to turn inline images into non-inline ones, I guess. | 10:15.00 |
| kens | COuld do that in GS too, but how would you know which one to process ? | 10:15.19 |
| Robin_Watts | kens: I have an idea for mupdf, whereby we'd identify every graphic operation (such as painting a path or image or text)with an id number | 10:16.07 |
| kens | GS already has an ID for inline images. | 10:16.32 |
| Robin_Watts | No. gs has a bitmap id. | 10:16.46 |
| | which is all to frequently -1. | 10:16.54 |
| kens | I just don't know how he wants to identify them. I'm guessing he a) hasn't considered it and b) won't be interested in inline images | 10:16.59 |
| | Robin_Watts : not in pdfwrite | 10:17.09 |
| Robin_Watts | I'm sure of a) :) | 10:17.15 |
| | With MuPDF you'd do the text extraction thing (with the image capture flag), and look at the images captured there. | 10:18.02 |
| kens | OK I rewrote the bit in identifying images to explicitly ask about multiple images on 1 page and inline images | 10:18.11 |
| | I'll send it over and you can tell me what I missed and where I'm unclear | 10:18.31 |
| Robin_Watts | When you know what image you want (and it's number) you could then rerun to find the exact image to rewrite. | 10:18.34 |
| | fab. | 10:18.35 |
| kens | By the way, I didn't thnk of it last night, but for a commercial customer its actually possible to take a PDF file with a JBIG2 image and produce a PDF file with a JBIG2 image, because the Luratech encoder is present in commercial code. | 10:20.12 |
| | JPEG and JPEG2000 are still a problem, I do need to work on that one. I guess that's my next project. | 10:20.42 |
| Robin_Watts | kens2: Yeah. but you don't want to recode the jbig2s (or jpx's) really. | 10:20.42 |
| kens | All part of the asme problem as I see it :-) | 10:20.59 |
| Robin_Watts | kens: Nice mail, with a few typos. | 10:28.59 |
| | In particular in his name :) | 10:29.06 |
| kens | Yeah I spotted some while re-reading it after I sent it | 10:31.20 |
| | If you point out the ones you see I'll fix those too (in case I missed any while reading) | 10:31.56 |
| | The spurios q of course | 10:32.11 |
| Robin_Watts | "as might be require" should be "as might be required" | 10:32.39 |
| | "as you've probably" should be "As you've probably" | 10:32.58 |
| kens | Missed that one (cause its real words) | 10:32.58 |
| Robin_Watts | Paragraph 3, sentence should split before "what is the goal of this?" | 10:33.31 |
| | Should be a : before 2a, I think. | 10:34.10 |
| | "Robin cam up with" | 10:34.24 |
| kens | I can't find an 'as you've probably' where is that ? | 10:34.32 |
| Robin_Watts | Right at the start. | 10:34.47 |
| kens | Oh I see it now | 10:34.51 |
| Robin_Watts | "PDF file wioll" | 10:35.03 |
| kens | I wonder why search didn't find that | 10:35.05 |
| | Already fixed that one | 10:35.14 |
| Robin_Watts | That's all the typos I think. | 10:36.25 |
| kens | Is there anything factual I missed that you thnk we should ask ? Any cases of image usage I didn't cover ? | 10:36.32 |
| Robin_Watts | The worry I have is that with the "Now, you state that you want to select the image to replace based on the Object Number (and generation number one assumes). Since the object can be reused on several pages (and indeed several times on a single page), you propose identifying the specific image to be replaced with a page number. " paragraph, Raed is just going to go "yes". | 10:36.58 |
| kens | In which case I'll send it back and say 'yes is not an acceptable answer' | 10:37.21 |
| Robin_Watts | Let me scribble something. | 10:37.49 |
| kens | And teh more flexibility he demands, the more likely I am to say its more than a weeks work | 10:37.55 |
| | Oh I also want to ask if he can supply example files for all the cases he wnats us to cover. | 10:39.28 |
| Robin_Watts | actually, sod it. just go with what you've got. We're going to be going back and forth for days on this. we're never going to get a straight answer on day 1. | 10:43.08 |
| kens | I agree completely with that :-) | 10:43.29 |
| | OK I'll send it now, I did add a pointed note about him supplying example files (cos I know he can't) and that will have to be factored in to the time required. | 10:44.00 |
| | Right mail sent, back to stupid marking ops inside text blocks | 10:45.57 |
| | Hmmm 22703 diffs, I guess that wasn't a good change, I wonder what I did..... | 13:34.38 |
| rayjj | kens: sounds like what I'd do ;-) | 14:17.01 |
| | heading out. bbiaw... | 14:17.17 |
| kens | I figured out the problem | 14:17.28 |
| henrys | meeting time... | 14:29.36 |
| Robin_Watts | morning | 14:30.02 |
| henrys | Robin_Watts: how did you get the bats out of your house? Bat herding is getting old. Worse than cats! | 14:30.10 |
| Robin_Watts | henrys: saucepan. | 14:30.19 |
| | or dyson :) | 14:30.36 |
| | Fortunately I think we only had the one. | 14:31.00 |
| fredross-perry | eeek | 14:31.11 |
| henrys | sometimes I catch them in a towel or something and they hiss and urinate. | 14:31.59 |
| | anyway the meeting | 14:32.10 |
| mvrhel_laptop | morning | 14:32.55 |
| henrys | going through kens patch here's what I think we should do if it is okay with kens ... | 14:32.56 |
| jogux | henrys: lovely :-( | 14:33.12 |
| henrys | assign files in the change to owners... it's too much for everyone to go through | 14:33.20 |
| kens | Yes, its massive | 14:33.26 |
| | very invasive | 14:33.30 |
| henrys | kens: for example gdeprn.c changes assigned to ray | 14:33.44 |
| | does that seem sensible. | 14:33.50 |
| kens | fie by me | 14:33.57 |
| Robin_Watts | henrys: So you're going to squash it all to a single commit and then assign file changes out? | 14:34.12 |
| henrys | Robin_Watts: I guess folks can review the way they want, but I'll look at each patch individually for the files I take on. | 14:35.04 |
| | kens: I'll assign the files | 14:35.32 |
| kens | looking at the commits makes more sense | 14:35.37 |
| | becuase the explanation (such as it is) is in the log | 14:35.48 |
| henrys | kens: yes I think that's much better but sometimes I'd find a mistake which you corrected later but that's easy enough to account for | 14:36.31 |
| kens | Yeah that is a problem, but I'm not sure there's a better approach | 14:36.55 |
| Robin_Watts | kens: Well, you can rewrite git history so that you never make the mistake... | 14:37.16 |
| kens | Robin_Watts : there are better than 100 commits | 14:37.40 |
| Robin_Watts | kens: so? | 14:37.49 |
| kens | I don't want to walk through them rearranging them | 14:37.50 |
| henrys | I like to see the history | 14:38.12 |
| | truth is good | 14:38.25 |
| | I guess this has to wait for rayjj http://bugs.ghostscript.com/show_bug.cgi?id=696018 but we never came up with a correct analysis, hate having wrong analysis in a bug and nothing else | 14:39.16 |
| | marcosw? | 14:39.31 |
| Robin_Watts | henrys: Well, we can easily add a comment saying "the analysis here is wrong; we already call _beginthreadex". | 14:40.07 |
| henrys | sure I'll copy paste that or you can do it. | 14:40.45 |
| Robin_Watts | I will. | 14:40.57 |
| | done. | 14:41.41 |
| henrys | kens: some progress on the P1 http://bugs.ghostscript.com/show_bug.cgi?id=696017 | 14:41.46 |
| | nice | 14:41.50 |
| kens | Yeah still working on the Z-ordering | 14:41.57 |
| | broke it comprehensively so far | 14:42.08 |
| henrys | that's on my list to discuss but it looks like you are moving along with it. | 14:42.12 |
| kens | Doing my best | 14:42.38 |
| | THe lineowrk 'proper' fix took a lot longer than the quick hack to prove the problem | 14:42.57 |
| henrys | kens: is this zoltan? http://bugs.ghostscript.com/show_bug.cgi?id=695253 | 14:43.47 |
| kens | Yeah that's part of the device subclassing demo code | 14:44.01 |
| | It is Zoltan indeeed | 14:44.09 |
| marcosw | henrys: sorry, i'm here. | 14:44.42 |
| henrys | kens: good to have some sort of response in the bug even if it isn't an answer or solution | 14:44.50 |
| kens | OK I'll put a '#holding' answer in there | 14:45.02 |
| henrys | marcosw: I meant to ask you at the meeting about x11 testing with xvfb, my thinking is just to test the first page of each job as a quick way to get started. | 14:45.42 |
| | all: marcosw has signed us up for coverity scanning - I looked and think I saw some interesting new problems but the signal/noise is very low in the report. | 14:46.37 |
| kens | I have a Q for marcosw as well. Once everyone has criitiqued the device subclassing code, I'd like to get all the weekly/nightly regression tests run on it before comitting it What's the best way to do that ? | 14:47.14 |
| marcosw | henrys: do we want to regression test x11 or x11alpha? | 14:47.17 |
| kens | henrys I looked at the Coverity thing this morning, looks nicer than the old interface we got. | 14:47.36 |
| | And there are some that look real in there also | 14:47.46 |
| marcosw | kens: just let me know and I will run a one-off test, the same way I do for a release candidate. takes about 2-3 days. | 14:48.17 |
| | plus the time to look at changes :-) | 14:48.35 |
| henrys | marcosw: I don't feel strongly about it but I guess alpha makes a bit more sense unless it errors out with a lot of files which I suspect it does. | 14:48.36 |
| kens | OK it won't be for a while, I will drop you a mail when everyone else has kicked it about thanks | 14:48.40 |
| | marcosw if there are changes, I'd like to evaluate and possibly fix them before comitting the code :-) | 14:49.02 |
| henrys | mvrhel: I was going to bug ray about his 2 week schedule... I'll talk to him later, but really his work doesn't hold you up making changes really right? | 14:50.01 |
| mvrhel_laptop | henrys: that is correct | 14:50.30 |
| | we really want to have the separations I think | 14:50.38 |
| henrys | mvrhel_laptop: that's good. | 14:50.49 |
| mvrhel_laptop | so his work is not really relevant | 14:50.52 |
| marcosw | henrys: I'll try x11alpha and see how it goes. Will we want to do this on a weekly basis or just occasionally? I ask because I thought we were discussing having someone make changes to the device and were worried about regressions. | 14:50.59 |
| Robin_Watts | mvrhel_laptop: Can we get both separations and the overprint simulation and the rgb version all at the same time ? | 14:51.34 |
| henrys | mvrhel_laptop: are we going to have this feature in gsview? | 14:51.35 |
| mvrhel_laptop | Robin_Watts: the rgb will show the overprint simulation | 14:51.59 |
| marcosw | kens: I assume the code is in a private repository? Is it up to date with master? | 14:51.59 |
| mvrhel_laptop | henrys: yes it will be in gsview | 14:52.07 |
| henrys | marcosw: I'd like weekly but available for local cluster runs, is that technology possible? | 14:52.08 |
| kens | marcosw its on my repo. branch is device_subclassing. Its slightly out from master, I haven't rebased for a day or two, but very close | 14:52.35 |
| | But don't do anythign with it right now | 14:52.50 |
| | Henry wants the code owners to review the changes first | 14:53.07 |
| henrys | I am also reaching out to anyone with a mobile device and a printer to test printhand, but the app and put it on your expense report and just tell me if it works for you. | 14:53.42 |
| marcosw | henrys: local cluster runs will take some work. The cluster nodes will have to have the xvfb package added to them and also there will have to be some changes to the cluster code itself. Nothing to difficult. | 14:53.43 |
| henrys | we are talking about a business arrangement with them but we haven't been able to get any printer really working well. | 14:54.22 |
| marcosw | kens: that's fine, there haven't been any major bitmap differences for at least a couple of weeks. | 14:54.23 |
| kens | The branch does throw a few, some tiny differences, a progression or three, and the usual Quality Logic insanity on the final pages | 14:55.05 |
| | But the only real changes are progressions | 14:55.18 |
| henrys | kens: I'm running into FORCE_TESTING_SUBCLASS, should that be removed? | 14:55.50 |
| kens | It will be before the code is released. It forces the devices into place for testing on the cluter, even when they aren't doing anythiong | 14:56.20 |
| henrys | that's all I have for now or at least it seems like enough ;-) | 14:56.27 |
| kens | Just to make sure their very preence doesn't break anything | 14:56.35 |
| henrys | okay | 14:56.56 |
| | off to skype for meeting II | 14:57.26 |
| kens | I need that code in when marcosw runs the regressions for me, to make sure I didn't break anything | 14:57.36 |
| jogux | henrys: did you want to talk about github? | 14:57.39 |
| henrys | jogux: I did | 14:57.49 |
| jogux | oh, I've clearly not been paying attention :) | 14:58.06 |
| henrys | chrisl: we're talking about github mirrors, whadya' think | 14:58.21 |
| chrisl | henrys: I think it'll be a pain | 14:58.34 |
| henrys | jogux: no I meant I did want to talk about it and forgot | 14:58.35 |
| jogux | ah :-) | 14:58.39 |
| henrys | and yesterday I said I can't imagine why chrisl would object ;-) | 14:59.10 |
| jogux | chrisl: this particularly came up in the context of making a cocoapod for iOS, which will have the side effect of people's CI servers potentially ending up hitting our git everytime they build. | 14:59.16 |
| marcosw | kens: shouldn't be an issue, as long it doesn't shift all of the output one pixel to the left or modify text hinting :-) | 14:59.17 |
| chrisl | We already get people bugging Tor because we don't use the github bug tracker for mupdf | 14:59.18 |
| kens | marcosw, I *really* hope it doesn't do anythign like that! | 14:59.34 |
| chrisl | If we have "official" github mirrors we'll get that even more | 14:59.54 |
| Robin_Watts | chrisl: I think having official github mirrors will increase our uptake. | 15:01.32 |
| henrys | marcosw: I don't know I think I'm the only one who uses X11 a lot and we do have a large change coming from hintak that warrants testing but it might be a lot of work without much benefit, whatever you think... | 15:02.17 |
| jogux | I agree with Robin | 15:02.18 |
| | Possibly if we wanted we could do thing that talks to github's API, sucks any bugs into bugzilla and closes them into github with a link to the bugzilla ticket. | 15:02.51 |
| henrys | chrisl: we can get somebody else to manage it. You might be a bit overtasked. | 15:03.02 |
| | with release like stuff | 15:03.12 |
| chrisl | And we'll likely also have to deal with pull requests on github, too | 15:03.26 |
| jogux | chrisl: there is a plugin that can auto-close them with 'meh, we don't do pull requests' if we want (though perhaps that's not the best approach) | 15:03.53 |
| Robin_Watts | Having scripts that push from our main repo to github every day shouldn't be hard. | 15:04.00 |
| | Part of using github is that we want to be given pull requests :) | 15:04.22 |
| jogux | github pull requests are probably a friendlier way for people to provide patches to us though, and no particular downside for us (I think?) | 15:04.41 |
| chrisl | Currently, we don't take a patch without a test case, and tracking it via bugzilla | 15:04.56 |
| Robin_Watts | Being offered fully formed patches is much easier than being asked to take random stuff in zipfiles attached to bugzilla etc. | 15:05.02 |
| jogux | Robin_Watts: the only thing I wasn't sure of was how to auto-change the sub-modules to point to github instead of casper | 15:05.22 |
| Robin_Watts | jogux: ooh, I bet they can't be. | 15:05.59 |
| | Cos that would change the SHA. | 15:06.02 |
| chrisl | I think if we want a presence on github, you're looking at "co-hosting" rather than simply mirroring | 15:06.52 |
| jogux | I can't help but feel nervous about suggesting it, but just so I know why it's bad... what if github was our master repo? | 15:08.00 |
| Robin_Watts | No! | 15:08.11 |
| | That's just wrong. | 15:08.30 |
| | When github goes tits up, where does that leave us? | 15:08.47 |
| jogux | you mean the company or temporary service issues? | 15:09.06 |
| Robin_Watts | both. | 15:09.13 |
| fredross-perry | jogux: well, that was my thought too | 15:09.41 |
| jogux | if the company goes titsup, we move stuff back (or to whatever the latest cool one is). I'd argue that long-lived service issues are more likely on casper than github. | 15:09.53 |
| henrys | I'm with jogux but I was beaten down about this in the past | 15:10.17 |
| jogux | ahhh. git submodule urls can be relative I think - that would work? | 15:11.05 |
| Robin_Watts | jogux: maybe. | 15:11.34 |
| jogux | [actually I'm not convinced about the long-lived service argument, aiui Marcos has live mirrors for casper or hotstandbys or something?] | 15:12.08 |
| chrisl | What are the implications of hosting commercial software on github? | 15:12.23 |
| Robin_Watts | jogux: casper is an aws instance. | 15:12.35 |
| jogux | chrisl: you mean dual licensed or proprietary? | 15:12.46 |
| Robin_Watts | so in terms of uptime/service we should be pretty well off. | 15:12.54 |
| chrisl | dual license - like mupdf and gs | 15:12.59 |
| henrys | doesn't understand why cocoapod will hit the server more and why it required a new git but I'll read about it. | 15:13.10 |
| jogux | chrisl: afaik, no issues. | 15:13.10 |
| chrisl | henrys: it probably needed a new git to fully support --depth, and it probably does a "git pull" every time you build | 15:14.02 |
| Robin_Watts | I would hope that it's smart enough to do: git submodule --update, which means it won't pull from the submodules unless the main repo says the SHA for the submodules has changed. | 15:14.51 |
| fredross-perry | heading out for a bit. back in 20 or so | 15:15.02 |
| Robin_Watts | So moving the main repo will remove 99% of the traffic anyway. | 15:15.09 |
| henrys | If I could start another argument on skype I could just leave and you guys wouldn't notice. | 15:15.44 |
| | ;-) | 15:15.52 |
| jogux | Robin_Watts: cocoapods main thing is a single file that lists the other projects that should be pulled into your project. you write the file, then run 'cocoapods install', and all the source etc magically appears in your xcodeproj | 15:16.04 |
| | Robin_Watts: One of the ways people use this is to check in /none/ of the third party source. In that situation, I believe they make their CI server do the 'cocoapods' install. | 15:16.28 |
| | 'cocoapods install' will do the --depth 1 pull of the full git repo, it won't have anything local to start from. | 15:17.01 |
| Robin_Watts | jogux: Right, so on an initial build, everything gets sucked down. | 15:17.06 |
| mvrhel_laptop | brb | 15:17.07 |
| jogux | (and, unless I can figure out how to make it work, it sucks down the /whole/ of the submodules, not even --depth 1) | 15:17.19 |
| | I don't 100% know that this will cause us an issue (ie. a big amazon bill?), but it sounds like it could. | 15:17.50 |
| Robin_Watts | but when you rebuild (or cocoapods install for a second time), it will presumably just pull the latest version from the git repo. | 15:18.04 |
| chrisl | I thought submodules only pulled in the specific SHA | 15:18.13 |
| jogux | [and tbh I think the github thing is good for visibility too as was said earlier] | 15:18.17 |
| Robin_Watts | and then will only get the submodules if their SHA has changed. | 15:18.24 |
| jogux | Robin_Watts: it's starting from a clean source tree. | 15:18.41 |
| Robin_Watts | chrisl: submodules are full git clones in their own right. | 15:18.44 |
| chrisl | Hmph, seems wasteful | 15:19.01 |
| jogux | chrisl: doesn't seem like it, at least not by default - just tried in my mupdf tree and I have the full git log for the submodules :-S | 15:19.05 |
| Robin_Watts | chrisl: There is no other way they can be :) | 15:19.10 |
| chrisl | --depth | 15:19.33 |
| jogux | chrisl: I tried that and got unhelpful git errors :( | 15:20.28 |
| chrisl | jogux: yeah, I assumed submodules would deal with it internally - as you can't manipulate the repo from a submodule, requiring the entire repo seems a little pointless | 15:21.31 |
| jogux | Cloning into 'thirdparty/curl'... | 15:21.58 |
| | fatal: reference is not a tree: 710915e3429efc8f3f017e76b55922846dfa20e7 | 15:21.59 |
| | Cloning into 'thirdparty/freetype'... | 15:22.00 |
| | fatal: reference is not a tree: 232bd948fd37821d35e728ec20aeea971fb9616c | 15:22.01 |
| | that's what I get with git submodule update --init --depth 1 | 15:22.11 |
| | maybe it'd be okay with a newer version of git on the client side perhaps... but that's not entirely helpful if so :) | 15:22.47 |
| chrisl | Realistically, for every product we mirror on github, everyone who regularly works on that product will need a github membership | 15:23.35 |
| jogux | chrisl: what causes that? (and why is that bad?) | 15:24.13 |
| chrisl | jogux: if we're going to be handling pull requests | 15:26.19 |
| jogux | ah, right, for pull requests, yes. | 15:26.28 |
| chrisl | And if we don't do that, people will bitch at us | 15:26.43 |
| jogux | they probably bitch at us already, just in silence :-) | 15:27.19 |
| chrisl | Well, maybe. But having an official presence on github will imply we accept (even want) patches submitted that way - which would lend a certain legitimacy to the bitching | 15:28.33 |
| Robin_Watts | We could always try this for mupdf and see how it goes? | 15:28.39 |
| | That way it would just be me/tor/paul that need to have a github account, and I suspect we all do anyway. | 15:29.02 |
| jogux | tbh I'm far less opinionated about github+ghostscript. but if we want to get mupdf out into mobile developers, at least for iOS developers cocoapods and github is a big part of their comfort zone. | 15:29.32 |
| chrisl | Like I said, we've already had complaints about Tor's mupdf and mujs github mirrors | 15:30.09 |
| jogux | I think experimenting with taking pull requests as Robin mentioned would be worthwhile | 15:30.35 |
| Robin_Watts | the complaints being what? | 15:30.42 |
| jogux | I have no objections to fielding the iOS pull requests (if henrys is happy with that) | 15:31.04 |
| chrisl | Why should have I have to report my problem on your bugzilla when I did it on github? Why won't you accept my patch without a bugzilla report etc | 15:31.28 |
| Robin_Watts | the fact we aren't using the github issue tracker? | 15:31.37 |
| chrisl | FWIW, I'm not planning to hold my breath until I turn blue to stop putting mirrors up on github. But I do think there will be on-going effort of dealing with it. | 15:33.15 |
| Robin_Watts | chrisl: If someone gives me a decent patch, a decent bug report and an example file, then, hell, I'll be happy to move it to our bug tracker :) | 15:33.24 |
| chrisl | And how do we deal with the contributor agreement going via github? | 15:34.34 |
| Robin_Watts | I think the point of having github mirrors would partly be to get more submissions from the public. If that means more work, well, that may not be a bad thing. | 15:34.35 |
| | chrisl: That's a good question. We'd have to explicitly ask them, as we transfer the issue between trackers. | 15:35.14 |
| chrisl | Ugh, I really *hate* the idea of manually copying stuff back and forward between trackers :-( | 15:35.46 |
| jogux | if it becomse an issue, both bugzilla and github have APIs (I believe) so it could be automated at that stage. | 15:36.19 |
| Robin_Watts | chrisl: I bet we can configure the bug tracker on github so it's impossible for any regular user to write to it :) | 15:36.20 |
| jogux | Robin_Watts: I think we can disable or enable it, not sure it's hugely configurable otherwise :-S | 15:36.39 |
| Robin_Watts | If we disable it, can we put up a page in place of it? | 15:36.57 |
| jogux | I don't believe so. eg: https://github.com/torvalds/linux | 15:37.52 |
| chrisl | If we disable it, but accept pull requests, won't we lose the connection between bug and patch? | 15:38.01 |
| jogux | we would be relying in people to fully document the bug in the pull request or commit messages I guess. | 15:38.46 |
| fredross-perry | back | 15:38.51 |
| Robin_Watts | kens: Well, that worked well. :( | 16:08.07 |
| kens | Yeah 'I want the Moon on a stick' | 16:08.17 |
| Robin_Watts | hand wave, gibble, miss point. | 16:08.40 |
| kens | Which is what I expected. | 16:08.52 |
| mvrhel_laptop | Robin_Watts: you there? | 16:23.21 |
| Robin_Watts | I am. | 16:23.26 |
| mvrhel_laptop | so do we want big or little endian encoding of stuff in the header etc | 16:24.02 |
| Robin_Watts | I would say little. | 16:24.14 |
| mvrhel_laptop | ok that is what I was thinking too | 16:24.22 |
| Robin_Watts | arm and intel are both little endian generally. | 16:24.34 |
| henrys | kens: have you considered pulling all the master changes to your branch to help us with looking at final diffs? | 16:35.43 |
| kens | I can do that, I do usually keep it up to date, but I;ve been busy ths week with this horrible nested textblock thng. | 16:36.18 |
| | Give me a minute and I'll pull the changes over from amster | 16:36.35 |
| | master* | 16:36.37 |
| | rebase is running now | 16:38.17 |
| | OK rebased onto master ad pushed back to kens | 16:41.26 |
| henrys | kens:thank you | 16:43.28 |
| | kens: should I assume chrisl has already reviewed? | 16:44.12 |
| kens | I wouldn't thnk so no | 16:44.19 |
| | Chris has looked at some of it, when I asked him questions about Garbage COllecton, but not a full review I don;t htink | 16:44.44 |
| chrisl | I've been more interested in the mechanics of using the new stuff, rather than the changes involved in making it happen | 16:45.34 |
| kens | Hmm, well that got rid of 16,000 diffs, still 6000 to go :-( | 16:52.30 |
| | Anyway, enough for today. Goodnight all | 16:52.45 |
| fredross-perry | mvrhel_laptop: see email | 17:02.24 |
| mvrhel_laptop | ok | 17:02.32 |
| | let me switch to skype | 17:03.14 |
| | fredross-perry: I moved to skype to talk about this | 17:07.27 |
| fredross-perry | ok | 17:07.41 |
| rayjj | mvrhel: did you see my comments about gsview and overprint preview ? | 17:12.04 |
| | mvrhel: (at the top of today's logs -- posted last night) | 17:12.26 |
| mvrhel_laptop | rayjj: yes I did. | 17:20.29 |
| | we want to have separations as well as a color managed rgb output | 17:20.43 |
| | so your work is not really an issue for us on this | 17:20.59 |
| | so the two week deadline is eased up on you ;) | 17:21.13 |
| Robin_Watts | mvrhel_laptop: What's the 2 week deadline thing? | 17:22.31 |
| | Is that when we have to have it working? | 17:22.37 |
| mvrhel_laptop | Robin_Watts: no | 17:22.41 |
| | at the staff meeting rayjj was going to have his pdf14 method of generating overprint previews done | 17:23.06 |
| | originally we were going to use that | 17:23.15 |
| Robin_Watts | This stuff has to be done before the tradeshow, right? | 17:23.21 |
| mvrhel_laptop | the problem with that though is that we loose the seps | 17:23.28 |
| | Robin_Watts: yes | 17:23.32 |
| | before the trade show | 17:23.35 |
| Robin_Watts | so possibly I should push this up my priority list (cos I have a big holiday before that) | 17:23.49 |
| mvrhel_laptop | oh right | 17:23.55 |
| | Robin_Watts: I am hoping to have the twiki write up down today or tomorrow at the latest | 17:24.15 |
| Robin_Watts | henrys: Should I look at the mupdf side of the changes for GhostProof ahead of the NUI stuff ? | 17:24.24 |
| mvrhel_laptop | Robin_Watts: If you can point me to where to add a new doc handler and image handler I may be able to do some of it too | 17:25.01 |
| | it may be a good excerscise for me | 17:25.17 |
| Robin_Watts | mvrhel_laptop: Sure. | 17:25.26 |
| | henrys: You here? | 17:26.18 |
| henrys | Robin_Watts: yes, what are we talking about ? | 17:26.53 |
| | oh right nvm | 17:27.06 |
| Robin_Watts | henrys: Well, 2 topics. | 17:27.07 |
| | First topic, this GhostProof thing. | 17:27.16 |
| | What's the priority on that compared to NUI ? | 17:27.24 |
| henrys | Robin_Watts: I think it's a tie | 17:28.06 |
| Robin_Watts | ok. | 17:28.18 |
| | Second topic... bug 695234 | 17:28.51 |
| | I cannot reproduce the SEGV, and consequently I'm pretty sure the patch supplied is wrong. | 17:29.35 |
| | but valgrind does show some uninitialised memory use. | 17:29.48 |
| | There is a claim in there from igor that this is based on some code that you wrote (but "dramatically improved" naturally :) ) | 17:30.21 |
| | Do you have any memory of this? | 17:31.13 |
| | If not, don't worry. | 17:31.18 |
| | I have a simple fix for the valgrind worries, and if that cluster tests out OK, I'm tempted to just commit and be done with it. | 17:31.38 |
| henrys | I'm afraid those synapses are not currently available. | 17:31.39 |
| Robin_Watts | OK, no worries. | 17:31.47 |
| henrys | Robin_Watts: they can always reopen if they reproduce it. | 17:31.59 |
| Robin_Watts | yeah. | 17:32.04 |
| rayjj | mvrhel: Sorry, I was on the phone. So, is GhostProof going to have the ability to switch layers on and off like the Windows display device does (with -dDisplayFormat=16#a0800) ? | 17:41.36 |
| Robin_Watts | rayjj: Yes. | 17:43.47 |
| | All the information will go into the file. | 17:44.00 |
| | MuPDF will then just pick it out as appropriate. | 17:44.12 |
| rayjj | Robin_Watts: thanks. I happen to use that feature since it's a lot handier than creating a PSD and opening it in PhotoShop | 17:44.32 |
| | Robin_Watts: I assume that gsview will actually provide the UI for selecting the separations and primaries, and that mupdf will just provide the bitmap that based on the "new image format" that gs created | 17:46.19 |
| | where the "new image format" is what you and mvrhel came up with | 17:46.52 |
| Robin_Watts | rayjj: For the show we want a demo on a tablet, right? | 17:46.53 |
| | hence it's not gsview. | 17:47.06 |
| rayjj | Robin_Watts: oh, right | 17:47.13 |
| | so it's the tablet app -- are you doing that part or fredross-perry ? | 17:47.39 |
| Robin_Watts | Which means there will be some android UI crap to do. yuck. | 17:47.40 |
| | rayjj: yes :) | 17:48.17 |
| mvrhel_laptop | rayjj: it is not clear who is doing the android work yet | 17:48.18 |
| fredross-perry | which show, and when? | 17:48.36 |
| Robin_Watts | There is work to do in mupdf itself, and in the mupdf app. | 17:48.45 |
| mvrhel_laptop | and ghostscript | 17:48.52 |
| rayjj | Robin_Watts: right -- gs needs to write the new format, mupdf needs to be able to read it and process it into a viewable bitmap (presumably using some layer selection params from the app level) | 17:50.00 |
| Robin_Watts | rayjj: yes. | 17:50.19 |
| rayjj | is the thinking that mupdf will produce the RGB from the layers and info about the 'equivalent colors' or will gs do that ? | 17:50.49 |
| Robin_Watts | rayjj: gs will do all that. | 17:51.08 |
| | mupdf is literally picking either raw rgb out of the file, or the selected separations (and combining them naively) | 17:51.46 |
| rayjj | I see. So switching layers on and off really won't work | 17:51.48 |
| mvrhel_laptop | huh | 17:51.58 |
| | why | 17:52.00 |
| Robin_Watts | it will work, but it won't be color correct. | 17:52.05 |
| henrys | rayjj: we discussed this at the meeting and you were to work on a project that would bring all this to an rgb device and it would take 2 weeks. Did I miss a memo? | 17:52.23 |
| mvrhel_laptop | right. but the rgb preview will be colorimetrically correct | 17:52.24 |
| Robin_Watts | mvrhel_laptop: right. | 17:52.38 |
| rayjj | mvrhel: mupdf would need to know how to build up a composite from just selected layers for that to work | 17:52.41 |
| mvrhel_laptop | yes. that is in the format | 17:52.54 |
| | spot color names, | 17:53.07 |
| | equivalent rgb and cmyk values | 17:53.13 |
| rayjj | henrys: the problem is that the approach I am doing doesn't provide separations | 17:53.16 |
| | henrys: it provides a composite to a 'dumb' device | 17:53.45 |
| mvrhel_laptop | right. so your work is no longer keeping us from moving forward | 17:54.06 |
| rayjj | (where dumb means a device that can't do separations) | 17:54.07 |
| | henrys: but for the tablet 'proofing' device, they want separations | 17:54.36 |
| mvrhel_laptop | and we will have the capability to view seps as well as have a color managed output | 17:54.37 |
| | this will be useful for gsview as well as the tablet | 17:54.58 |
| henrys | okay I didn't understand I thought all the color management we'd do would be baked intto the rgb output, isn't that what we said at the meeting? | 17:55.29 |
| mvrhel_laptop | yes it is all baked in | 17:55.46 |
| | however | 17:55.54 |
| | we are adding the separations too | 17:55.59 |
| | so that we can view those | 17:56.05 |
| rayjj | mvrhel: if you want to be able to show the composite with only selected primaries or spot colors, you need to be able to build up the composite in mupdf, right ? | 17:56.12 |
| mvrhel_laptop | yes | 17:56.22 |
| Robin_Watts | This is why the output format has both the color correct rgb, and the separation data. | 17:56.44 |
| mvrhel_laptop | mupdf will generate an rgb image from the selected spots | 17:56.45 |
| Robin_Watts | mupdf can either just display the color correct rgb, or it can display combinations of spots by doing the combination itself (but that result will not be color correct) | 17:57.21 |
| mvrhel_laptop | yes | 17:57.29 |
| rayjj | mvrhel: but it makes sense that any view without all of the layers or primaries cannot be "proof" color, so any old approach of mashing to a composite RGB is pretty much OK, IMHO | 17:57.37 |
| Robin_Watts | mvrhel_laptop: I think *we* are in agreement at least :) | 17:57.52 |
| rayjj | what Robin_Watts just said | 17:57.53 |
| mvrhel_laptop | Not sure if you have an issue with what we are doing or not rayjj | 17:58.27 |
| Robin_Watts | I think, from rays last comment, that he is in agreement with us too. | 17:58.43 |
| mvrhel_laptop | ok good | 17:58.47 |
| rayjj | mvrhel: no, it sounds fine. I was just making sure I understood as well | 17:58.48 |
| | Robin_Watts: yes | 17:58.51 |
| mvrhel_laptop | yes if you start throwing out colorants then real "color mangement" should not be expected | 17:59.28 |
| rayjj | but it does mean that mupdf will need to know how to build up a composite RGB from spot equivalent colors | 17:59.32 |
| mvrhel_laptop | yes | 17:59.39 |
| rayjj | mvrhel: right. | 17:59.40 |
| Robin_Watts | I can see that people might get a tad confused if they disable an unused spot, and suddenly the color changes :) | 18:01.18 |
| mvrhel_laptop | that is true | 18:01.29 |
| | we need to think a bit about that | 18:01.43 |
| Robin_Watts | Maybe, we should have a 'used or not' flag for each spot in each 256x256 image? | 18:01.47 |
| rayjj | mvrhel: once you guys decide on a format, if you are both too busy, I could probably hack up the tiffsep or psd device to do the gs device, but if you want to keep it on your plate(s), fine | 18:01.59 |
| Robin_Watts | Then if all the used spots are enabled, we can just use the rgb for that image? | 18:02.03 |
| | That might be confusing in that tiles would look different though. | 18:02.30 |
| rayjj | Robin_Watts: sounds like a future enhancement | 18:02.51 |
| Robin_Watts | rayjj: Well, in future we hope to have color management in mupdf, so then we can display stuff properly. | 18:03.26 |
| mvrhel_laptop | Robin_Watts: Perhaps the following. We actually have a "color proofing" mode that shows the RGB color managed. If someone starts to throw out spots they are no longer in color proofing mode | 18:04.02 |
| rayjj | a status flag that just tells the user that the image is 'proof color' that goes away when the colors are approximate seems adequate | 18:04.04 |
| mvrhel_laptop | rayjj: yes | 18:04.42 |
| rayjj | or an alert flag when colors are approximate -- whatever the UI gurus think up | 18:04.58 |
| mvrhel_laptop | right. need to head out. bbbiab | 18:05.27 |
| rayjj | it's just that tablet screen space is at a premium | 18:05.29 |
| | mvrhel: me too. | 18:05.37 |
| | bbiab | 18:05.41 |
| Robin_Watts | I would be tempted by a simple thing where we have a row of spots across the top of the screen. | 18:08.42 |
| | Tapping each spot toggles it on/off (and the squares for each spot go 'hollow' when off). | 18:10.01 |
| SpNg | whenever I run some postscript against an EPS that contains embeded fonts gs is outputting the error âLast OS error: No such file or directoryâ this does not happen when the EPS has no embedded fonts. Why would embedded fonts cause gs to fail? (using gs 9.15) | 18:52.56 |
| Robin_Watts | SpNg: A vanilla 9.15? | 18:54.55 |
| | I would suggest that you try 9.16 | 18:55.41 |
| | If that doesn't work, let us know the exact command you're using, and give us the file that's having problems. | 18:55.57 |
| SpNg | Robin_Watts: my install command: RUN curl -sO http://downloads.ghostscript.com/public/binaries/ghostscript-9.15-linux-x86_64.tgz && tar -vxf ghostscript-9.15-linux-x86_64.tgz mv ghostscript-9.15-linux-x86_64/gs-915-linux_x86_64 /usr/local/bin/gs && cd .. rm -rf ghostscript* | 18:56.08 |
| Robin_Watts | ok. | 18:56.33 |
| SpNg | Robin_Watts: I can upgrade to 9.16 and give that a run. | 18:56.59 |
| rayjj | Robin_Watts: if you hold down on a spot it could pop up an 'info' box with the spot name and maybe the equivalent color in CMYK and/or RGB | 19:05.34 |
| Robin_Watts | rayjj: yeah. | 19:06.42 |
| | http://ghostscript.com/~regression/robin/ | 19:07.16 |
| | Does that right a bell for anyone? | 19:07.22 |
| rayjj | Robin_Watts: part of the row could be reserved for the "alert" flag (yellow triangle with an ! in it, or whatever) that if you tap it explains that colors are approximate because not all colorants are enabled | 19:07.49 |
| Robin_Watts | rayjj: yeah, there are all sorts of things we can do. With many spots we may not be able to fit them across the top of the screen on a phone, say. | 19:08.36 |
| rayjj | Robin_Watts: I've seen that (and ignored it) because I can't reproduce it. some glyph mapping problem I presume | 19:08.45 |
| Robin_Watts | rayjj: Fab. I shall ignore it too then. Thanks. | 19:09.01 |
| rayjj | Robin_Watts: that's what scroll arrows are for | 19:09.12 |
| | Robin_Watts: it's always one of the CET font files (3*_all.PS) | 19:09.52 |
| SpNg | brb | 19:42.04 |
| kens | Robin_Watts : 34_all.ps keeps on doing that, its some kind of weird checksumming thing that the QL CET tests do | 19:54.46 |
| | It causes frequent changes but I don;t believe its a real problem | 19:55.35 |
| rayjj | Robin_Watts: Now that henrys has put out a review list, and my name shows up on it, what do I have to do to get ken's changes into someplace I can review the files. The problem I have is that the http://git.ghostscript.com/?p=user/ken/ghostpdl.git;a=log;h=refs/heads/device_subclassing doesn't show which files are changed | 20:36.36 |
| | do I have to create a clone and pull his branch or something ? | 20:36.58 |
| | so I can see the equivalent of git log --name-only | 20:37.16 |
| | have to run an errand. I'll check the logs later | 20:37.52 |
| henrys | add [remote "kens"] | 20:39.51 |
| | url = git://git.ghostscript.com/user/ken/ghostpdl.git | 20:39.52 |
| | fetch = +refs/heads/*:refs/remotes/ken/* | 20:39.53 |
| | to your config, then pull "kens" then I did: git difftool --tool=meld master device_subclassing, but you can use plain diff | 20:39.54 |
| | You can also have a separate clone and just do a regular diff if you don't want to be gittish | 20:40.56 |
| | FWIW the following example might be useful for reviewing individual files across branches if you do use git: git diff master device_subclassing -- gs/base/gdevp14.c | 20:54.51 |
| | bbiab | 20:58.17 |
| Robin_Watts | rayjj: git remote add ken ray@ghostscript.com:/home/ken/repos/ghostpdl.git | 21:11.44 |
| | Then git fetch ken device_subclassing | 21:11.56 |
| | That will produce a branch in your local one called ken/device_subclassing. | 21:12.15 |
| | You can then look at the changes on it using: gitk ken/device_subclassing | 21:12.35 |
| | or to look at only commits that change particular files: | 21:12.51 |
| | gitk ken/device_subclassing -- file1 file2 file3 .... | 21:13.07 |
| | rayjj: You missed my git burbling :) | 21:15.45 |
| rayjj | Robin_Watts: I tried your method (git fetch after adding the remote for kens) and it gave me: From ghostscript.com:/home/ken/repos/ghostpdl | 21:23.35 |
| | * branch device_subclassing -> FETCH_HEAD | 21:23.37 |
| | but then git branch doesn't list it, and git co device_subclassing fails as does git co kens/device_subclassing | 21:23.38 |
| | so I did the "nuclear" (slow) option that henrys suggested and that does create ken/device_subclassing and allow me to check it out | 21:25.27 |
| | Thanks to both of you | 21:25.28 |
| henrys | rayjj: what was slow, you mean cloning? | 21:26.53 |
| rayjj | henrys: the 'pull' to a "throw away" clone I have around | 21:27.33 |
| mvrhel_laptop | bbiab | 21:27.57 |
| rayjj | doesn't trust real work-in-process git sandboxes to experimental (new to me) git actions | 21:28.28 |
| | in theory, I can get ANYTHING back from a git screw-up, but... my way is easier when I know I will eventually throw it away and just reset --hard to origin/master | 21:29.23 |
| | henrys: and by slow, I mean, 40 seconds of download or something | 21:29.50 |
| henrys | Robin_Watts missed my git burblings and repeated it all double burbling ... | 21:30.20 |
| rayjj | oh, no. Martin is back :-( | 21:30.38 |
| henrys | rayjj: yea I saw that ugh | 21:31.01 |
| rayjj | mvrhel: I think you are in the hot seat on this one (at least initially) | 21:31.21 |
| | miles had to jinx things and mention that no customers have called him to complain about support. :-/ | 21:32.05 |
| fredross-perry | mvrhel_laptop ru about? | 23:10.30 |
| Robin_Watts | fredross-perry: can I help? | 23:17.00 |
| fredross-perry | no, I just wanted to stop Michael from finishing an onerous task because I think Iâve got it wired based on a previous suggestion of his. | 23:17.47 |
| | but thanks | 23:18.24 |
| mvrhel_laptop | fredross-perry: I am back | 23:32.57 |
| fredross-perry | yes head to Skype please | 23:33.08 |
| mvrhel_laptop | ok | 23:33.12 |
| | I am confused what Martin wants to do | 23:39.04 |
| | at least with this file | 23:39.34 |
| | I understand the he wants for profile his printer | 23:39.46 |
| | s/the/that/ | 23:39.52 |
| | s/for/to/ | 23:39.57 |
| | Forward 1 day (to 2015/06/17)>>> | |
IRC Logs