| | <<<Back 1 day (to 2012/02/14) | 2012/02/15 |
| Robin_Watts | sebras: I need to rejig the aalevel stuff a bit. | 00:04.01 |
| | It needs to move from context to draw device. | 00:04.12 |
| | So just skip that for now. | 00:04.18 |
| henrys | mvrhel:ping | 03:19.41 |
| | mvrhel - gotta go I'll send you email. | 03:27.17 |
| mvrhel | henrys: got your email. lets chat a bit tomorrow so I understand what needs to be done | 04:18.49 |
| | I still get a bit confused about user and device params | 04:19.12 |
| henrys | mvrhel:for example the code in set_default_gray_icc would be moved to a gs/base file and wrapped in a function called gs_setdefaultgrayicc - you would just call the operator from zusparam.c ... | 04:39.45 |
| | that way I don't have to copy all the code in set_default_gray_icc() ... zusparam.c is not compiled into the pcl or xps build. | 04:40.59 |
| mvrhel | henrys: gotcha. ok. I will work on doing that | 04:44.09 |
| | ok. there are quite a few functions to move... | 05:23.23 |
| | sorry about that henrys | 05:23.28 |
| | I remember doing this now | 05:23.56 |
| | at the time there were no user_string_params | 05:24.09 |
| | I should have recognized how to do this then though | 05:52.23 |
| sebras | Robin_Watts tor8: noted. | 09:27.48 |
| scott-san | Robin are you on? | 14:16.54 |
| Robin_Watts | I am, hi. | 14:17.10 |
| scott-san | Can you come up on FB for a personal conversation? | 14:17.39 |
| Robin_Watts | Sure. | 14:17.44 |
| scott-san | Ok Bye | 14:17.51 |
| Robin_Watts | chrisl, tor8: We've been invited to eat with Scott and his Daughter in SF after the Alcatraz tour. | 15:25.38 |
| | (Sadly, tour is now sold out, so they can't join us) | 15:25.49 |
| chrisl | Robin_Watts: sounds good - shame about the tour, though | 15:26.22 |
| Robin_Watts | yeah. I knew they sold out early, but had hoped there might still be some available. | 15:26.50 |
| chrisl | So, Scott must either not like his daughter too much, or we must be less onerous company than I thought! ;-) | 15:30.25 |
| Robin_Watts | He's booking a table at "The Stinking Rose", an "Italian Garlic" restaurant. | 15:31.43 |
| | Sounds awesome. | 15:31.47 |
| henrys | chrisl:a new customer for you email on the way, it's your lucky day ;-) | 15:32.06 |
| chrisl | henrys: oh joy, thanks..... | 15:33.03 |
| Robin_Watts | tor8: Just got given a pdf file from the mupdf customer, that they got from a publisher. | 15:33.04 |
| | Looks like it's pdf tk produced. | 15:33.19 |
| | And the xref seems to use 000000000 65536 n when it really means 000000000 65535 f | 15:33.56 |
| | And Acrobat doesn't whinge. | 15:34.08 |
| tor8 | Robin_Watts: about dinner: great. | 15:34.22 |
| | Robin_Watts: hm, I thought apple was the main producer of that sort of xref table | 15:34.38 |
| Robin_Watts | Well, maybe it's been post processed by pdftk, but originally came from apple. | 15:35.03 |
| | tor8: Any objection to me special casing 000000000 65536 to mean 'f' ? | 15:36.23 |
| tor8 | we should probably special case 0000000 * to mean 'f' | 15:36.39 |
| | would save us repairing all of apple quartz produced pdf files | 15:36.56 |
| Robin_Watts | ok. | 15:37.02 |
| | They've also asked about whether we can do something about fallback rendering of overly large jpegs. | 15:38.54 |
| | i.e. if they have a jpeg that we can't decode because of memory issues, can we fall back and decode it smaller? | 15:39.21 |
| | bbiab. | 15:39.29 |
| tor8 | if we store jpegs uncompressed as a special type of fz_image, we could decode at the smaller coefficients | 15:39.32 |
| | and save us some trouble scaling | 15:39.41 |
| chrisl | henrys: Scott seems to have answered all the questions in there (so far) - the only thing to add, really, is that we now supply DroidSansFallback which can be used for Japanese text | 15:40.00 |
| henrys | chrisl:right so just answer whatever there is to answer the important thing is they want an engineer contact for technical questions that arise. So the introduction is what is important. | 15:43.50 |
| chrisl | henrys: sure, I'm just working out how best to mention the DroidSansFallback addition | 15:44.28 |
| henrys | saying something like we have good support for CJK and customers frequently use non latin fonts with ghostscrit seems like a good thing to mention. | 15:46.04 |
| | the email that just came into support is that a new customer? | 15:48.50 |
| chrisl | henrys: not that I've heard - he's also reported on bugzilla, so I'm guessing not a customer. esp as using 8.71...... | 15:50.04 |
| henrys | I sent something to scott and miles | 15:51.22 |
| Robin_Watts | henrys: That mail to support... | 16:01.43 |
| | If you look at his supplied UpgradeLog.XML file, it shows a problem trying to upgrade pcl6_msvc.sln | 16:02.11 |
| | We don't (and never have) supplied a pcl6_msvc.sln file, AIUI. | 16:02.31 |
| henrys | right but I recall in msvc you could open the makefile and it would generate a sln, that is no longer supported. | 16:08.24 |
| | and opening pcl6_msvc.mak would create pcl6_msvc.sln | 16:09.10 |
| | anyway lets see waht miles and scott say. | 16:09.27 |
| Robin_Watts | ah, ok, maybe yes. | 16:12.52 |
| | Anyone looking at Gemmas issues? | 16:18.27 |
| chrisl | I'm just looking, but her report isn't very clear | 16:18.46 |
| | Robin_Watts: looks like color issues in the output, "wouldn't process" to me suggests an error | 16:21.12 |
| Robin_Watts | yes. | 16:21.26 |
| chrisl | This is outside my area of knowledge...... | 16:22.03 |
| Robin_Watts | I'll send her a quick email back asking her to tell us exactly what's wrong. | 16:23.00 |
| chrisl | Robin_Watts: is there an easy to pull OUT one commit in git - like a cherry pick in reverse? | 16:23.34 |
| Robin_Watts | git revert ? | 16:23.42 |
| chrisl | No I mean a "historical" commit, just to remove that diff from the working directory, not actually obliterate the commit | 16:24.29 |
| Robin_Watts | git revert hash | 16:24.42 |
| | That adds a new commit that reverts the changes made in a previous commit (or commits) hash. | 16:25.01 |
| chrisl | Oh, great, thanks! | 16:25.11 |
| Robin_Watts | np. | 16:25.17 |
| henrys | so it looks like marcos thought 9.05 would fix gemma's woes and it didn't. | 16:26.09 |
| Robin_Watts | Time to break the cluster... | 16:28.59 |
| | told you I was going to break the cluster :( | 16:47.25 |
| mvrhel | I have managed to get a stomach flu so I am going to be in and out today.... | 17:01.02 |
| henrys_laptop | sorry to hear that hope the kids stay healthy | 17:01.45 |
| mvrhel | thanks. one of them already had it last week... we are supposed to go skiing tomorrow through saturday. I hope I get over this quickly | 17:02.55 |
| Robin_Watts | mvrhel: While you are here... | 17:15.48 |
| | Are you on the support email? Did you see the latest mail from Gemma? | 17:16.22 |
| mvrhel | I do get the support emails | 17:16.33 |
| | let me look | 17:16.37 |
| Robin_Watts | If I run the following: | 17:16.49 |
| | gs/bin/gswin32c.exe -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r400 -dMaxBitmap=500000000 -dAlignToPixels=0 -dGrid | 17:16.59 |
| | FitTT=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dDOINTERPOLATE -dFirstPage=1 -dLastPage=1 -sOutputFile=out.tif ../My | 17:17.01 |
| | Tests/WMB1102317A01.pdf | 17:17.03 |
| | Bah. | 17:17.05 |
| | gs/bin/gswin32c.exe -sDEVICE=tiffsep -dNOPAUSE -dBATCH -dSAFER -r400 -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=0 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -dDOINTERPOLATE -dFirstPage=1 -dLastPage=1 -sOutputFile=out.tif ../MyTests/WMB1102317A01.pdf | 17:17.14 |
| | I do see a block that's far darker than it should be. | 17:17.33 |
| mvrhel | hmm I wonder if this has gradients in spot colors | 17:18.20 |
| Robin_Watts | With -dNOINTERPOLATE it looks perfect. | 17:18.47 |
| mvrhel | hold on let me grab the file and try to run it | 17:20.39 |
| | Robin_Watts: does the color change with resolution with -dDOINTERPOLATE? | 17:22.58 |
| Robin_Watts | mvrhel: I haven't tried that. | 17:23.13 |
| | I will do. | 17:23.20 |
| mvrhel | recall that we did do a change where we do the interpolation in one color space at high res and the other at low res | 17:23.30 |
| | source color vs. des. color | 17:23.37 |
| | to speed things along | 17:23.51 |
| Robin_Watts | Apparently some of her files are still giving the "Cannot encode colour" thing, and some crash. | 17:24.18 |
| mvrhel | ok this cannot encode color issue is due to the compressed color encoding failures | 17:24.50 |
| Robin_Watts | At 72dpi, I get the same results as at 400. | 17:25.06 |
| mvrhel | we need to move to an array of color values | 17:25.19 |
| | I thought ray did some fixes on the compressed color encoding though | 17:26.35 |
| | is she running 9.05? | 17:26.49 |
| Robin_Watts | She is | 17:27.03 |
| | Gawd. I'm getting a crash in clist stuff now. | 17:27.28 |
| mvrhel | uhoh | 17:27.39 |
| Robin_Watts | Let me do a clean build. That looks suspicious. | 17:28.38 |
| mvrhel | I had to update my source. rebuilding | 17:31.35 |
| Robin_Watts | OK, the crash is down to a mistake in the interpolation code. Joy. | 17:36.24 |
| mvrhel | mine is taking forever to run | 17:36.40 |
| | there it finished | 17:37.07 |
| Robin_Watts | Eek. We have an image that's being scaled to 0 by 0. | 17:37.52 |
| mvrhel | oh | 17:40.00 |
| | what resolution were you running | 17:40.15 |
| Robin_Watts | 400dpi! | 17:40.19 |
| mvrhel | huh | 17:40.27 |
| Robin_Watts | Well, if we're scaling to 0 wide or 0 high, we don't care whether we interpolate or not :) | 17:41.19 |
| | so I've got some code that bales in that case. | 17:41.29 |
| | Hey ray. How's Karen? | 17:41.35 |
| chrisl | Robin_Watts: is the cluster functioning? | 17:42.04 |
| Robin_Watts | chrisl: Yes. | 17:42.12 |
| mvrhel | so I do see the black part | 17:42.13 |
| chrisl | Cool, ta | 17:42.18 |
| Robin_Watts | I broke mupdf was all. | 17:42.21 |
| mvrhel | interesting product.... | 17:42.45 |
| chrisl | I just wanted to check - didn't want to push, and trample over a work-in-progress | 17:42.50 |
| Robin_Watts | No, it should be fine now. | 17:43.08 |
| | I'm about to remove mupdfdraw and that's the binary that the cluster calls. | 17:43.22 |
| | It should now cope with calling mudraw instead. | 17:43.29 |
| chrisl | doh, I forgot to update my source first | 17:44.19 |
| mvrhel | Robin_Watts: so you have this issue figure out ? | 17:49.01 |
| | figured... | 17:49.35 |
| | bbiab | 17:50.01 |
| Robin_Watts | mvrhel: No. | 17:50.25 |
| | I have a workaround for the crashing in 1 of the files. | 17:50.43 |
| | Another one is down to non encodable pixels | 17:50.59 |
| | geez. a different issue in every file :( | 17:52.48 |
| mvrhel | Robin_Watts: I am not sure I am going to be of much help with this today | 17:58.20 |
| | let me go and try to eat something | 17:58.39 |
| | bbiab | 17:58.40 |
| ray_laptop | Morning, all | 18:00.20 |
| henrys_laptop | hi ray_laptop | 18:00.44 |
| | are you still at the hospital? | 18:00.58 |
| ray_laptop | sorry I 'went dark' yesterday -- there were insurance company hassles that occupied me all day. | 18:01.01 |
| | I'm home right now, but heading over to the (new) hospital. The insurance company forced a transfer (which was what I was trying to prevent) | 18:01.50 |
| | at least the new place is 10 minutes away instead of 25-45 minutes (and is only 3 minutes from the twins' school) | 18:03.12 |
| henrys_laptop | so they'll do the surgery there? | 18:03.31 |
| ray_laptop | henrys: right. At least the surgeon has a good rep. and is a nice guy. | 18:04.33 |
| Robin_Watts | ray_laptop: So when will the surgery take place ? | 18:04.45 |
| ray_laptop | the time is not scheduled yet, but he said it will be late this afternoon or this evening. | 18:05.26 |
| | Robin_Watts: on the non-encodeable tiffsep issue -- there is a funky bit of code that I spotted in the compressed encoding that can result in a 0 component being encoded as the 'solid' color, when that is better encoded (I think) using the colorant bitmap | 18:07.24 |
| | Robin_Watts: but when I changed that for one of Gemma's files, it actually INCREASED the non-encodeable count. So I didn't commit that "fix" | 18:08.30 |
| | Robin_Watts: but if you have a different file from them that is giving non-encodeable pixels, it may be that the patch will help. | 18:09.18 |
| chrisl | ray_laptop: could we change tiffsep to render one plate at a time - that should workaround the non-encodeable color problem, wouldn't it? | 18:09.53 |
| Robin_Watts | ray_laptop: Is there any reason we can't have her run with a minimum bandsize ? | 18:09.54 |
| | -dMaxBitmap=10000 | 18:10.28 |
| ray_laptop | chrisl: tiffsep already has the ability to accept a list of the plates you want and make multiple runs to get them all. | 18:14.14 |
| | chrisl: if you build GS to not use the compressed encoding, then you get CMYK plus 4 separations per "pass". | 18:14.53 |
| chrisl | ray_laptop: oh, I thought we were doing all the plates in one go | 18:15.41 |
| Robin_Watts | I'm getting a SEGV in free_compressed_color_list for one file. | 18:15.46 |
| ray_laptop | chrisl: the problem with generating the subset of colorants is that the CMYK composite is then incorrect, and the customer actually wants the composite. It's just that we don't do overprint correctly without generating the separations | 18:16.01 |
| chrisl | Yeh, good point - ah well..... | 18:16.38 |
| ray_laptop | chrisl: by default, tiffsep uses compressed encoding and does all of the plates at once -- which works 99% of the time | 18:16.41 |
| | chrisl: in fact, for this customer, they don't even do anything with the separation files -- just delete them | 18:17.22 |
| Robin_Watts | ray_laptop: pcomp_list is full of feeefeee | 18:17.40 |
| chrisl | ray_laptop: so why don't they use tiff32, then? | 18:17.59 |
| | Oh, overprint - sorry | 18:18.19 |
| ray_laptop | If we wrote a tool to collect the separations with the "equivalent" color for each spot color, then we could composite plates together | 18:18.20 |
| | chrisl: but it's an pretty inconvenient way to run. | 18:19.24 |
| chrisl | ray_laptop: yeh, I was just trying to think of a workaround, because eliminating the non-encodeable colors problem completely sounds like a fairly big project | 18:20.23 |
| ray_laptop | chrisl: yeah, that's right. I have to break free from cust 532 in order to tackle that (unless someone else does) | 18:22.25 |
| Robin_Watts | Why can't we have her run with a smaller MaxBitmap ? | 18:23.11 |
| ray_laptop | Robin_Watts: to track those down I usually resort to -ZA | 18:23.14 |
| Robin_Watts | ray_laptop: Memento! :) | 18:23.24 |
| ray_laptop | Robin_Watts: does it work OK with clist mode and just not with page mode ? | 18:23.39 |
| Robin_Watts | She is running with a MaxBitmap of 500000000 | 18:23.55 |
| | AIUI, we get a new set of compressed encoding colors for each band. | 18:24.17 |
| | hence smaller bands mean less likely to hit the problem. | 18:24.29 |
| ray_laptop | Robin_Watts: the problem is that we need to write the encoded (compressed) colors into the clist | 18:25.22 |
| Robin_Watts | So... smaller bands = larger clist data. | 18:25.41 |
| | Do we care? | 18:25.46 |
| ray_laptop | Only _some_ things go into the clist as high-level colors | 18:26.03 |
| | Robin_Watts: there isn't a per band encoded color list in the clist per band state (unless I missed something) | 18:26.45 |
| Robin_Watts | oh, so we DON'T have a new set of colors each time? | 18:27.15 |
| | So why does changing the MaxBitmap solve the problem for at least 1 file here ? | 18:27.31 |
| ray_laptop | Robin_Watts: that would be a SEVERE performance hit. For a rectange that covers more than one band it would be filled, we'd have to get encode a different compressed color for each band, using its list | 18:28.13 |
| Robin_Watts | I'm confused now. | 18:28.53 |
| | at the moment, I don't care about performance. I just care about giving the customer something that can run to completion. | 18:29.17 |
| | Why does decreasing the MaxBitmap solve the problem? | 18:29.50 |
| ray_laptop | Robin_Watts: I was seeing an effect caused by the pdf14 composition resulting in colors that were created during rendering (due to blending), but the set of colors used to paint the transparency buffers were all able to be encoded | 18:30.44 |
| | And in this case, it is the 'put_image' that is getting all of the encoded colors | 18:31.29 |
| | and since each band _is_ rendered with a compressed color list created from the set created during clist writing, then ADDED to by the pdf14 put_image action, we may or may not end up exceeding the encodeable color set | 18:33.15 |
| | depending on the band size. | 18:33.32 |
| Robin_Watts | Right, so reducing the band height *might* help, but it might hinder? | 18:34.09 |
| ray_laptop | In page buffer mode, the superset of colorants for the entire page is needed. So clist mode _can_ help (in some cases) | 18:34.14 |
| | Robin_Watts: it won't hinder -- it just may not help to reduce band size (but it _will_ impact performance) | 18:34.49 |
| Robin_Watts | There look to be funky GC routines for coping with compressed_color_list, but not for pdf14_compressed_color_list | 18:41.26 |
| | Is that an omission? | 18:41.31 |
| ray_laptop | Robin_Watts: if they are different st_ type structures, then yes it is a bug. It depends on how the structure is allocated (what st type) | 18:43.30 |
| | Robin_Watts: let me look | 18:43.55 |
| Robin_Watts | gs_devn_params | 18:44.04 |
| ray_laptop | in line 486 of base/gdevp14.c I see: RELOC_PTR(pdf14_device, devn_params.compressed_color_list); | 18:45.02 |
| | oops that's the RELOC, but there is also line 474: case 4: ENUM_RETURN(pdev->devn_params.compressed_color_list); | 18:46.03 |
| | these are part of the enum and reloc GC functions for the pdf14_device structure | 18:46.41 |
| Robin_Watts | I see code in gdevpsd.c, gdevtsep.c and gdevp14.c | 18:47.13 |
| ray_laptop | Robin_Watts: phone call -- bbiab | 18:47.13 |
| Robin_Watts | all of which deal with devn_params.compressed_color_list, but no corresponding code for devn_params.pdf14_compressed_color_list. | 18:47.37 |
| | Interesting. gs_devn_params is not being alloced large enough. | 19:03.24 |
| | Oh, ignore me. | 19:03.47 |
| | Right. Fixing the garbage collection means we don't get a SEGV any more. | 19:04.24 |
| | We just get a rangecheck in showpage. | 19:04.32 |
| ray_laptop | Robin_Watts: rangecheck is what we throw when we get non-encodeable colors, right ? | 19:12.07 |
| Robin_Watts | Is it? | 19:12.19 |
| ray_laptop | goes to checlk | 19:12.44 |
| Robin_Watts | I wasn't seeing "WARNING: blah blah non encodable colors" | 19:12.56 |
| ray_laptop | Robin_Watts: see lline 1706 gdevtsep.c | 19:14.06 |
| Robin_Watts | Is there a cunning trick to catching such error returns in the debugger? | 19:14.12 |
| | Trying with a breakpoint there. | 19:14.45 |
| ray_laptop | Robin_Watts: you mean when the compressed encoding fails ? | 19:14.46 |
| Robin_Watts | In general, it'd be nice if there was some way to put a breakpoint in the debugger that would go off at the point at which a non-zero return code was used. | 19:15.31 |
| ray_laptop | Robin_Watts: line 1471 of base/gdevdevn.c | 19:15.45 |
| | and other places -- just search for NON_ENCODEABLE_COLOR | 19:16.38 |
| Robin_Watts | Ok. The range check didn't come from them. | 19:16.45 |
| ray_laptop | Robin_Watts: heading over to see Karen (with the kids) now. bbiaw | 19:23.08 |
| Robin_Watts | cu. | 19:23.14 |
| | alexcher: You here? | 20:28.03 |
| Robin_Watts | breaks out the git blame | 20:29.32 |
| | look like tor8... You here tor8? | 20:32.48 |
| | I just happened to run a memento build of ghostscript, and it's dying early on. | 20:33.54 |
| | In context_state_alloc in gs/psi/icontext.c | 20:34.04 |
| tor8 | hmm | 20:34.06 |
| Robin_Watts | at line 160, it's looking up 'puserparams' and getting back a pointer to something of type null. | 20:34.44 |
| | At line 161 we then do size = dct_length(puserparams) (i.e. we treat the null as a dict) and we get a crash. | 20:35.12 |
| | Should we be checking the type of puserparams before we use it ? | 20:35.30 |
| tor8 | Robin_Watts: are you asking me about psi internals? | 20:35.55 |
| | or alexcher | 20:36.00 |
| Robin_Watts | I'm asking anyone. | 20:36.09 |
| | But you, as you're here, and you wrote the code, would seem a reasonable person :) | 20:36.24 |
| tor8 | you sure you ran git blame with the ignore-whitespace option? | 20:36.51 |
| Robin_Watts | ahem. | 20:37.05 |
| | OK, so it's henrys, back in 1998. | 20:39.56 |
| | So... what has changed to make this fail now ? | 20:40.08 |
| | And now, after much checkout and rebuilding... it's working :( | 21:09.59 |
| | mvrhel: ping | 21:49.55 |
| | I'm giving up for the night. | 21:50.08 |
| | The WMB1102317A01.pdf issue is still outstanding. | 21:50.27 |
| | If you have any time to look at that (does your wifi reach your bathroom? :) ) or any more thoughts about it, that would be great. | 21:51.43 |
| | I hope you feel better soon. | 21:51.49 |
| ray_webchat | Robin_Watts: I noticed that you wanted to be able to set a b.p. when a certain return code was returned. If the C code follows the rules, it uses the return_error macro which (in a debug build) will call gs_log_error in gsmisc.c | 22:59.11 |
| | If you make the b.p. conditional on 'err == ____' then you can ignore the noise. | 22:59.37 |
| | The hospital only allows http ports -- I'm sure glad webchat works. Even email ports don't work -- have to resort to gmail web :-( | 23:02.04 |
| | Forward 1 day (to 2012/02/16)>>> | |
IRC Logs