| | <<<Back 1 day (to 2011/08/15) | 2011/08/16 |
| mvrhel2 | tkamppeter: I am here now | 00:26.06 |
| | chrisl_away and tkamppeter: I will look over the profile choices | 00:29.00 |
| tkamppeter | mvrhel2, can you have a look at today's commits of cups/gdevcups.c and whether all is correct? | 00:29.47 |
| mvrhel2 | tkamppeter: yes I will take a look at this | 00:29.58 |
| | my hours are a bit odd for 2 more days due to family visiting. | 00:30.34 |
| tkamppeter | mvrhel2, I have pushed another one now. This should finally deliver the correct results for bug 691922. | 00:33.22 |
| mvrhel2 | ok | 00:33.49 |
| | tkamppeter: tell me about CUPS_CSPACE_W and CUPS_CSPACE_WHITE | 00:41.38 |
| | and CUPS_CSPACE_GMCK, CUPS_CSPACE_GMCS : | 00:42.24 |
| | the CUPS_RASTER_HAVE_COLORIMETRIC are interesting ones. those you would want to have externally set. although CIELab gs could handle | 00:43.30 |
| | CUPS_CSPACE_GOLD and CUPS_CSPACE_SILVER you would also want to have set up externally | 00:44.08 |
| | but the defaults that we have are probably ok | 00:44.51 |
| | as the user who is using these color spaces probably knows what they are doing anyway | 00:46.10 |
| tkamppeter | mvrhel2, I do not know about what these color spaces are exactly, too. Probably they should even have no ICC profile at all by default and more or less a pass-through of the colors. Most drivers use only things like RGB, RGBW, CMYK, and Gray, and these need default profiles, also all derivatives of them which differ only in the order of the channels. | 00:49.02 |
| mvrhel2 | ok. then I think you are good with what you have | 00:49.32 |
| | have you tested all these color spaces? | 00:49.58 |
| | and checked with rasterview? | 00:50.14 |
| tkamppeter | mvrhel2, only standard ones: RGB, RGBW, and gray. | 00:51.50 |
| | thank you very much. please tell me whatever else you find on my last commits. | 00:52.47 |
| mvrhel2 | hmm ref count of link cache remains at 5 when gs shuts down | 01:01.32 |
| | sigh | 01:01.39 |
| | oh. the other members of the graphic state like black_generation also have a ref count of 5 | 01:11.37 |
| | oh actually lots of objects have rc's of 3 | 01:15.07 |
| | when we are closing down | 01:15.12 |
| tkamppeter | chrisl, thank you for the help yesterday. mvrhel2 appeared and had a look at it and it is all OK with the default profiles. | 07:58.21 |
| kens | tkamppeter, unless I'm reading the regression tests wrong, your commits seem to have caused a lot of seg faults. | 07:58.48 |
| | All in the CUPS device. | 07:59.14 |
| | tkamppeter, do you get the regression test resutls ? | 07:59.51 |
| tkamppeter | kens, no, I did not see them. So seems that the attempt to fix it has completely torn it apart. | 08:01.26 |
| kens | tkamppeter, can I forward you one of the mails ? | 08:01.45 |
| tkamppeter | kens, can one see where it segfaulted? | 08:02.00 |
| kens | Sadly no, it just lists which file(s) failed | 08:02.13 |
| tkamppeter | kens, please forward them to me and to chrisl. | 08:02.15 |
| chrisl | kens, tkamppeter: I guess those thanks were a little premature - I'll have a look in a little while | 08:02.20 |
| kens | chrisl definitely sees them | 08:02.23 |
| | I'll leave it with chrisl then. | 08:02.32 |
| chrisl | tkamppeter: you can see the results: http://www.ghostscript.com/cgi-bin/clustermonitor.cgi?report=1920f21e245e9e1c1ed9e8df1314b4b548088db5 | 08:02.55 |
| | It's all the banding cases that seem affected :-( | 08:03.46 |
| tkamppeter | chrisl, thanks. | 08:03.53 |
| kens | Ah, I didn't try to diagnose hte problem. | 08:03.59 |
| chrisl | Just looking at the cluster result, and that explains why I didn't see a problem. I need to finish a couple of e-mails, then I'll look at it | 08:04.48 |
| tkamppeter | chrisl, what I have already seen yesterday but put on lower priority is "gs -sDEVICE=cups -sPAPERSIZE=a4 -r300 -dcupsColorSpace=17 -sOutputFile=x rgbw-test-bug691922.ps" | 08:05.56 |
| | chrisl, this line segfaults. the .ps input file is the attachment of comment #42 of bug 691922. | 08:06.31 |
| chrisl | I wouldn't have thought that would run through the clist, but I don't know - it is probably the same issue. | 08:07.24 |
| tkamppeter | chrisl, the output file x is not yet created whgen the segfault happens. | 08:07.43 |
| chrisl | Hmmm, well, the problem seems to be that we get parameters sent thus: /OutputICCProfile /cupsInteger13 - so we get a completely bogus object for the ICC profile file name. | 08:51.52 |
| tkamppeter | chrisl, you mean that /OutputICCProfile needs an argument but it is sent without argument? Can one do something in gdevcups.c that this does not cause a problem any more? | 09:24.11 |
| chrisl | tkamppeter: essentially yes, that seems to be what's happening - I can't fathom how what I changed in gdevcups.c could cause that change. If I can work that out, I might be able to work out how to prevent it. | 09:25.44 |
| tkamppeter | Supplying an explicit output profile with "-sOutputICCProfile=..." does not suppress the segfault. | 09:30.38 |
| | chrisl, ^^\ | 09:30.46 |
| chrisl | tkamppeter: no, the "broken" call to put_params() doesn't come from the command line parameters, it's coming from somewhere else, so that wouldn't affect it | 09:32.42 |
| tkamppeter | chrisl, any idea how to get rid of the segfaults? | 10:16.43 |
| chrisl | tkamppeter: I've come to the tentative conclusions that the problem is related to garbage collection. It looks like the original code in cups_set_color_info() to installer a profile for RGBW may have been wrong, and only worked coincidentally - it looks like ICC profiles need to be allocated in non-gc memory. I've cluserpushed a test just now. | 10:35.09 |
| tkamppeter | chrisl, can you make the code visible to me somehow? | 10:49.26 |
| robin_watts_mac | tkamppeter: http://ghostscript.com/regression/ | 10:52.15 |
| | Follow the 'chrisl' link on the right hand side when chris' test completes. | 10:52.33 |
| chrisl | tkamppeter: as before: http://www.ghostscript.com/~chrisl/gdevcups.c - I've also some efficiency improvements, so we only change the profile if we have to | 10:52.48 |
| robin_watts_mac | The report page includes a diff from the current trunk. | 10:52.53 |
| chrisl | Well, that still crashes, and I can't seem to reproduce it :-( | 11:03.21 |
| tkamppeter | chrisl, I have tried it and my command line still segfaults. | 11:03.26 |
| chrisl | tkamppeter: are you using JobID-314-tmpAPUg7W-pstops-output ? | 11:05.25 |
| tkamppeter | chrisl, yes. | 11:05.43 |
| chrisl | I just ran that with: gs -sDEVICE=cups -sPAPERSIZE=a4 -r300 -dcupsColorSpace=17 -sOutputFile=x JobID-314-tmpAPUg7W-pstops-output and no seg fault | 11:06.29 |
| tkamppeter | chrisl, the report of your clusterpush has also a lot of segfaults. | 11:08.51 |
| | robin_watts_mac, thank you for the link. | 11:16.42 |
| | chrisl, it looks even like that there are more segfaults than before in your clusterpush. | 11:18.58 |
| mvrhel2 | hi kens | 11:33.10 |
| | is there an example of the use of HighLevelDevice checking in the PS code some place? | 11:33.25 |
| kens | Hi mvrhel2 give me a minute to find one | 11:35.50 |
| mvrhel2 | ok. thanks | 11:36.32 |
| kens | In gs_setpd.ps: | 11:36.56 |
| | currentdevice 1 dict dup /HighLevelDevice dup put .getdeviceparams | 11:36.56 |
| | dup type /booleantype eq not {cleartomark //true}{3 1 roll cleartomark not}ifelse | 11:37.21 |
| | The second line is error checking and defaults | 11:37.29 |
| mvrhel2 | ok. | 11:38.21 |
| kens | If the return type is not a boolean then rteh parameter was not known so use the default (//true here) otherwise preserve the value, and clear the other stack elements | 11:38.46 |
| mvrhel2 | so at the end of these two lines I will have a true or false on the top of the stack? | 11:39.29 |
| kens | Warning! ps2write is also a HighlevelDevice, but transparency needs flattened, I don't know if this makes a difference or not | 11:39.30 |
| | mvrhel2 in this case yes. | 11:39.38 |
| mvrhel2 | well, I just want to avoid having this group pushed, if we are a high level device | 11:40.02 |
| kens | OK well that code shuld do it. | 11:40.12 |
| mvrhel2 | so I want to wrap some stuff up with an if statement based upon the top value | 11:40.25 |
| kens | Exactly | 11:40.35 |
| | {...} if | 11:40.41 |
| mvrhel2 | ok. I think I can handle this now | 11:40.53 |
| kens | You can invert the boolean with 'not' if required | 11:40.55 |
| mvrhel2 | thanks kens | 11:40.55 |
| kens | NP | 11:41.06 |
| chrisl | mvrhel2: is it possible to change the device ICC profile after initialization? | 12:00.35 |
| | mvrhel2: I really need some help with this cups issue - it's got me stumped :-( | 12:21.08 |
| mvrhel2 | hi chrisl | 13:03.38 |
| | it is possible to change the ICC profile. | 13:04.23 |
| | the trick I see is telling if it was set externally or internally, but I see that you have a flag for that | 13:04.49 |
| | chrisl: what is the case that is not working? | 13:05.19 |
| chrisl | mvrhel2: I think the problem here is that we're changing the number of channels, so the raster buffer needs recreated | 13:05.35 |
| | mvrhel2: also there is a bug in gsicc_init_device_profile_struct(): "if (strncmp(curr_profile->name, profile_name, strlen(profile_name) != 0 ))" should be if (strncmp(curr_profile->name, profile_name, strlen(profile_name)) != 0 ) | 13:08.08 |
| mvrhel2 | chrisl: do you have a typo above? | 13:10.41 |
| | or I need new glasses... | 13:10.53 |
| | chrisl: are we changing the cups color space? | 13:11.18 |
| chrisl | mvrhel2: one of the trailing parentheses is in the wrong place. | 13:11.40 |
| mvrhel2 | oh my | 13:11.53 |
| | yes | 13:11.58 |
| | please commit your fix for that | 13:12.15 |
| chrisl | Okay, will do. | 13:12.23 |
| | And yes, we are changing the cups color space | 13:12.34 |
| mvrhel2 | ok, so it should be reset in that case I believe | 13:13.13 |
| | or is there a check and it is only set if one is not already there? | 13:13.38 |
| | It should be set up to change. | 13:14.21 |
| chrisl | mvrhel2: the original code *only* setup a profile if one didn't exist, and *only* for RGBW - so it works fine if the device is initialized for RGBW, but doesn't work otherwise. | 13:15.20 |
| mvrhel2 | oh I thought you fixed that with your switch statement | 13:15.52 |
| chrisl | I did, and it now crashes with a shed load of files, and all in banding mode. | 13:16.42 |
| mvrhel2 | chrisl: ok. if you want, I can take this off your hands | 13:18.26 |
| | I am wondering why banding mode would make a difference | 13:18.47 |
| | that seems odd | 13:18.49 |
| | unless there is some issue with the clist device and the cups device | 13:19.13 |
| | and the profile | 13:19.28 |
| chrisl | The banding may just be a coincidence in the way it changes the memory layout, I haven't established whether that's the case or not. | 13:20.09 |
| mvrhel2 | ok | 13:20.16 |
| | chrisl: is there a case that I can run to see? | 13:20.47 |
| | is this with the trunk or with a version that you have | 13:20.59 |
| chrisl | this is in trunk - you can see a load of test cases here: http://www.ghostscript.com/cgi-bin/clustermonitor.cgi?report=1920f21e245e9e1c1ed9e8df1314b4b548088db5 | 13:21.32 |
| mvrhel2 | ok. let me see if I can get it to explode too | 13:22.26 |
| chrisl | The command line I've been using for the cluster problems is: ./gs -r300 -o stuff.ras -dMaxBitmap=10000 -sDEVICE=cups -dcupsColorSpace=0 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dNOOUTERSAVE -dJOBSERVER -c false 0 startjob pop -f fts_01_0104.pdf | 13:22.37 |
| mvrhel2 | I wonder why libopenjpeg/opj_malloc.h keeps showing up as changed in my git checkout | 13:23.43 |
| chrisl | I hope the build doesn't change opj_malloc.h dynamically, that would be bad :-( | 13:25.44 |
| mvrhel2 | it appears that may be the case | 13:26.08 |
| | interesting. first it sets the color space to gray then to RGB | 13:36.45 |
| | ok at 72 dpi it ran fine | 13:37.20 |
| chrisl | The setting to gray will be for the DeviceGray default color space from the interpreter. | 13:37.37 |
| mvrhel2 | ok. it came from gdevcups.c though | 13:38.07 |
| | what is color space 0 | 13:38.20 |
| | oh I see | 13:38.42 |
| | CSPACE_W | 13:38.48 |
| | that is our issue | 13:38.59 |
| | that is a gray color space | 13:39.09 |
| | we need to add another case in our switch | 13:39.15 |
| | let me see if I can get it to crash first | 13:39.58 |
| | I am not getting a segv (on windows) | 13:43.46 |
| | let me see what the output looks like though | 13:43.54 |
| chrisl | Oh, actually, fts_01_0104.pdf gives me a floating point exception - hang on a sec | 13:44.32 |
| mvrhel2 | as it should be screwed up if it is using the RGB profile | 13:44.55 |
| chrisl | You could try 2colCIEtest.pdf | 13:45.43 |
| mvrhel2 | hold on a sec | 13:46.22 |
| | ok. I got the screw up | 13:51.06 |
| | my feeling is that it is due to the use of the RGB profile for a gray color space | 13:51.26 |
| chrisl | I took a punt on splitting the spaces into additive and subtractive, possibly would have been better with the number of components | 13:52.12 |
| mvrhel2 | chrisl: so for CUPS_CSPACE_K, CUPS_CSPACE_W, CUPS_CSPACE_WHITE, CUPS_CSPACE_GOLD, CUPS_CSPACE_SILVER we should load gray as the profile | 13:52.39 |
| | CUPS_CSPACE_W = 0,/* Luminance (DeviceGray, gamma 2.2 by default) */ | 13:53.09 |
| | that should not be in the RGB section | 13:53.16 |
| | right now it looks like we only have CUPS_CSPACE_K getting a gray profile | 13:53.57 |
| chrisl | mvrhel2: another question: should ICC profiles be allocated from non GC memory, or does it not matter? | 13:55.01 |
| mvrhel2 | chrisl: they should not be in gc memory | 13:58.52 |
| | there was a reason why but I can't remember it now | 13:59.08 |
| chrisl | OKay, so that's wrong as well..... | 13:59.12 |
| mvrhel2 | I think the allocator takes care of that | 13:59.17 |
| chrisl | It doesn't seem to, the code seems to just what what "mem" you give gsicc_set_device_profile() | 14:01.38 |
| mvrhel2 | hmm I see that | 14:02.24 |
| | oh it is ok | 14:03.15 |
| | gsicc_profile_new gets the non_gc memory | 14:03.24 |
| | which is the allocation we need to worry about | 14:03.31 |
| | the other allocations are local | 14:03.37 |
| | and freed | 14:03.45 |
| | chrisl: so I think it is all fine | 14:05.17 |
| chrisl | Unfortunately, not quite :-( | 14:05.41 |
| mvrhel2 | hehe | 14:05.46 |
| chrisl | This also stems from Bug 691922 | 14:06.24 |
| mvrhel2 | last comment is "it works for me" | 14:07.01 |
| | :) | 14:07.09 |
| chrisl | Yes, shame it goes "bang" for many other cases! | 14:07.30 |
| | Now, that's what raised the issue, as the last attachment in that bug sets the cups color space in the Postscript using a setpagedevice - hence the need to change the profile after initialization | 14:08.03 |
| | So using that job, it crashes if I do: ./gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -dcupsColorSpace=17 -sOutputFile=%stdout -I/usr/share/cups/fonts -f -_ < ~/Downloads/JobID-314-tmpAPUg7W-pstops-output > stuff.ras | 14:09.00 |
| mvrhel2 | chrisl: hmm.. changing CUPS_CSPACE_W to install gray has other issues... | 14:12.17 |
| | sigh | 14:12.22 |
| | I have to run my mother up to pick up her car right now | 14:12.37 |
| | chrisl: I will be back in a bit | 14:13.21 |
| chrisl | Okay | 14:13.28 |
| marcosw_ | chrisl: can we add the luratech decoders to the customer download page? | 15:04.09 |
| chrisl | marcosw_: they're in the customer archives already | 15:05.00 |
| henrys | marcosw_:I reopened the dependency bug you closed but I don't feel strongly about fixing let me know and I'll reclose it. | 15:06.13 |
| marcosw_ | chrisl: do you mean in the ghostscript-9.04.tar.gz file? | 15:06.55 |
| chrisl | marcosw_: yes, and in the ghostpdl one, too | 15:07.27 |
| marcosw_ | what about the .zip files? Are the included in the .exe? | 15:07.39 |
| chrisl | zip files? | 15:07.54 |
| henrys | we got rid of zip files. | 15:08.25 |
| | I thought | 15:08.33 |
| marcosw_ | sorry, I mean the windows installers. | 15:09.26 |
| | Aren't the self-extracting zip files? :-) | 15:09.39 |
| chrisl | Do you mean, were the commercial release Windows binaries built with luratech? | 15:10.22 |
| marcosw_ | yes, that's what I'm trying to ask. | 15:10.43 |
| chrisl | Yes, they were | 15:11.10 |
| marcosw_ | thx. | 15:13.00 |
| chrisl | np | 15:13.13 |
| marcosw_ | henrys: I'll have another look at 689077. I didn't know about checkdeps.pl, it was written while I was out of town in June and I didn't see the commit email. | 15:14.30 |
| henrys | I wrote one too: tools/check_deps.py can't have too many of things laying around ;-) | 15:15.26 |
| chrisl | mvrhel2: I might be onto something with this cups problem - the code for setting up the raster buffer checks whether the width and height have changed, but not the number of colors or bit depth of the colours. | 15:50.12 |
| mvrhel2 | ah | 15:53.50 |
| | that would be an important piece of information | 15:54.18 |
| henrys | the bit device should handle that correctly. | 15:54.32 |
| marcosw_ | henrys and robin_watts_mac: is there a reason that we don't fix the issues reported by tools/check_deps.py and toolbin/checkdeps.pl? | 15:55.37 |
| henrys | laziness | 15:55.51 |
| chrisl | mvrhel2, henrys: well, in gdev_prn_maybe_realloc_memory() it checks width and height against the parameters old_width and old_height, but no where does it check the color space | 15:57.09 |
| | I've just clusterpushed a change that has cups_put_params() check whether cups has changed the color space, and force reallocation of the raster if it has - we'll see how that goes. | 15:59.39 |
| kens | meeting ? | 15:59.43 |
| henrys | 1 minute kens | 15:59.58 |
| kens | my clock is obviously fast | 16:00.10 |
| henrys | now we can start | 16:00.17 |
| kens | :-) | 16:00.22 |
| mvrhel2 | meeting time. I had one question about 692372 | 16:00.30 |
| kens | ? | 16:00.51 |
| henrys | just 1 | 16:01.04 |
| mvrhel2 | when I run that file, I see that none of the ref counted items of the graphic state are released | 16:01.13 |
| | that file being tiger.eps | 16:01.20 |
| | see my last comment | 16:01.29 |
| kens | I did, but I have no useful information. | 16:01.45 |
| mvrhel2 | hehe. | 16:01.57 |
| | well I don't understand how gs should shut down in general | 16:02.23 |
| henrys | yes well there is always a base graphics state right? | 16:02.23 |
| chrisl | It might be that the graphics state needs a "finalize" to rc_decrement those - if there isn't one already. | 16:02.37 |
| kens | Must be an initial graphics state, yes | 16:02.50 |
| henrys | there is some special routine that has to be called to release all the states. | 16:02.51 |
| mvrhel2 | ok, if I can find that then I can make sure these things get cleaned up | 16:03.19 |
| henrys | hang on looking for it. | 16:03.37 |
| mvrhel2 | I am just worried that perhaps some stuff needs to remain when we are running as a JOBSERVER or with multiple input files | 16:04.43 |
| | but at some point even then, things need to be cleaned up when we are done | 16:05.02 |
| kens | After gsapi_delete_instance I don;t htink so | 16:05.07 |
| mvrhel2 | yes, by then it should be cleaned up :) | 16:05.20 |
| henrys | anyway I'll look for it after the meeting. | 16:06.22 |
| mvrhel2 | ok. thanks henrys | 16:06.32 |
| henrys | it should be in the same module with gsave and grestore, grestoreall off the top of my head | 16:06.56 |
| | I am kind of concerned about some bug lists in the bug aging list being longer than others. | 16:07.26 |
| kens | zgstate.c ? | 16:07.28 |
| henrys | I wonder if chrisl, kens, robin_watts_mac and I should be working on some bugs from others' lists. | 16:08.02 |
| kens | Could do that if it helps. | 16:08.14 |
| henrys | alexcher, mvrhel2: can you pick some bugs others might work on from your list. | 16:08.48 |
| | alexcher:any openjpeg problem you found during integration should be reported to the openjpeg group and have a gs bugzilla report. | 16:09.36 |
| mvrhel2 | 690538 may be good for robin | 16:09.56 |
| | a fun rounding/truncation issue | 16:10.19 |
| alexcher | henrys: if somebody feels that he can easily fix a bug from my list, I'd be glad to reassign it. | 16:10.43 |
| henrys | just go ahead and reassign any that you think could benefit from somebody else looking at it. | 16:10.51 |
| mvrhel2 | ok | 16:10.57 |
| kens | I'll look through Alex and Michael's list tomorrow to see if there's any likely cnadidates for me. | 16:11.21 |
| henrys | kens:okay, maybe chrisl and I can do the same, I'll sound off before I start working on a particular one. | 16:12.06 |
| kens | OK. | 16:12.16 |
| mvrhel2 | I have made progress on my bug list in the last six months | 16:12.23 |
| alexcher | henrys: I've posted a message on OpenJPEG mailing list. Unfortunately, alex.cherepanov@artifex.com cannot join Google groups. So I did it privately. | 16:12.35 |
| mvrhel2 | it has gone from around 90 down to the high 50s | 16:12.37 |
| henrys | mvrhel2:yes yours is much better. | 16:12.44 |
| chrisl | I've got a couple of bugs I need to resolve, then I'll have another look at other people's | 16:12.51 |
| kens | Alex is the one with most reports in the aging list | 16:13.13 |
| henrys | mvrhel2:but still a bit long relative to others, that is just the nature of the problem distribution and no reflection on you (obviously). | 16:13.36 |
| kens | He has 8, michael and ray have 4 , everyone else one or tow | 16:13.45 |
| | My totoal bug list (not just in aging) is about 85 | 16:14.07 |
| henrys | tor8:are you around? | 16:14.25 |
| mvrhel2 | henrys: I am hoping to have this down much lower soon. I am making my way through these regressions that I introduced. | 16:14.29 |
| tor8 | henrys: yeah | 16:14.31 |
| henrys | we need a release from you, when's the date? | 16:14.49 |
| | well we wanted one before the next newsletter. | 16:15.06 |
| tor8 | henrys: okay, so you still want one? I guess I could slap a tag on what we have now and call it good enough. | 16:15.28 |
| henrys | can you give me a list of improvements that I can massage for the newsletter? | 16:15.59 |
| tor8 | robin left a few loose ends with the transparency blending rework he started for the knockout/isolated that make me hesitate a bit | 16:16.02 |
| | henrys: I'll forward the list I sent to scott last week | 16:16.20 |
| henrys | okay and we can hold off until Robin is back if you are more comfortable with that. | 16:17.13 |
| tor8 | how many weeks is he gone? | 16:17.31 |
| henrys | wasn't it 2.5? | 16:17.56 |
| | that's really all I had for the meeting - anyone have stuff to add? | 16:18.44 |
| kens | Nothing from me, just been fire-fighting | 16:19.11 |
| alexcher | henrys: OpenJPEG library implements JP2 standard, but PDF needs JPX. So we mostly need extensions. | 16:19.12 |
| chrisl | Oh, I'll be on vacation next Monday, Tuesday and Wednesday | 16:19.20 |
| mvrhel2 | I don't have anything else. Thanks kens for helping me with the PS stuff earlier | 16:19.21 |
| henrys | actually I take that back xhtml-print is getting on my radar for a project, thoughts? | 16:19.31 |
| | that might fall into tor8's domain. | 16:20.13 |
| tor8 | xhtml-print? | 16:20.32 |
| kens | its a W3C standard | 16:20.45 |
| henrys | http://www.w3.org/TR/xhtml-print/ | 16:20.53 |
| mvrhel2 | these guys have it | 16:20.55 |
| | http://www.zoran.com/IPS-XP1 | 16:20.57 |
| henrys | yes one of the reasons it is on my radar. | 16:21.20 |
| mvrhel2 | I would think this is rather important | 16:21.36 |
| henrys | kens, chrisl:do you know if global is doing anything with this? | 16:21.58 |
| tor8 | henrys: right. I think my epub parser could make a decent start on this. it's got xhtml and css parsing started. | 16:22.01 |
| kens | henrys not that I've heard of. | 16:22.08 |
| chrisl | henrys: I would be surprised if global is doing any much new right now......... | 16:22.24 |
| kens | is inclined to agree | 16:22.36 |
| henrys | it has the potential to be important in the mobile market. | 16:22.57 |
| mvrhel2 | I agree | 16:23.22 |
| henrys | alexcher:we can request the extensions can't we? | 16:24.06 |
| | they are servicing mupdf, xpdf and poppler which presumably need these things as well, yes? | 16:24.45 |
| alexcher | henrys: We can indeed. I'm about to commit a hacked OpenJPEG version. The trick is to make the changes adopted. | 16:24.46 |
| mvrhel2 | alexcher: is there any reason that libopenjpeg/opj_malloc.h changes when I build? git shows it as modified | 16:26.48 |
| kens | I keep seeing rthat too. I think its a lin endings problem | 16:27.19 |
| henrys | alexcher we also have to fix memory management in all these decoders, everything should be using gs. | 16:27.20 |
| mvrhel2 | alexcher: also, are you all set with the customer and his halftone selection? you might want to send him an email to let him know you are going to send him something | 16:27.36 |
| chrisl | mvrhel2: I've just done builds on Linux and Windows, and libopenjpeg/opj_malloc.h doesn't change, I'm not at all sure why you see different | 16:28.09 |
| mvrhel2 | that is odd. | 16:28.19 |
| | kens is seeing it | 16:28.22 |
| kens | Not when building, but when committing, git gui shows it as changed. | 16:28.45 |
| alexcher | mvrhel2: I 'm not aware of any ojp_malloc.h issues. | 16:28.46 |
| chrisl | kens: does git status -uno show it as changed? | 16:29.07 |
| mvrhel2 | yes. when committing or when just checking what files have been modified | 16:29.17 |
| kens | chrisl let me check | 16:29.17 |
| | chrisl no | 16:29.49 |
| | nothing to cimmit it says | 16:29.56 |
| alexcher | mvrhel2: Yes, we need to use gs_malloc, but Luratech uses malloc() and the current implementation was copied from Luratech. | 16:29.59 |
| mvrhel2 | the file itself shows no diffs | 16:30.00 |
| | alexcher: I think that was for henrys | 16:30.12 |
| henrys | alexcher:same problem with jbig2 | 16:30.40 |
| chrisl | mvrhel2, kens: next time I commit something from Windows, I will see if I can see the problem | 16:30.59 |
| kens | git gui shows entire file opj_malloc.h being altered, but loks identical. I think line-ending problem | 16:31.15 |
| | chrisl git gui should show it, does for me | 16:31.22 |
| mvrhel2 | yes. that is what I am seeing | 16:31.42 |
| chrisl | It might be a difference between msys and cygwin - I'm using git in cygwin | 16:32.13 |
| kens | Ah, well I'm using the cut down msys | 16:32.28 |
| mvrhel2 | and I am using tortoisegit | 16:32.32 |
| kens | yours probably has Linux line endings at a guess | 16:32.38 |
| henrys | mvrhel2:so I think you need to call gs_grestore_only to completely get rid of the graphics state stack, for gs_grestore if there is not a save state one is created. | 16:32.40 |
| | I am looking in gsstate.c | 16:32.57 |
| chrisl | kens: I thought we had git configured to deal with line endings........ | 16:33.22 |
| kens | I need to leave, does anyone need anything from me before I go ? | 16:33.25 |
| | chrisl I thought so too, but I think this is maybe the source of the confusion. | 16:33.38 |
| mvrhel2 | henrys: ok I will look at that | 16:33.41 |
| kens | I could be wrong | 16:33.43 |
| chrisl | kens: I'll try to look into it | 16:33.57 |
| mvrhel2 | lunch time now | 16:34.01 |
| marcosw_ | Does anyone have any comments about the memcmp of structures issue that I fixed in Bug 692375? Are there likely to be more of these waiting to bite us in other places? | 16:34.08 |
| henrys | the mem. mannagement for this stuff is horrendous though see the discussion at the top of the c code. | 16:34.09 |
| kens | chrisl no rush, I just unstage it every time | 16:34.11 |
| | OK, no takers so goodnight all. | 16:34.41 |
| kens | slinks off. | 16:34.45 |
| henrys | marcosw_:should be pretty easy to grep through the code for that, I don't think it is a common practice. | 16:35.40 |
| marcosw_ | henrys: I've done that, and saw a couple of potential cases. I'll open a bug to remind me to follow-up. | 16:36.39 |
| chrisl | mvrhel2: looks like my idea for the cups problem didn't pan out - now a bunch of other files crash :-( | 16:39.55 |
| marcosw_ | I have to run in a few minutes, anything else for me? | 16:41.17 |
| henrys | marcosw_:thanks for catching up on all those bugs! | 16:41.38 |
| marcosw_ | no problem, sorry it took so long. I'm down to 18 open bugs, none of the customer issues :-) | 16:42.15 |
| henrys | nice | 16:43.04 |
| mvrhel2 | chrisl: :( sorry to hear this. | 16:43.07 |
| chrisl | mvrhel2: I'm trying to find a simple cluster file that goes wrong | 16:43.53 |
| mvrhel2 | that would be great | 16:44.20 |
| henrys | chrisl:funny that doesn't work I thought gdevbit.c would let you switch color model but like you said I don't see how it would reallocate and color info. | 16:44.25 |
| | I mean ... reallocate as a function of color info | 16:44.55 |
| chrisl | henrys: I think it's a hole - but then, as Alex and I pointed out, devices rarely change color space once initialized | 16:45.22 |
| henrys | please say color model or I'll be very confused ;-) | 16:45.52 |
| chrisl | okay, sorry - too-Postscripty :-) | 16:46.18 |
| henrys | We definitely should fix that though. We did have a monochrome mode working in gdevbit for a customer which did work at some point. It might work if the user only requests something that requires less memory than the default. | 16:48.40 |
| chrisl | I don't think that will work either, because the line_ptrs will still all be wrong | 16:49.16 |
| henrys | the parameter is ForceMono=1 | 16:49.52 |
| chrisl | Oh, so that might do special stuff | 16:50.13 |
| henrys | no it just seems to end up calling that "maybe" routine indirectly through the default prn_put_params. | 16:51.06 |
| | no idea how it ever worked from reading the code. | 16:51.37 |
| chrisl | Maybe it does what I'm doing, and setting the old page dimensions to nonsense values, forcing a full re-evaluation | 16:51.57 |
| | mvrhel2: I'm not having much luck, a lot of the files that are reported as crashing on the cluster, don't crash for me here. | 16:52.40 |
| | ./gs -r300 -o stuff.ras -dMaxBitmap=10000 -sDEVICE=cups -dcupsColorSpace=0 -sDEFAULTPAPERSIZE=letter -dNOPAUSE -dBATCH -K1000000 -dNOOUTERSAVE -dJOBSERVER -c false 0 startjob pop -f ../../../svn-private/comparefiles/Bug688807.pdf | 16:52.58 |
| | Above crashes consistently, but it's not the simple example I was really looking for :-( | 16:53.26 |
| | where I've gotten so far: http://www.ghostscript.com/~chrisl/gdevcups.c | 16:54.22 |
| mvrhel2 | ok, you moved the W to init with gray | 16:56.00 |
| | I guess I am confused why we did not have a problem before | 16:56.25 |
| | how did the color space 0 work fine before | 16:56.51 |
| | before being before we even put the switch in | 16:57.20 |
| chrisl | Well, did it work "fine", did anyone actually test it? | 16:57.24 |
| mvrhel2 | and only had the RGBW one set. | 16:57.33 |
| | chrisl: were these not part of the cluster push testing? | 16:57.52 |
| | so I would imagine they were tested | 16:58.04 |
| chrisl | Yes, but regression tested - I have no idea if they were right to begin with | 16:58.32 |
| mvrhel2 | but segv should have shown up | 16:58.41 |
| | chrisl: for the case in the cluster tested, I am pretty sure we were ok. I *think* I had checked rasterview | 16:59.20 |
| | I guess I am trying to figure out what problem we are (or were) trying to solve initially | 17:00.06 |
| chrisl | I suspect it worked because we would all have been setting cups color space on the command line | 17:00.33 |
| | using -dcupsColorSpace=X | 17:01.04 |
| mvrhel2 | isnt that needed ? | 17:01.25 |
| | you have it above.. | 17:01.42 |
| chrisl | No, you can also set the cups color space in Postscript script - it was a job that does that which started all this | 17:02.01 |
| mvrhel2 | oh | 17:02.08 |
| | ugh | 17:02.11 |
| | sorry to be so slow | 17:02.23 |
| chrisl | The problem being, with the old code (before I changed that switch) we'd only ever initialize to an RGBW compatible ICC profile - after initialization, we'd never change the profile there. | 17:03.33 |
| mvrhel2 | ok. I can see where that would be a problem | 17:04.33 |
| chrisl | So, I've been trying to get it to be happy changing the profile *after* device initialization, and that's where the pain is | 17:04.44 |
| mvrhel2 | so, now does it do the change? | 17:04.59 |
| | does all the color info get updated too? | 17:05.22 |
| chrisl | I *think* so - but the cups code is, ahem, not too nice...... | 17:05.51 |
| mvrhel2 | yes | 17:05.57 |
| chrisl | The function you're interested in is cups_set_color_info() and it's one of the calls from cups_put_params() - that seems to be the only time the color model can change. | 17:07.11 |
| mvrhel2 | chrisl: do we have an example ps file that I can run that changes the color model? | 17:07.43 |
| | it is strange though that we would be getting crashes with the 0 color space though | 17:08.58 |
| | with the changes that you have in place | 17:09.04 |
| chrisl | mvrhel2: the final attachment in Bug 691922 is what sparked this - it's called: JobID-314-tmpAPUg7W-pstops-output | 17:09.10 |
| | mvrhel2: well, quick question: if you look around 4104, is it right to rc_decrement() the profile at that point? | 17:09.57 |
| mvrhel2 | chrisl: it should be OK unless there is some reason that the set is not occurring. | 17:11.53 |
| | after that | 17:12.02 |
| | i.e. if it thinks the profile is the same and doesnt need to do an assign | 17:12.21 |
| | this is just a guess | 17:12.24 |
| | it should be fine | 17:13.05 |
| chrisl | Well, it won't think the profile is the same, as the profile pointer is nulled - the thing is, if I remove the rc_decrement() line, I don't see it crashing. | 17:13.50 |
| mvrhel2 | that is weird | 17:14.21 |
| chrisl | Unless the ref count is wrong - but it did look okay to me (it was a few hours ago I went through that hoop!) | 17:15.38 |
| mvrhel2 | chrisl: I will have to take a closer look at this a bit later today. I am getting ready to head back home finally from visiting relatives. Which attachment is the file in 691922? I may be able to work on it on the plane | 17:17.07 |
| | oh the last one | 17:17.31 |
| | I see | 17:17.33 |
| chrisl | yes, the last one. | 17:17.38 |
| mvrhel2 | is it a PS input? | 17:17.49 |
| chrisl | Yes, it's PS | 17:18.05 |
| mvrhel2 | ok. so what is the command line that I should use? | 17:18.21 |
| chrisl | Something like: ./gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -f -_ < ~/Downloads/JobID-314-tmpAPUg7W-pstops-output > stuff.ras | 17:19.28 |
| mvrhel2 | oh a simple one | 17:19.36 |
| chrisl | For cups, that *is* simple :-( | 17:20.05 |
| mvrhel2 | so no output color space? | 17:20.09 |
| | it is specified in the file? | 17:20.18 |
| chrisl | Yes, around line 402: <</cupsColorSpace 17/cupsBitsPerColor 8/cupsRowStep 0>>setpagedevice | 17:20.46 |
| mvrhel2 | does the above work for you now? or is it the other files/cases that are broken? | 17:21.10 |
| chrisl | That works with the gdevcups.c I put up the link for, it's other cases that now crash | 17:21.56 |
| mvrhel2 | ok. so like Bug688807.pdf | 17:22.20 |
| | that you mentioned above | 17:22.29 |
| chrisl | Yes | 17:22.38 |
| mvrhel2 | ok. I have everything now. I will beat on this tonight and then on my flight in the morning | 17:23.17 |
| | thanks chrisl | 17:23.24 |
| chrisl | The original problem was that running JobID-314-tmpAPUg7W-pstops-output like above would result in grayscale output, where it should be color | 17:23.28 |
| mvrhel2 | right. because it was not resetting | 17:24.02 |
| | it is interesting that we are only having issues in the clist case | 17:24.17 |
| | I suspect there is some color information for the clist that is not getting updated | 17:24.31 |
| | the clist sets up some stuff based upon the target | 17:24.50 |
| chrisl | That seems possible - it's not an area with which I'm familiar | 17:24.55 |
| mvrhel2 | when the clist is started | 17:25.04 |
| | it is possible that we don't update it properly | 17:25.17 |
| | changing target color models like this does not occur often. | 17:25.47 |
| | It would be interesting to see if we could do this for another device | 17:26.03 |
| | need to head out for a momemt | 17:26.10 |
| chrisl | I *thought* that it would get done by my forcing the changed page size code to run - I think that tears down the clist, and recreates | 17:26.18 |
| | mvrhel2: clusterpush *without* the rc_decrements() in cups_set_color_info() was successful - no (unexpected) crashes, no differences. | 17:31.18 |
| | mvrhel2: I need to head out for a couple of hours - if I miss you when I return: have a good journey! | 17:32.03 |
| tkamppeter | mvrhel2, chrisl_away, can I access Bug688807.pdf somewhere? | 18:27.55 |
| | marcosw_, can I access Bug688807.pdf somewhere? | 18:29.38 |
| marcosw_ | tkamppeter: do you mean the test file for Bug 688807? It doesn't appear to be customer confidential, so I can email it it you. | 18:31.39 |
| vlada_ | hi ppl, anyone awake? | 18:35.59 |
| tkamppeter | marcosw_, yes, please mail it to me. | 18:45.19 |
| marcosw_ | done | 18:45.23 |
| tkamppeter | marcosw_, thanks, this actually segfaults for me, and none of my files segfault with chrisl's last version of gdevcups.c. | 18:48.30 |
| marcosw_ | you should open a bug for the problem :-) | 18:48.49 |
| tkamppeter | marcosw_, mvrhel2 is working on it already. | 18:50.38 |
| marcosw_ | oka. | 18:50.48 |
| | y | 18:50.50 |
| vlada_ | I'm trying to do separation of one pdf file for proofing purpose, but no previous experience with gs from command line | 18:51.20 |
| tkamppeter | marcosw_, why is the bug attachment not publicly readable? It looks like a published flyer. | 18:51.30 |
| vlada_ | if I pass file to device tiffsep it produces four CMYK passes but no custom named spot color | 18:52.00 |
| | is there some easy way to produce that tiffs without knowing the name of spot or similar "complication" | 18:52.41 |
| | even name of some application for linux that can do it graphically would work... ;) | 18:53.05 |
| | anyone? | 18:53.08 |
| marcosw_ | we routinely mark all customer supplied as private. Even files that appear not to contain private information may reveal to others who the customer is based on what kind of files they process. | 18:53.37 |
| tkamppeter | marcosw_, OK, I understand. | 18:54.13 |
| marcosw_ | vladla_: if the input file includes spot colors there should be more than the four CMYK files produced. There should be one for each spot color as well. | 18:54.19 |
| vlada_ | marcosw_, http://pastebin.com/P4D5Z7mX | 18:58.14 |
| | vlada@vlada-MS-7369:~$ ls *.tif | 18:58.49 |
| | p00000001.Black.tif p00000001.Cyan.tif p00000001.Magenta.tif p00000001.tif p00000001.Yellow.tif | 18:58.49 |
| | marcosw_, maybe I should add that I've just built gs 9.04 because of bug with looking for iccprofiles | 19:00.39 |
| | ubuntu linux on amd64 | 19:00.51 |
| marcosw_ | seems odd. Can you send me a copy of the Ploca-max-1boja.pdf file? | 19:01.25 |
| vlada_ | If you're willing to accept 1,2MB file, yes | 19:02.23 |
| | marcosw_, I'll need you email address | 19:04.04 |
| marcosw_ | marcos.woehrmann@artifex.com | 19:04.16 |
| vlada_ | marcosw_, should be sent now | 19:06.40 |
| | s/now/by now | 19:06.53 |
| marcosw_ | vlada_: nothing yet, is the file large? | 19:09.08 |
| vlada_ | 1,2MB if I recall | 19:09.27 |
| | marcosw_, my bad (actually Evolutions; it has copied email as mailto:marcos.w... :| pfff | 19:11.36 |
| | marcosw_, now you should have received mail | 19:12.00 |
| marcosw_ | yes, the file arrived. Checking it now. | 19:12.19 |
| | it behaves the same way for me. I'll investigate and reply to your email when I have an answer. | 19:13.49 |
| vlada_ | marcosw_, thanks a lot. I'm using Linux and I'm not aware of any other app that can give me per plate separation output. Don't worry, I'll use it for fast searching for mistakes in color definition, not actual separation. | 19:15.54 |
| | marcosw_, It would be great if you could pass me a command line that made correct separation, if you figure out what went wrong. | 19:17.07 |
| | bye now | 19:17.15 |
| marcosw_ | vlada_: you might download a copy of Ghostscript-9.02. It appear to correctly process the file (it generates a test.s0.tif file along with the CMYK files). | 19:34.34 |
| vlada_ | test.s0.tif is spot color? | 19:36.25 |
| | any idea why that happens? | 19:39.40 |
| marcosw_ | yes, test.s0.tif is the spot color. I'm not sure why 9.02 generates the spot file and 9.04 gives an error. I'm isolating the change now and will either open a bug or email you an explanation when I figure out what is going on. | 19:40.56 |
| vlada_ | marcosw_, downloading right now. How do I uninstall 9.04 when there is no make uninstall target? Oh, well... I'll try replacing 9.04 with simple make install and hope for the best. :) | 19:54.20 |
| marcosw_ | vlada_: that should work, the 9.02 will install over the 9.04 | 19:58.52 |
| vlada_ | marcosw_, building right now. Will inform you about result later | 19:59.50 |
| marcosw_ | I have to run out for a while, but will read the irc logs when I return. | 20:00.24 |
| vlada_ | k | 20:02.16 |
| | /usr/bin/ld: cannot find -lcupsimage | 20:07.23 |
| | collect2: ld returned 1 exit status | 20:07.23 |
| | make: *** [bin/gs] Error 1 | 20:07.23 |
| | not good. can't even build it | 20:07.36 |
| chrisl_r61 | vlada_: you can either install libcupsimage-dev or do "./configure --disable-cups" | 20:18.31 |
| vlada_ | chrisl_r61, it's funny actually since 9.04 didn't complaint | 20:21.01 |
| | anyway, I've installed it and let's see if that improves something | 20:21.18 |
| | chrisl_r61, that's it! Thanks | 20:21.58 |
| chrisl_r61 | vlada_: for some reason the check for libcupsimage had been disabled a while back (before I was involved), I re-enabled it for 9.04, so 9.04 would not have tried to include the cups device | 20:22.14 |
| vlada_ | ah, ok | 20:22.29 |
| chrisl_r61 | vlada_: did you get a warning when GS 9.04 didn't produce your spot plate? | 20:27.25 |
| vlada_ | not really | 20:28.00 |
| chrisl_r61 | Hmm, okay. I only ask as I worked on a problem that prevented spot plates being omitted on 32 bit systems - it sounds like a different issue, though. | 20:30.29 |
| vlada_ | this is 64bit on amd64 | 20:30.55 |
| chrisl_r61 | Ah well, I'll leave it to marcosw_ he can punt it to me if it looks related. | 20:31.54 |
| vlada_ | chrisl_r61, with 9.02 I get error! :( | 20:36.00 |
| chrisl_r61 | vlada_: what's the error? | 20:36.15 |
| vlada_ | http://pastebin.com/EMiBj1tj | 20:37.06 |
| chrisl_r61 | you didn't give an output file to write to | 20:37.48 |
| | gs -sDEVICE=tiffsep -o Ploca-max-1boja%d%s.tiff Ploca-max-1boja.pdf or something like that might work | 20:38.39 |
| | Oops, no: gs -sDEVICE=tiffsep -o Ploca-max-1boja%d.tiff Ploca-max-1boja.pdf is more better | 20:41.12 |
| vlada_ | chrisl_r61, the same error! | 20:41.16 |
| chrisl_r61 | See above | 20:41.23 |
| vlada_ | chrisl_r61, ok | 20:42.03 |
| | hmm | 20:42.20 |
| | still no spot | 20:42.25 |
| chrisl_r61 | But you get the process plates? | 20:43.32 |
| | vlada_: I have a test file here with a spot plate in it, and it produces the spot plate from tiffsep - so it does work, at least in some cases | 20:51.24 |
| vlada_ | chrisl_r61, yes - CMYK plates are there and one without appendix to name | 20:52.28 |
| | vlada@vlada-MS-7369:~$ ls Ploca-max-1boja* | 20:52.53 |
| | Ploca-max-1boja1.tiff Ploca-max-1boja1.tiff.Cyan.tif Ploca-max-1boja1.tiff.Yellow.tif | 20:52.53 |
| | Ploca-max-1boja1.tiff.Black.tif Ploca-max-1boja1.tiff.Magenta.tif Ploca-max-1boja.pdf | 20:52.53 |
| | not sure what Ploca-max-1boja1.tiff is, but it isn't spot channel | 20:53.21 |
| chrisl_r61 | Ploca-max-1boja1.tiffis a composite approximation of all the plates - a preview | 20:54.01 |
| | (typing went awry...) Ploca-max-1boja1.tiff is a composite approximation of all the plates - a preview | 20:54.19 |
| vlada_ | thought so. thanks | 20:55.37 |
| | chrisl_r61, I'm trying with different doc now | 21:01.13 |
| | chrisl_r61, vlada@vlada-MS-7369:~$ gs -sDEVICE=tiffsep -o TESTdoc.%d.tiff TESTdoc.pdf | 21:03.02 |
| | GPL Ghostscript 9.02 (2011-03-30) | 21:03.02 |
| | Copyright (C) 2010 Artifex Software, Inc. All rights reserved. | 21:03.02 |
| | This software comes with NO WARRANTY: see the file PUBLIC for details. | 21:03.02 |
| | Processing pages 1 through 1. | 21:03.02 |
| | Page 1 | 21:03.02 |
| | %%SeparationName: Test crv | 21:03.04 |
| | %%SeparationName: Plava | 21:03.06 |
| | %%SeparationName: Test nar | 21:03.08 |
| | %%SeparationName: New Color | 21:03.10 |
| | vlada@vlada-MS-7369:~$ ls TESTdoc.* | 21:03.23 |
| | TESTdoc.1.tiff TESTdoc.1.tiff.Cyan.tif TESTdoc.1.tiff.Yellow.tif | 21:03.23 |
| | TESTdoc.1.tiff.Black.tif TESTdoc.1.tiff.Magenta.tif TESTdoc.pdf | 21:03.23 |
| | gs recognized spot colors, but did nothing with them | 21:03.53 |
| | sorry for flooding :( | 21:04.08 |
| chrisl_r61 | no worries, but I don't really know what to suggest | 21:05.21 |
| tkamppeter | chrisl_r61, your last gdevcups.c with all rc_decrement(...) calls commented out gives no segfault for me. Are the rc_decrement(...) really needed? | 21:08.19 |
| chrisl_r61 | tkamppeter: I'm not sure. Leaving may be a temporary workaround for you, at the expense of possibly leaking a bit of memory. With the way cups uses Ghostscript I think the leakage should be constant - it shouldn't go up with the size of the job, for example. | 21:11.16 |
| | s/Leaving/Leaving them out | 21:11.28 |
| tkamppeter | chrisl_r61, I could commit your gdevcups.c with the commented lines so that the cluster regression test gets triggered and we see how many segfaults will rename. I will also mark then that it is not completely finished. | 21:14.04 |
| chrisl_r61 | tkamppeter: I clusterpushed earlier with the rc_decrement()s removed, and it passed fine - I am worried it's indicative of a deeper problem, though. I do want to try something else, though...... | 21:15.20 |
| tkamppeter | chrisl_r61, so I will not do a commit for now. | 21:16.00 |
| vlada_ | chrisl_r61, thank you anyway. I've learned something along to way. | 21:16.13 |
| Kunnis | I'm fighting colorspaces with a pdf I'm working on, and I don't know how to figure it out. It shows up right in adobe acrobat reader, but if I try doing showing the seperations in acrobat, it doesn't come out right. Anyone know where I should even ask on this? | 21:16.25 |
| vlada_ | What's not right in Acrobat? I presume Professional... | 21:18.32 |
| Kunnis | I'm combing several pdfs onto one larger pdf to send to our printer. I'm creating a "White" color, for a white underprint, so we can print on clear materials. I create the white underprint as a overprint, and one of them shows up correctly as a seperation in the print preview of acrobat pro, but not the other images in the document. but in reader, I can see the overprint layer over all the graphics, exactly where the overprint shoul | 21:21.37 |
| | I take the smaller pdfs, put them in as groups in the larger pdf. I then put them in again, this time changing all of their element's colorspaces to the seperation coorspace. | 21:24.04 |
| | and set the fill overprint and the spot overprint options to true | 21:25.20 |
| | If you'd like, I can send a sample | 21:27.59 |
| chrisl_away | tkamppeter: here's what I was thinking http://www.ghostscript.com/~chrisl/gdevcups.c - so it rc_decrement()s the entire device ICC struct, instead of just the one profile. I'm hoping that means the ref counts come out right. | 21:30.15 |
| | (sorry about the changing nick, I'm jumping between computers) | 21:31.08 |
| tkamppeter | chrisl_away, I will try it, thanks. | 21:38.48 |
| chrisl_r61 | tkamppeter: it's running on the cluster now - if this doesn't work, I really am out of ideas! | 21:39.41 |
| henrys | I see the CRLF problem with obj_malloc.h on the mac also. | 21:42.47 |
| | opj_malloc.h | 21:43.00 |
| chrisl_r61 | henrys: Odd, I wonder only that one file is affected. I'll try to sort it out tomorrow. | 21:43.58 |
| Kunnis | Woohoo! I figured it out. I was setting the colorspace, but not setting the color itself. I set it to 0xff and it started looking right | 21:45.39 |
| | I've been fighting this stupid thing for most of the day. | 21:46.06 |
| henrys | is is the only file CRLF endings? | 21:47.55 |
| | s/is is/is it/ | 21:48.08 |
| chrisl_r61 | Seems to be, yes | 21:48.24 |
| | henrys: I've pushed a change so the line endings are consistent | 21:49.14 |
| henrys | It looks like if I just commit it it'll convert. | 21:49.17 |
| | oh okay. | 21:49.25 |
| chrisl_r61 | Sorry, when it hit me what it was, it was dead easy to sort | 21:49.49 |
| | Drat! I did forget to label the commit "CLUSTER_UNTESTED" :-( | 21:50.31 |
| | tkamppeter: that gdevcups.c passed the "highres" cluster test, so I've pushed a full cluster test, which will run after the commit test - it looks promising! | 21:51.06 |
| tkamppeter | chrisl_r61, great, I am doing an Ubuntu package build with it now. | 21:51.48 |
| chrisl_r61 | tkamppeter: it's getting late, but I'm going to stay online until the cluster test finishes - I *really* want this out the way! Assuming it passes the full test, I'll commit it (and heave a sigh of relief!). | 21:54.58 |
| tkamppeter | chrisl_r61, for me it works perfectly. No segfaults. I have uploaded it to Ubuntu now. | 22:01.57 |
| chrisl_r61 | tkamppeter: oh yes, that passed! Do you want to commit it, or shall I? | 22:50.35 |
| tkamppeter | chrisl_r61, mvrhel2, clusterpush finished, I do not see any segfaults with CUPS Raster there any more. | 22:51.05 |
| mvrhel2 | oh I missed everything | 22:51.23 |
| henrys | why did we check in all the segv's in the first place, can tkamppeter do local cluster pushes? | 22:51.31 |
| mvrhel2 | what was the fix? | 22:51.34 |
| tkamppeter | chrisl_r61, commit it. Thank you very much for this fix! | 22:51.39 |
| mvrhel2 | goes back to read the logs | 22:51.51 |
| chrisl_r61 | mvrhel2: Instead of decrementing the ref count of the individual profile, I do it for the whole icc_struct. | 22:52.35 |
| mvrhel2 | ah. ok | 22:52.44 |
| | oh do we reallocate a new one? | 22:52.55 |
| chrisl_r61 | Yes | 22:53.00 |
| mvrhel2 | hmm.. that is weird | 22:53.11 |
| | but I suppose it is fine as if someone is doing special profiles for text, graphic and images then they are probably setting up everything external | 22:53.46 |
| chrisl_r61 | henrys: it was a misunderstanding between tkamppeter and me - I hadn't fully tested the fix that I passed to him. | 22:53.55 |
| mvrhel2 | ok. well that is all good news | 22:54.13 |
| | frees me up to work on my bug pile on the plane | 22:54.28 |
| chrisl_r61 | mvrhel2: if you set custom profiles on the command line, as long as you set the output profile as well, it will skip the code that changes the profile - so custom profiles should be fine, too. | 22:55.39 |
| mvrhel2 | ok. sounds good. sorry to have all these issues for you to find chrisl_r6l :( | 22:56.43 |
| chrisl_r61 | mvrhel2: not a problem - I just wonder why I didn't try this 14 hours ago! | 22:57.06 |
| | tkamppeter: committed now - phew! I'm going to bed now....... | 23:05.23 |
| tkamppeter | chrisl_away, thank you very much! Good nifght. | 23:17.59 |
| | Forward 1 day (to 2011/08/17)>>> | |
IRC Logs