| | <<<Back 1 day (to 2013/06/25) | 2013/06/26 |
| mvrhel_laptop | brb | 00:07.27 |
| | argh. henrys: so it appears that to get full real blending preview working with generic CMYK devices would require the storage of some extra information. I believe for most files it would work OK but for some of the Ghent files it can't work due to the order in which the overprinting is done | 02:45.16 |
| | hmm. something just occurred to me. hold on | 02:47.19 |
| | ok. yes. It is not possible to handle every overprint situation (including the overprint mode) with only a CMYK device. In particular, if one is doing an overprint with CMYK values on top of a fill that was with a spot color it is not possible to handle this correctly if one is also going to handle the case of CMYK overprinted on previous CMYK fill | 03:06.34 |
| | since the spot color was converted to CMYK during its fill | 03:07.03 |
| | so... the question is, what do we want -dSimulateOverprint to do / mean. Right now, all subtractive devices will handle proper overprint simulation for their process colorants | 03:09.08 |
| | we can expand that a bit, with the blending when we have spot fills on top of other stuff. | 03:09.54 |
| | but if the process colorant overprint fills occur over simulated blending fills, we will not get a true overprint simulation | 03:10.37 |
| | ok. I think I am close now to the best that we can do. pushing to test | 03:24.20 |
| kens | chrisl I just ran across a limitation in Ghostscript I'd never considered before | 08:21.58 |
| | There is no filename to resource name mapping in place. So resourceforall basically just enumerates all the files in a directory. THat's OK for Linux, and tehse days for Windows, bt for systems with a limited filename, or not case-sensitive, resoruce names would be incorrect.... | 08:22.54 |
| chrisl | Hmm, I guess that's expected to be handled in the platform code? | 08:23.46 |
| kens | chrisl I don't think so, but I guess I could be wrong | 08:24.03 |
| | It seems to be why the standard encodings (eg ISOLatin1Encooding) asre loaded by executing PostScript files, rather than having them in the Resource machinery | 08:24.45 |
| | That and old PS level compatibility | 08:25.03 |
| chrisl | Well, it must have worked in some form otherwise the Dos port would never have worked | 08:25.09 |
| kens | chrisl that's what I mean | 08:25.29 |
| | I think that's why lengthy resources are pre-loaded by executing PS files | 08:25.45 |
| | lengthy names that is of course | 08:25.54 |
| chrisl | Could be, yes | 08:26.00 |
| kens | I don't have a DOS VM at the moment to try it on (and woulcn't have a compiler either....) | 08:26.18 |
| | I'm not proposing to worry about it at the moment | 08:26.26 |
| chrisl | I *seriously* doubt it would still build on DOS! | 08:26.38 |
| kens | Well there's that nutter with the Amiga port :-) | 08:26.53 |
| chrisl | But that's really on a Unix emulator - sort of.... not really AmigaOS | 08:27.23 |
| | TBH, if the issue arises, it wouldn't be hard to implement a mapping like we do for fonts | 08:27.50 |
| kens | Anyway, I've added CEEncoding, ExpertEncoding and ExpertSubsetEncoding to the resource category. They won't work on DOS, I'm not sure about OS/2 | 08:27.52 |
| chrisl | OS/2 should be fine - I *think* it ignores case, but that's not likely to be a problem | 08:28.34 |
| kens | Oh, and I've removed the hideous hack that searched Encoding naems to see if they were in the '.svn' subdirectory | 08:28.48 |
| | Since we don't use Subversion any more | 08:29.03 |
| chrisl | Yes, I should probably do a "sweep" and remove all those .svn and CVS references | 08:29.39 |
| | And we must remember to mention to tor8 and marcosw to disable the Ghostscript and GhostPDL svn servers........ | 08:30.26 |
| kens | Yes that would be good. Of course, since the sub-directory enumeration didn't actually work, the hack probably wasn't doing anything useful. | 08:30.32 |
| | Ah yes, you saw that bug comment ? | 08:30.41 |
| chrisl | Yes, it's not the first either :-( | 08:30.51 |
| kens | Definitely time to kill them | 08:31.00 |
| chrisl | kens: Oh, on the subject of filenameforall: we shouldn't list the directory names if we descend into them, is that right? | 08:31.40 |
| kens | We should never list the directory names at all | 08:31.52 |
| | Even if they are empty. We only list files | 08:32.03 |
| | Or so I believe anyway | 08:32.22 |
| chrisl | Good, that's how my "fixed" code currently works - just double checking | 08:32.24 |
| kens | I'm pretty sure its how the Windows code works :-) | 08:32.37 |
| chrisl | Anyway, have to go - have a squash match....... | 08:32.43 |
| kens | I'll be out soon too for a bit, have fun | 08:32.52 |
| kens | sees we have two new cluster nodes, parsecs and hubbles :-) | 08:43.29 |
| sebras | kensà someone is using more of their basement to heat their house? | 11:24.19 |
| sebras | needs to switch keyboard layout. | 11:24.30 |
| robin_watts_fone | my internet has broken. | 11:48.19 |
| kens | bioler, then internet, somene doesn't like you.... | 11:48.34 |
| robin_watts_fone | can anyone see anything on the eclipse internet page please? | 11:49.02 |
| kens | Well teh web page is there, any idea where problems are reported ? | 11:49.51 |
| chrisl | robin_watts_fone: it says "broadband: intermittent" | 11:50.00 |
| kens | also says broadband dSL planned maintenance, in case htat's you | 11:50.37 |
| | It does say Dial-up is working :-) | 11:50.53 |
| robin_watts_fone | yeah. that's a DNS fault with certainn routers | 11:51.01 |
| | I thought that was bonded dsl? | 11:51.26 |
| chrisl | kens: it says *bonded* DSL planned maintenance | 11:51.31 |
| kens | Oops so it does | 11:51.41 |
| chrisl | robin_watts_fone: I think you're going to have to brave tech support :-( | 11:51.46 |
| kens | I read 2 lines and merged them | 11:51.48 |
| | "Have you tried turning it off and on again ?" | 11:52.04 |
| robin_watts_fone | Chrisl: I fear you're right | 11:52.12 |
| chrisl | Do you have the number? | 11:52.26 |
| robin_watts_fone | not offhand. | 11:52.48 |
| chrisl | Are you home or business? | 11:52.57 |
| robin_watts_fone | home | 11:53.05 |
| chrisl | Home Support: 0845 1224 111 | 11:53.13 |
| robin_watts_fone | thanks | 11:53.22 |
| chrisl | Good luck! | 11:53.34 |
| henrys | oh god guillaume is going to kill me,his last problem still has me stumped. | 12:01.05 |
| kens | and he's sent you a new one | 12:01.31 |
| henrys | kens:we'll have to look at stats but I think you must have the most bugs dispatched | 12:02.34 |
| kens | henrys only because I'm closing a load of Alex's old ones :-) | 12:03.41 |
| mvrhel_laptop | nice. if I can get this overprint stuff finished I will be able to close three bugs on my list. I am hoping to have it done today | 12:04.21 |
| | nothing compared to you though kens | 12:04.30 |
| kens | thinks quantity of bugs is not a good metric, I'm sure other people just tackle harder ones | 12:04.58 |
| henrys | mvrhel_laptop: so you said last night there was going to need to be some stuff we had to punt on. | 12:05.19 |
| kens | chrisl did two knotty ones for mer last week for example | 12:05.19 |
| robin_watts_fone | exchange is knackered | 12:05.33 |
| kens | well at least its not just you robin_watts_fone | 12:05.46 |
| robin_watts_fone | phone hotspot time | 12:05.54 |
| kens | what happened to it ? Someone drove a car into it or something ? | 12:06.05 |
| mvrhel_laptop | henrys: yes. well there are a some cases that can not be properly simulated | 12:06.30 |
| henrys | yes we used to report the stats in the weekly reports and I got rid of it. There is such a huge difference in bug difficulty I thought it distorting. | 12:06.44 |
| kens | henrys I agree completely | 12:06.58 |
| henrys | mvrhel_laptop: probably obvious: but we should have some docs. | 12:07.29 |
| robin_watts_mac | kens: Dunno "major problem at exchange" apparently. Should be fixed by 4:45pm. | 12:15.13 |
| mvrhel_laptop | henrys: yes, I am going to discuss the limitation in the documentation | 12:15.19 |
| robin_watts_mac | It's not on fire cos I'd see the flames from here. | 12:15.26 |
| kens | Maybe someone stole all your copper | 12:15.56 |
| | Or ripped up the fibre thinking it was copper..... | 12:16.08 |
| mvrhel_laptop | gawd. glad I decided to drive here on monday evening. the flight they rebooked me on which should have left today is 1.5 hours delayed today so far | 12:16.33 |
| | and still has not left | 12:16.45 |
| robin_watts_mac | fibre? yeah, right. :) | 12:16.47 |
| kens | robin_watts_mac : well copper then like I said :-) | 12:17.03 |
| robin_watts_mac | kens: did you see the burbling between me/ray/chrisl last night about a way to do high level image pass thru for pdfwrite? | 12:20.50 |
| kens | robin_watts_mac : yes I did read it | 12:21.01 |
| | As chrisl points out the interpreter doesn't (usually) have knowledge of teh fileter chain, which is where the problem arises | 12:21.24 |
| | The only compression worth worrying about is JPEG (and by inference JPX) | 12:21.45 |
| | Distiller has a JPEG pass-through, and we don't so we potentially lose quality | 12:22.10 |
| robin_watts_mac | Well, from a quality point of view jpeg and jpx, yes as they are lossy | 12:22.24 |
| kens | (obviously JPX is irrelevant to Distiller since you can't put a JPX image in PostScript) | 12:22.33 |
| chrisl | kens: that was based on our discussion which was about quality - Robin and Ray were also talking about performance...... | 12:22.41 |
| robin_watts_mac | from a performance point of view jpeg, jpx, flate, ccittfax - all are important | 12:23.03 |
| kens | I understand the point about performance, but I'm less keen on doing it for that purpose | 12:23.13 |
| | It adds a lot to the complexity | 12:23.26 |
| robin_watts_mac | I was imagining that with a gs stream, you can see the top level stream function from the interpreter, yes? (I admit I have not checked) | 12:23.51 |
| kens | what do you mean by the top level stream function ? | 12:24.13 |
| robin_watts_mac | streams are a concatenation of filters. | 12:24.27 |
| kens | There isn't a 'stream' in PostScript just files and filters | 12:24.40 |
| | And a filter looks like a file | 12:24.49 |
| robin_watts_mac | OK, each filter has a function you call to get data, right? | 12:25.39 |
| kens | Once you've applied a filter, there's no way to distinguish it from a file, or know what kind of filter it is, from standard PostScript, I dont htink | 12:25.45 |
| | robin_watts_mac : No, you just call the standard file operators | 12:25.56 |
| robin_watts_mac | Not from standard postscript. | 12:25.59 |
| chrisl | kens: we could do it internally, though | 12:26.08 |
| kens | chrisl yes, but that wasn't what I thought robin_watts_mac was asking | 12:26.22 |
| robin_watts_mac | From inside the implementation of 'image' | 12:26.23 |
| kens | image calls the relevant procs I haven't looked recently | 12:26.42 |
| robin_watts_mac | When image is called, AIUI, it's passed a filter. | 12:26.47 |
| kens | No, image gets a data source, which may be a file or a string | 12:27.07 |
| | Or mutliple files or strings | 12:27.13 |
| | From teh C POV I'd have to look at the source I don;t remember | 12:27.26 |
| robin_watts_mac | It's at that stage we'd want to say "is the filter a JPEG one?" and if it is, we'd try a device call (possibly a devspecop) to say "can you handle high level jpeg images?" | 12:27.52 |
| chrisl | It would get nasty when you have multiple sources :-( | 12:28.00 |
| robin_watts_mac | jpegs can't come from multiple sources. | 12:28.09 |
| kens | JPEGs can't other image types can | 12:28.19 |
| | Like I said, ading other compressions gets harder | 12:28.30 |
| robin_watts_mac | right. for our purposes we only care about the lossy ones initially. | 12:28.47 |
| kens | For the lossy ones, I'm happy, for Flate et al, less so | 12:29.03 |
| robin_watts_mac | We can worry about flate etc later. | 12:29.21 |
| kens | More complex, less chance that the compression *should* be preserved | 12:29.23 |
| robin_watts_mac | right. | 12:29.38 |
| | anyway, I wanted to be sure you'd seen the discussion- I wasn't expecting immediate action :) | 12:30.02 |
| kens | In general, for colour images, if they aren't DCT we will need to decompress DCT and recompress | 12:30.04 |
| | Action is a *long* way off :-( | 12:30.15 |
| robin_watts_mac | kens: I disagree. | 12:30.17 |
| kens | Especially if Marcos keeps bombarding us with fuzzing bugs | 12:30.30 |
| chrisl | kens: (interjecting) Bug 694244 - I can't reproduce the valgrind errors | 12:30.37 |
| robin_watts_mac | If they are DCT then we should keep them as they are. If they aren't DCT then we should losslessly recompress. | 12:30.52 |
| | i.e. no quality loss. | 12:31.05 |
| kens | chrisl maybe you need some special sauce that Marcos runs | 12:31.10 |
| | robin_watts_mac : Not if the distiller params say that images should be DCT compressed | 12:31.32 |
| chrisl | I used exactly the command line - can't see what else I could do | 12:31.40 |
| robin_watts_mac | currently we can't realistically use that setting because recompressing DCT images as lossless ones (the only way to avoid losing quality now) is a killer. | 12:31.44 |
| | kens: right, clearly we should respect the params, but as a default we should aim for lossless operation I reckon. | 12:32.12 |
| | and currently we can't achieve that. | 12:32.28 |
| kens | robin_watts_mac : we generally do, we don't default to DCT IIRC | 12:32.36 |
| robin_watts_mac | ok. | 12:32.41 |
| kens | chrisl if yo ucan't reproduce it, then maybe Marcos tested on older code ? Anyway, seems like closing it is best or at least sedning it back to Marcos | 12:33.18 |
| chrisl | kens: okay, I'll return it to Marcos | 12:33.39 |
| kens | will be happy to see it removed from my ever-increasing list | 12:33.40 |
| chrisl | Done | 12:34.52 |
| kens | :-) | 12:34.56 |
| | I'm going to have to learn how to use valgrind so I can do that too .... | 12:35.17 |
| chrisl | You just run Ghostscript, and prefix the Ghostscript command line with "valgrind" | 12:35.52 |
| kens | That sounds easy (famous last words) | 12:36.09 |
| chrisl | kens: if you look at the valgrind logs that Marcos puts in the bugs, the exact gs command line is in the valgrind pre-amble | 12:36.35 |
| kens | That's handy, I hadn't noticed that before | 12:36.50 |
| | <sigh> can't look at some of teh commits referenced by these ancient bugs, because cvs.ghostscript.com doesn't exist any more.... | 12:38.10 |
| chrisl | kens: There's a few valgrind options that are useful - mostly "--track-origins=yes" - that will list not only where a memory error occurs, but also where valgrind thinks the memory came from. | 12:38.53 |
| kens | worth rememberin, thanks | 12:39.09 |
| chrisl | kens: I can't help but feel that if a bug if referencing a CVS commit, it is probably no longer worth worrying about! | 12:41.44 |
| kens | I'm just testing to see if the bug exists. The CVS references describe where the problem was introduced.... | 12:42.10 |
| | Yeah still happens, invalidaccess in setpagdevice | 12:43.08 |
| chrisl | is that a VM conflict? | 12:44.44 |
| kens | Yes. It happens if you execute setpagdevice while the VM allocation mode is global | 12:45.07 |
| | Alex's comment says it occurs because of an attempt to put a local VM OutputAttributes dictionary into a global allocated dictioary | 12:45.45 |
| chrisl | Hmm, is that wrong? | 12:46.08 |
| kens | I believe you can't pu local objects inside global dicts, because they can disappear unexpectedly | 12:46.49 |
| | global objects in local dicts is OK | 12:46.59 |
| chrisl | Yes, so why is it a bug? | 12:47.18 |
| kens | executing setpagdevice doesn't work if you are in a global VM context | 12:47.41 |
| chrisl | So, could we just force VM to local for setpagedevice? | 12:48.17 |
| kens | Well that would seem like on possible solution, or alllocate the OUtputAttributes dictionary in the current VM allocation mode :-) | 12:48.49 |
| | I think its the usual problem of part being done in PostScript, and part in C. | 12:49.03 |
| robin_watts_mac | TTOTD: If you buy a gunsafe, don't drop it on you toe. | 12:51.14 |
| kens | runs for a coffee | 12:51.27 |
| tor8 | robin_watts_mac: small patch on tor/master | 12:58.36 |
| kens | Hmm, interesting, I did 2 cluster tests of this code, and got no problems, committed it and got 3 seg faults, all with henrsysx6..... | 13:31.22 |
| henrys | kens:best to report it to marcosw for review if you can't reproduce it on your linux box. | 13:34.23 |
| paulgardiner | tor8: Did we have a plan for an alternative to putting a ".useBM" marker in xobject dictionaries? | 13:39.45 |
| tor8 | paulgardiner: robin implemented one | 13:42.47 |
| | pdf_obj_stash / stashed | 13:42.55 |
| paulgardiner | Oh great. :-) I'd better git fetch | 13:43.33 |
| robin_watts_mac | tor8: Looks good to me, | 13:49.35 |
| | Can you push it? gitting is tricky at the moment :) | 13:49.46 |
| tor8 | robin_watts_mac: will do :) | 13:49.56 |
| robin_watts_mac | orders ammo safe (for the other toe) | 13:50.17 |
| chrisl | kens: is it correct that if the matching file name doesn't fit in the scratch string, filenameforall exist with a rangecheck? | 14:13.56 |
| | s/exist/exits | 14:14.06 |
| kens | chrisl seems reasonable | 14:16.13 |
| chrisl | I just didn't know if it should continue trying to find matches | 14:16.34 |
| kens | Ill try disitller | 14:18.22 |
| mvrhel_laptop | that is bizarre about the tiffsep files being locked.... | 14:25.05 |
| kens | mvrhel_laptop : I have not personally tried it | 14:25.46 |
| | the reporter says its only the 64-bit version which seems truly odd | 14:26.01 |
| mvrhel_laptop | I am looking into it now. Just surprised to see it, and yes, makes no sense that it would be only 64 bit | 14:26.20 |
| kens | chrisl I can't get Distiller to produce me any filenames at all :-( | 14:27.46 |
| chrisl | kens: me neither, but I do get a rangecheck error | 14:28.09 |
| kens | that's one better than me | 14:28.18 |
| | I sort of see what's going on with the pagedevice, I reckon I can solve it in PostScript. | 14:29.05 |
| | more coffee first though | 14:29.20 |
| chrisl | kens: and I can't get distiller to let me open a file to write to, either :-( | 14:32.50 |
| kens | well distiller isn't a true rip, it has some lock downs | 14:33.18 |
| chrisl | Okay, it looks like Distiller does just stop with an error at the first file whose path length is > scratch length - which is good :-) | 14:36.12 |
| kens | Good enough for me. | 14:36.24 |
| chrisl | I wanted to check because we now get "errors" in some of the QL tests, for exactly that reason | 14:36.59 |
| kens | sigh.... | 14:37.10 |
| chrisl | Of course, whether you get the error or depends on *where* in the directory hierarchy you are when you run Ghostscript (or any other rip)! | 14:38.04 |
| kens | And what's in the directory heirarchy... | 14:38.31 |
| chrisl | So, a really bad thing for a compliance test to be trying, in the way that it does it...... | 14:39.34 |
| kens | True, but that's perfectly normal for the QL tests | 14:39.54 |
| chrisl | Doesn't mean I'm happy about it! | 14:41.05 |
| kens | Well setting the VM allocation mode to local for the duration of setpagdevice seems to solve that bug trivially, I'll just cluster test it | 14:42.14 |
| mvrhel_laptop | I am not seeing any problem with files being left open | 14:49.02 |
| | I have a PS file here with 20 spots and I am halfway through the loop in closing the files all seems fine | 14:49.38 |
| | I requested the exact file he is using to see if there is anything special with that | 14:50.04 |
| chrisl | mvrhel_laptop: does he give a command line? | 14:50.45 |
| mvrhel_laptop | he gave a c# test harness from which he is calling the dll | 14:51.11 |
| | maybe I should push this off to you ;) | 14:51.40 |
| | all looks good to me in the tiffsep device itself | 14:51.55 |
| chrisl | I wouldn't know where to start - you'd get it right back again...... | 14:52.00 |
| mvrhel_laptop | hehe | 14:52.04 |
| chrisl | He doesn't give the output file string - I wonder if he's producing multipage tiffs, and not shutting gs down properly, thus not closing the device, and clearing up open files | 14:53.11 |
| mvrhel_laptop | that was confusing to me too | 14:53.38 |
| | let me look at the csharp code for a sec | 14:53.59 |
| chrisl | Of course, I'm tempted to point out that we don't really handle Illustrator files....... | 14:54.45 |
| | mvrhel_laptop: I note he *claims* to have reproduced the problem with the code in the stock exe, which begs the question: why the c# code? | 14:56.32 |
| mvrhel_laptop | oh I did not even see that | 14:56.55 |
| | I can't replicate that | 14:57.01 |
| | but perhaps with his file | 14:57.08 |
| | ok. I have spent too much time on this already | 14:57.27 |
| | so in the C# code he is doing CreateAPIInstance, InitAP, then ExitAPI and finally DeleteAPIInstance | 14:58.27 |
| | which are mapped to gsapi_new_instance, gsapi_init_with_args, gsapi_exit and gsapi_delete_instance | 14:59.22 |
| | anyway enough of this. If after I get his file, I don't see an issue in with exe in 64 bit then I will close as works for me | 15:00.36 |
| kens | definietly | 15:00.45 |
| | welcome back robin_watts_mac dos this mean you r broadband is fixed ? | 15:07.51 |
| paulgardiner | robin_watts_mac: I've pushed that xref-section change, but I'm waiting on a cluster test | 15:10.56 |
| | robin_watts_mac: cluster test passed. Good to go | 15:32.37 |
| chrisl | kens: I've pushed my filenameforall changes to my repo, if you want to have a look - also in a branch called filenameforall. | 15:44.52 |
| kens | OK thanks, need a minute or two | 15:45.06 |
| | Hmm, actually, I wont understand the changes probably,.... | 15:46.12 |
| chrisl | Erm, they are quite trivial...... | 15:47.23 |
| kens | :) | 15:47.59 |
| | OK so how do I look at your repository on casper chrisl ? | 15:54.29 |
| chrisl | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=shortlog;h=refs/heads/filenameforall | 15:54.52 |
| kens | well I admit that does look quite trivial yes | 15:55.42 |
| | Any easy way to pull that into my branch locally ? | 15:56.34 |
| chrisl | I set up your repo as a custom remote, and then pull from it | 15:57.26 |
| kens | Sounds reasonable | 15:57.54 |
| | I'll see if I can figure that out | 15:58.02 |
| | after I stash what I'm working on | 15:58.09 |
| chrisl | git remote add <name> chrisl@ghostscript.com:/home/chrisl/repos/ghostpdl.git | 15:58.20 |
| | the switch to your filenameforall branch, and then git pull --rebase <name> filenameforall | 15:59.21 |
| | Actually, give me a second, and I'll rejig the commits so you won't get a conflict..... | 15:59.39 |
| kens | Just in tmie, I was about to pull it :-) | 16:00.10 |
| chrisl | Okay, that should work now | 16:01.08 |
| kens | FATAL ERROR: no supported authentication methods | 16:01.53 |
| chrisl | Oh, oops, sorry is should have been: | 16:02.13 |
| | git remote add <name> kenl@ghostscript.com:/home/chrisl/repos/ghostpdl.git | 16:02.23 |
| | or even: git remote add <name> ken@ghostscript.com:/home/chrisl/repos/ghostpdl.git | 16:02.37 |
| kens | aha :-) | 16:02.41 |
| | That looks better | 16:03.29 |
| | Well, I think I've got all the changes in my master now.... | 16:05.37 |
| | Hmm, no looks like I didn't get your commit | 16:06.59 |
| ray_laptop | robin_watts_mac: I'll let you or tor close bug 694376 as LATER or WONTFIX, unless you really want to keep displaying video files open as an enhancement. | 17:35.51 |
| | sure is quiet here today | 20:15.42 |
| | Spent some time clearing old bugs. Got rid of 5 of them and my oldest is now from 2008. | 20:27.38 |
| | Forward 1 day (to 2013/06/27)>>> | |
IRC Logs