| | <<<Back 1 day (to 2011/07/27) | 2011/07/28 |
| JakeyChan | hi, | 03:52.27 |
| | ghostscript can add TOC from bookmark ? | 03:52.45 |
| | I want to make sure quickly :) | 03:53.00 |
| pasigydziau | Good day. I'm printing to ps file and then trying to convert it to png images with ghostscript. And i found page orientation problem. For example: when i print ppt slides, they should be landscape instead of portrait. | 09:44.47 |
| | Does ps file contain information about orientation? | 09:45.08 |
| | Can ghostscript automaticly rotate needed direction? | 09:45.23 |
| | I know that, pdfwriter got -dAutoRotatePages=/All | 09:46.27 |
| | but for png it doens't work | 09:46.37 |
| | you could set orientation manualy, -c "<</Orientation 3>> setpagedevice" | 09:47.04 |
| | But it still manualy, i need automatic | 09:47.12 |
| Robin_Watts | Try -dLeadingEdge= values can range from 0 to 3 if memory serves. | 09:51.19 |
| | one of them may do what you want. | 09:51.25 |
| pasigydziau | that doesn't helped | 10:05.57 |
| | intresting is that, i can find comments like: %%Orientation: Landscape in *.ps file. So what should be possible somehow to use needed orientation | 10:07.34 |
| chrisl | pasigydziau: Ghostscript can only do what it's told - if the file, or command line, doesn't set the page orientation, we'll use the default. I don't think GS (normally?) act on DSC comments. | 10:11.43 |
| pasigydziau | ok. I can write parser to extract DSC comments and then use that as switches on gs command, but maybe there is easier way? | 10:15.18 |
| chrisl | pasigydziau: well, I would say the "right" way would be for the PS file to include a setpagedevice which sets the pagesize correctly. | 10:16.09 |
| | pasigydziau: I don't know if/how you might be able to have Ghostscript do all the DSC stuff for you, but you shouldn't need to write a full parser, if you look at section 7 in Language.htm, it covers how to let GS do most of the work. | 10:21.14 |
| pasigydziau | ok, thanks for info. I will try to figure out how does it work, cause i new to ghostscript stuff | 10:24.29 |
| chrisl | pasigydziau: the person who can probably help the most is alexcher but he's in the US, so probably won't be around for a few hours yet. | 10:27.08 |
| pasigydziau | ok. | 10:29.52 |
| veleno | hello everyone | 10:35.59 |
| | anyone familiar with this error ? http://pastie.org/2279641 | 10:36.08 |
| | i googled for it, and apart from some discussion on a mailing-list, i could find an answer about whether the bug was fixed or not. | 10:36.42 |
| chrisl | veleno: yes, that should have been fixed in the not yet released code. | 10:38.11 |
| | veleno: should be fixed by: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=10cd4a | 10:38.47 |
| veleno | mmm when is it going to be released ? i usually get my gs from the MacTex distribution | 10:40.15 |
| | or maybe from port | 10:40.34 |
| chrisl | veleno: we have a scheduled release coming up in the next couple of weeks. | 10:40.50 |
| veleno | ok thanks | 10:43.58 |
| Robin_Watts | joy. lcms v1 doesn't seem to believe in checking to see if allocations worked before using them. | 11:56.48 |
| | This code really is quite amazingly broken. | 12:51.35 |
| | I have no idea how we've ever done stable releases based on it. | 12:51.52 |
| chrisl | Robin_Watts: is lcms2 any better? | 12:55.09 |
| Robin_Watts | Well, it's broken on at least some files that lcms1 works with. | 12:55.29 |
| | I haven't looked to see if the memory checking issues are sorted. | 12:55.48 |
| | In general lots of functions return bools to say whether they worked or not, but very few of them are checked. | 12:56.06 |
| chrisl | It's not a great endorsement, kind of feel the quality of the code should have been reviewed before we adopted it. | 12:56.33 |
| Robin_Watts | indeed. | 12:58.49 |
| | And sometimes 0 means "OK", sometimes 1 means "OK". | 12:59.08 |
| | ffs. | 12:59.10 |
| chrisl | Yeh, some people seem to think it's clever to switch the conventional zero == "OK" when it's a function that'll be called often from a conditional - I just think it's confusing . | 13:03.18 |
| Robin_Watts | I think I'm of the opinion that we should fork lcms, and cure it. | 13:08.30 |
| | and then offer the patches back to Marti. It's not TOO huge a job to fix (a man week, say) | 13:09.34 |
| | but the patches will be horrendous. | 13:09.39 |
| | because the code is full of inconsistent indentation, trailing spaces etc. | 13:09.55 |
| chrisl | I think it's only fair we offer the patches to Marti before we fork - I'd really prefer to avoid that.# | 13:10.18 |
| Robin_Watts | By the time we've made all the changes we'll need to make, it'll be really hard for him to take it back unless he accepts it wholesale. | 13:10.32 |
| chrisl | The easiest thing, in that case, would be for him to setup a git repos so that whoever does the work at our end could easily push changes back via git. | 13:11.45 |
| Robin_Watts | We'll need to discuss this with henrys and co. | 13:16.02 |
| chrisl | Yep, it's not a decision to take lightly, I feel. I wonder if we could contract Marti to do the work? | 13:16.46 |
| Robin_Watts | Given that he wrote the code this badly in the first place, do we trust him to tidy it up? | 13:17.33 |
| chrisl | Good point....... | 13:17.54 |
| Robin_Watts | I get the feeling that he wrote lcms to be "good enough" for what he wanted. | 13:18.15 |
| chrisl | Often the case for open source projects | 13:18.39 |
| Robin_Watts | it bears all the hallmarks of non-production code (it works, but doesn't cope with exceptional conditions). | 13:18.45 |
| | lunchtime. | 13:31.26 |
| alexcher | pasigydziau: I need a PS file to to tell you why it doesn't work as espected. | 13:47.47 |
| chrisl | alexcher: do we parse and act on DSC page size and orientation comments normally? | 13:49.41 |
| alexcher | chrisl: We do, but setpagedevice has the priority. | 13:52.04 |
| chrisl | alexcher: Ah, okay, thanks. I had it in my mind we only automatically used DSC comments when running to PS or PDF /output/ (that's probably Jaws that's like that!). | 13:53.19 |
| pasigydziau | chris1, i just copied a little from beginning and end http://pastebin.com/kqqNH3yQ | 14:01.38 |
| | is it enough for you? | 14:01.46 |
| | or should i upload ps as file? | 14:04.43 |
| alexcher | pasigydziau: I need the whole file. | 14:06.50 |
| pasigydziau | http://ma-fi.lt/convert.ps | 14:09.37 |
| chrisl | Robin_Watts: Could you read over the section on the Windows UNICODE stuff, and rewrite it as you see fit: http://www.ghostscript.com/~chrisl/News.htm ? | 14:38.02 |
| Robin_Watts | looking now | 14:38.49 |
| | "Downscaling is also now support*ed*" | 14:39.28 |
| | "and a new pngmonod device *has been implemented*" | 14:39.54 |
| | "then downscale*s*/min_feature_size*s*/error diffuse*s*" | 14:40.36 |
| | bevahiour | 14:40.52 |
| alexcher | pasigydziau: First, your file is rotated perfectly by pdfwrite auto-rotation feature. | 14:43.18 |
| | Second, the file is not dsc-conforming. it has a header that precedes DSC comments. | 14:44.10 |
| | However, a file with a fixed DSC header still doesn't work as espected. | 14:46.05 |
| | For now use the following command line: | 14:46.59 |
| | gs -dAutoRotatePages=/None -sDEVICE=pdfwrite -o dsc.pdf -c '<</Orientation 3>>setpagedevice -f FILE.PS | 14:47.26 |
| | gs -dAutoRotatePages=/None -sDEVICE=pdfwrite -o dsc.pdf -c '<</Orientation 3>>setpagedevice' -f FILE.PS | 14:47.54 |
| henrys | yea marti should be contacted first, do you want me to do it? | 15:06.59 |
| ray_laptop | chrisl: I noticed that you gave some incorrect info to pasigydziau earlier. There _is_ a DSC parser in GS, and we use it when converting to PDF to set the orientation, but as alexcher determined, it isn't working as expected with the test file | 15:09.20 |
| chrisl | ray_laptop: yeh, I checked with alexcher, he set me straight on it. | 15:10.20 |
| Robin_Watts | henrys: I'd be happy to draft something, but I would feel happier to run it past people before sending it out. | 15:10.36 |
| ray_laptop | Since the other devices _don't_ pay attention to the DSC comments, however, pasigydziau would need to make a PDF first. | 15:10.48 |
| henrys | Robin_Watts:okay | 15:11.05 |
| ray_laptop | chrisl: I missed that, but did see alexcher commenting on the pdfwrite later. | 15:11.33 |
| chrisl | ray_laptop: well, I did say that GS doesn't /normally/ act on DSC comments - I tend to consider "normal" to be output to a raster format. | 15:13.08 |
| ray_laptop | alexcher: did you try pdfwrite without the -c '<</Orientation 3>>setpagedevice ?? I didn't check the code, but the times I've used it I just set AutoRotatePages=/None and it worked. | 15:13.09 |
| | chrisl: true. 'normal' is subject to assumption. | 15:13.53 |
| henrys | so I guess everybody read sags view - Now I am of the view we should do uft-8 and tell windows user to be less "windowsy" | 15:14.25 |
| ray_laptop | it isn't too hard to add a ProcessDSCComment procedure | 15:14.58 |
| Robin_Watts | henrys: I haven't read sags report yet. | 15:15.00 |
| | But I still think we should ship with it disabled, with a note announcing our intention to change for next time. | 15:15.31 |
| ray_laptop | henrys: me neither. Will do now. But I still think that we should start telling them now, and make a non-backward compatible change later | 15:15.40 |
| Robin_Watts | At the very least, that covers our asses, because if they don't complain until we change it, and it then causes problems, it's their fault for not having read/responded to the release notes. | 15:16.11 |
| henrys | sounds good to me, but check out sags stuff too. | 15:17.00 |
| Robin_Watts | I will do. | 15:17.18 |
| alexcher | ray_laptop: AutoRotatePages works perfectly for this file but the user doesn't want to depend on it. | 15:17.19 |
| chrisl | Surely, what sags is talking about will only work when the system's codepage is compatible with extended ASCII - is that always true? | 15:18.04 |
| ray_laptop | I think there is a typo in sags' write up. He says " The no-suffix names are kept for backward compatibility, and are aliases for he ANSII entry points." but then has: | 15:22.06 |
| | - Keep unchanged: | 15:22.08 |
| | int gsapi_run_file (..., const char *file_name/*utf8*/, ...); | 15:22.10 |
| | I like the first concept which is at odds with the pseudo prototype. | 15:23.02 |
| | but then later he goes on to say " the no-prefix externally visible symbol links to the ANSII functions on Windows and to the utf8 one on all other platforms." which seems OK | 15:24.45 |
| | so with sags' proposal, we end up adding UTF-8 for windows clients to migrate toward but don't have to change anything now. | 15:27.33 |
| chrisl | And we end up committed to maintaining two APIs forevermore........ | 15:27.59 |
| henrys | chrisl:that's where I lost interest | 15:28.21 |
| ray_laptop | chrisl: I think that what Windows expects in file paths is whatever codepage is set for 'native' on that installation. | 15:28.51 |
| chrisl | How about making whether to treat parameters as UTF8 or ASCII optional, with a setting in the context? | 15:29.48 |
| ray_laptop | henrys: chrisl: as to maintaining indefinitely -- we don't have to. This can be documented as a 'bridge' to allow Windows clients to switch to UTF-8 | 15:29.49 |
| | chrisl: I like the 'dynamic' idea as well and hadn't typed that yet. | 15:30.24 |
| chrisl | I think that would suit everyone: it can be initialised to ASCII, so default won't change, and those that need UNICODE path capabilities can enable it, and make appropriate code changes. | 15:31.23 |
| ray_laptop | btw, I _don't_ see any reason we should have the 16 variant. Then we _would_ be creating a new variant with no useful purpose if we are going to drop it | 15:31.29 |
| | the whole "wide char" cr*p of Windows is misguided IMHO (they should have just gone to UTF-8) | 15:32.11 |
| henrys | I am reading some windows programs use a "byte order mark"... that's all we need ;-) | 15:32.42 |
| chrisl | ray_laptop: the thing is, if we add new API calls, however we document it, we'll never get rid of it - just look at the device procs list! | 15:33.10 |
| ray_laptop | chrisl: actually we _could_ go ahead an prune the device procs, IMHO. We just haven't done it. As long as all of the 'contrib' devices still work, any third party drivers are "too bad" | 15:34.26 |
| | chrisl: since they are rare (compared to the number of Windows clients outside the US) | 15:34.57 |
| Robin_Watts | chrisl: http://ghostscript.com/~robin/UnicodeNode.txt | 15:35.39 |
| ray_laptop | chrisl: I'm sure that if we say we are going to remove it next release, then henrys or you will see to it | 15:35.45 |
| | Robin_Watts: 404 | 15:36.01 |
| chrisl | Robin_Watts: can't read it | 15:36.03 |
| henrys | I am very much in favor of our original course. | 15:36.04 |
| Robin_Watts | chrisl: http://ghostscript.com/~robin/UnicodeNote.txt | 15:36.15 |
| henrys | what we agreed to yesterday. | 15:36.22 |
| ray_laptop | Robin_Watts: OK, but I think mentioning some Western European characaters that are in the "Extended ASCII" range early would be good to sensitize readers as to why this is at issue. | 15:39.37 |
| henrys | yes we need what will go wrong | 15:41.03 |
| ray_laptop | Robin_Watts: also, your note doesn't explain what "other" clients will need to do (those that call gsapi_ functions) | 15:41.25 |
| Robin_Watts | ray_laptop: Eh? | 15:41.48 |
| | The last but one paragraph ? | 15:41.58 |
| ray_laptop | Robin_Watts: I think we need to be more helpful than "will need to add a utf8 encoding stage" | 15:42.44 |
| chrisl | ray_laptop, Robin_Watts we can't realistically squeeze more into the News.htm "release highlights" section - It's already rather longer than I'd like :-( | 15:43.00 |
| Robin_Watts | ray_laptop: I'm trying to be clear about exactly who is affected, without getting down to the detail of actually writing code for them :) | 15:43.38 |
| ray_laptop | Robin_Watts: I don't think this all needs to go into the News.htm, but rather move most of it into a separate doc. | 15:43.50 |
| Robin_Watts | ray_laptop: Fine. Then is the section above "More Details:" clear enough ? | 15:44.29 |
| ray_laptop | Robin_Watts: for our customers, if we want them to convert, we probably will end up writing the code anyway, so we might as well put out the help npw. | 15:44.31 |
| | I don't think the part about unilaterally extending PS needs to be in the News.htm -- it's more of a detail | 15:45.57 |
| chrisl | ray_laptop: I disagree, we get a *lot* of people asking "how do I do UNICODE in Postscript", I think we need to be very clear that's *not* what this is doing. | 15:46.39 |
| henrys | I'd rather just put the entire thing in and warn people there is a treatise below that can be skipped. | 15:46.41 |
| chrisl | henrys, ray_laptop, mvrhel2, alexcher: can you look at the following, and tell if there's any other new stuff you want mentioned: http://www.ghostscript.com/~chrisl/News.htm ? | 15:47.49 |
| ray_laptop | also, we had discussed distributing gs904w??_unicode.exe to make it easier for customers to begin using without rebuilding. Customers that use our front-end will be able to try the _unicode variant and make sure it works as expected | 15:47.57 |
| Robin_Watts | New version. | 15:48.13 |
| henrys | chrisl:will do. | 15:48.45 |
| Robin_Watts | chrisl: I pointed out some minor tweaks to that above. | 15:49.28 |
| ray_laptop | while we have a number of customers (and GSView users) that use the gsapi_ calls, we have another group that uses our pre-built parts including the gswin32 | 15:49.36 |
| | chrisl: I'll have a look today. | 15:49.48 |
| chrisl | Robin_Watts: I got them locally, I just didn't upload a fresh copy, thanks | 15:50.09 |
| Robin_Watts | ah, ok. | 15:50.17 |
| chrisl | henrys: as you can probably guess, we're not getting a release candidate today..... | 15:50.28 |
| Robin_Watts | mvrhel2: henrys: alexcher: (and anyone else interested)... can we talk about the shading bug for a bit ? | 15:50.53 |
| henrys | yes first off I don't think we should block on the shading bug. | 15:51.27 |
| Robin_Watts | henrys: Phew! | 15:51.39 |
| chrisl | Which bug is that? | 15:51.42 |
| ray_laptop | chrisl: I forgot to mention, that you can try the script out before there is a ghostscript-9.04 tag using: git archive origin/gs904 | tar -x --file=- -Cghostpdl-9.04 | 15:51.53 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=692352 | 15:51.54 |
| ray_laptop | chrisl: then run the script. If ghostpdl-9.04 already exists, it assumes it is populated. | 15:51.55 |
| | I think we need to fix the crash that we are seeing from lcms !!! | 15:52.54 |
| Robin_Watts | Firstly, lcms sucks hugely at coping with failed allocations. | 15:53.01 |
| chrisl | ray_laptop: yes, that was my plan - although I was hoping to push out a release candidate before I had time to test it. | 15:53.10 |
| henrys | ray_laptop:there are hundreds of potential problems with lcms because it ignores return frequently we can't fix them all before the release. | 15:53.44 |
| Robin_Watts | Lots of places it assumes allocations succeed. Where it does bother to check, it often returns a 'failed' value to the code above that doesn't bother to check for the failed value etc. | 15:53.48 |
| | I have fixed that in many places today. | 15:54.05 |
| | (locally) | 15:54.13 |
| henrys | when was lcms added? | 15:54.27 |
| Robin_Watts | but a more thorough survey would seem to be in order. | 15:54.29 |
| henrys | 9.0? | 15:54.30 |
| ray_laptop | well, it's UGLY but can we do a test allocation of a fairly large amount of RAM before calling lcms ? | 15:54.33 |
| Robin_Watts | yes. | 15:54.34 |
| | The next problem is that we then make exactly the same mistake :) | 15:54.58 |
| | In the shading setup code, we don't cope with the icclink failing to be made due to memory shortage. | 15:55.24 |
| | And again, I have a fix for that locally. | 15:55.32 |
| ray_laptop | what I mention is like the gsmalloc.c "heap_available" hack. | 15:55.52 |
| Robin_Watts | ray_laptop: Yes, I understand. it sounds really nasty, and I'd rather not, but... | 15:56.40 |
| ray_laptop | but until we can clean up lcms (or lcms2) | 15:56.56 |
| Robin_Watts | We create an icclink on every shaded rectangle, then destroy it again. | 15:57.20 |
| | so it's clearly not that that's causing the memory bloat. | 15:57.36 |
| ray_laptop | what ? what about our icc_link_cache ? | 15:57.54 |
| | surely every shading is not a new colorspace | 15:58.18 |
| chrisl | Robin_Watts: does the icclink actually get freed each time? | 15:58.25 |
| Robin_Watts | The ref count of the icclink goes to zero | 15:58.34 |
| ray_laptop | and the link cache is in non-gc memory (iirc). mvrhel2 ?? | 15:58.38 |
| Robin_Watts | and it gets put into the icc_link_cache. | 15:58.47 |
| | but I think I know what causes the bloat. | 15:58.56 |
| | The .buildshadingX operators are called from the pdf interpreter. | 15:59.27 |
| ray_laptop | Robin_Watts: but going to zero is not supposed to free it until we need the space in the cache (it's not the usual rc methods) | 15:59.28 |
| Robin_Watts | ray_laptop: Right, but I don't see the link cache getting bigger and bigger etc. | 15:59.53 |
| henrys | Robin_Watts:what were you saying is causing the bloat? | 16:00.21 |
| ray_laptop | Robin_Watts: well, it wouldn't be getting bigger and bigger if we were freeing a link every time, it would just kill performance | 16:00.28 |
| Robin_Watts | I think the buildshading operators construct a postscript garbage collectable object with stuff in it. | 16:00.32 |
| ray_laptop | alexcher wrote up what caused the bloat | 16:00.45 |
| Robin_Watts | that gets used when we come to render the shading. | 16:00.56 |
| | but it's never freed until the next garbage collection. | 16:01.05 |
| | Alex had a way of improving the situation by wrapping the building/use of the thing in a save/restore, which somehow causes the objects to be reclaimed. | 16:01.54 |
| | BUT... that triggered SEGVs elsewhere. | 16:02.06 |
| ray_laptop | alexcher has one comment that concerned me: "Apparently, the memory allocated by .buildshading cannot be reclaimed by GC." | 16:02.08 |
| marcosw | the weekly regression that ran today was the UFST one, and every command produced an error: "Unrecoverable error: rangecheck in readline". I'll go ahead and open a bug, but was wondering if this meant anything to anyone? | 16:02.42 |
| Robin_Watts | Right. So what I was getting to, was that I think we need to look at the memory use by buildshading. The lcms stuff is actually just a canary that's keeling over as memory gets short. | 16:03.16 |
| ray_laptop | note that I am not proposing changing the way shading is done for 9.04, but just fixing the ICC related crash(es) when we run out of memory | 16:03.26 |
| chrisl | marcosw: it doesn't sound like an error I would expect from a faulty UFST build - but I'll look into it when I have time. | 16:03.50 |
| Robin_Watts | ray_laptop: Well, I have fixes locally that allow the file to complete (with a warning saying it ran out of memory and may be incomplete). | 16:04.41 |
| | i.e. we don't keel over and die any more. | 16:05.06 |
| ray_laptop | Robin_Watts: any reason not to go ahead and commit those ? | 16:05.08 |
| | then chrisl can cherry-pick it into 904 | 16:05.23 |
| Robin_Watts | No, I don't think so. | 16:05.26 |
| | I need to run tests etc. | 16:05.35 |
| marcosw | chrisl: okay, I'll assign the bug to you when I've opened it. I'm still using an old UFST command line, where I'm setting -sFCOfontfile, -sUFST_PlugIn, and -sFAPIfontmap. | 16:05.45 |
| ray_laptop | Robin_Watts: sounds good. | 16:05.54 |
| Robin_Watts | but I think we should look at putting alexchers extra save/restore in and try and fix the SEGVs that cause. | 16:06.06 |
| | cos that's the real cure. | 16:06.10 |
| henrys | alexcher:if gc was working would the save restore be necessary? | 16:06.49 |
| chrisl | marcosw: I haven't tried it with the extensive command line for some time. | 16:06.52 |
| ray_laptop | Robin_Watts: I agree that alexcher's approach sounds good, and following through to fix it makes sense -- just not a gating item for 904 | 16:07.20 |
| marcosw | chrisl: should the the long command line still work? If not it's presumably not a bug. | 16:07.40 |
| ray_laptop | henrys: save / restore is much more efficient than GC | 16:07.46 |
| marcosw | henrys: can we cancel the support meeting or postpone it until tomorrow? I need to run to school for a meeting. | 16:08.22 |
| ray_laptop | votes for canceling | 16:08.39 |
| chrisl | marcosw: yes, it should still work - we still need it for COMPILE_INITS=0 | 16:08.44 |
| henrys | yes cancel is fine - marcosw I've sent you mail about testing stuff that is fairly important we wanted to get 9.04 through the weekly. | 16:09.51 |
| marcosw | henrys: I'll have time to work on that tomorrow and over the weekend. | 16:10.50 |
| henrys | ray_laptop:every other pdf interpreter seems to process this job fine without the benefits of save/restore why is it necessary to introduce the postscript object bloat in the first place? | 16:12.19 |
| | not just to ray_laptop | 16:12.57 |
| chrisl | How many other PDF interpreters do you know of written in Postscript? | 16:13.27 |
| henrys | 0 | 16:13.39 |
| | the question is why can't this be coded more in C and less in postscript | 16:13.59 |
| chrisl | I suspect that may be a contributing factor, then! | 16:13.59 |
| ray_laptop | alexcher: I noticed in your patch for '352 you still do a gsave / grestore -- we don't need this, right ? | 16:14.28 |
| | alexcher: since restore does an implicit grestoreall | 16:14.55 |
| chrisl | henrys: I guess the problem would be making sure that *everything* got cleaned up after the shading without the aid of GC | 16:15.46 |
| henrys | what about alexcher's last paragraph comment #5 does that still require the save/restore? alexcher? | 16:18.10 |
| ray_laptop | henrys: the problem is that the '.buildshading' and '.shfill' are in separate PS operators, so the C code would have to create the save state in the .buildshading and then somehow pass it to the .shfill | 16:18.18 |
| Robin_Watts | ray_laptop: Do we call one .buildshading, and then multiple .shfills ? | 16:19.05 |
| ray_laptop | henrys: alexcher: I didn't understand the relevance of alex's comment "Smooth shading has to copy shading data to a reusable stream." since he next said that it dosen't cause bloat | 16:19.47 |
| Robin_Watts | ray_laptop: I read that as "I've checked this bit of it, and it's not this that's causing problems." | 16:20.11 |
| henrys | ray_laptop:it just seems to me save/restore is a pretty heavy operation to throw in for the usualy shading cases. This file is pathological. | 16:20.32 |
| ray_laptop | Robin_Watts: there are many 'buildshading' variants, so it's in lots of places in C | 16:20.32 |
| Robin_Watts | ray_laptop: Right. | 16:20.43 |
| | But is there a reason why the 'build shading' stage is separate from the 'fill shading' ? | 16:21.00 |
| | If we have a strict 1:1 use of buildshading with fillshading, then we might as well have a 'buildandfillshading' which would avoid us needing to make the ps operator. | 16:21.51 |
| | s/operator/object/ | 16:22.00 |
| ray_laptop | Robin_Watts: yes. They are not 1:1 in PS | 16:22.39 |
| mvrhel2 | chrisl: there is a bunch of color stuff that I need to get into the news for 9.04 | 16:22.58 |
| ray_laptop | and, iirc, a pattern type 2 shading actually persists and can be used for many fill operations | 16:23.33 |
| chrisl | mvrhel2: okay, well, I'm really hoping to get a release candidate out tomorrow, so.........] | 16:23.44 |
| ray_laptop | Robin_Watts: or even painting text, etc. | 16:23.56 |
| | Robin_Watts: this will become moot once we can move to mupdf's PDF parser. | 16:26.48 |
| henrys | yes this adventure is raising the priority of that project. | 16:27.49 |
| mvrhel2 | chrisl: I will get the new material out to you to add today | 16:28.00 |
| ray_laptop | then we can address the real reason that the shading can't clean up its memory properly. | 16:28.18 |
| Robin_Watts | Well, I've pushed the changes that should make the bug complete. | 16:28.22 |
| chrisl | mvrhel2: thanks - you're lucky, I was supposed to do the release candidate today....... | 16:28.29 |
| Robin_Watts | now I'll add the SAVE/RESTORE stuff from alexcher and look at the SEGVs. | 16:28.41 |
| ray_laptop | chrisl: you could do a release candidate and still update News.htm with feedback tomorrow, right ? | 16:29.20 |
| henrys | Robin_Watts:sounds like a plan I wish alexcher were here to discuss the last sentence in comment #5 | 16:30.22 |
| chrisl | ray_laptop: I'm not doing putting together a release candidate now, it's too late in my day - but I don't have a problem pulling in doc changes after an rc, no. | 16:30.26 |
| ray_laptop | chrisl: fine. I'll have any 'News' comments to you before you start in your AM | 16:31.01 |
| chrisl | ray_laptop: see, I can't even type English intelligibly right now! | 16:31.37 |
| Robin_Watts | I'm happy with my unicode note, as is. If anyone else wants to see more changes to it, have at it :) | 16:33.40 |
| chrisl | Robin_Watts: are those the two commits you want pulled into 9.04 (393685f and 4f2d3c7) or are there more to come? | 17:01.59 |
| Robin_Watts | chrisl: Those two are all I have so far. | 17:02.14 |
| chrisl | Are you expecting more to go in? | 17:02.28 |
| Robin_Watts | Only if I can find a cure for these SEGVs. | 17:02.43 |
| | not that I can currently reproduce the SEGVs.... | 17:02.56 |
| henrys | have you used -Z? to check allocations? | 17:04.12 |
| Robin_Watts | nope. | 17:04.27 |
| henrys | of course you need a debug build. | 17:05.39 |
| ray_laptop | I usually use -Z@$? ( -Z@\$\? on shell) | 17:10.20 |
| Robin_Watts | I'm not getting SEGVs, but it's never completing. | 17:13.44 |
| henrys | looks like kens is manning the stackoverflow post. | 17:14.29 |
| alexcher | I'm back from lunch. | 17:16.55 |
| Robin_Watts | ok. Enabling the halftoning stuff (which I'd done by mistake) makes it MUCH slower. | 17:18.23 |
| | Now memento is reporting memory corruption nicely. | 17:18.34 |
| alexcher | henrys: My comment means: smooth shading code copies the data to a reusable stream but it is OK. The bug is somewhere else. | 17:21.14 |
| tkamppeter | chrisl, there is also b3dbb094 (bug 692368), but did that need a review by marcosw or so? | 17:36.56 |
| chrisl | tkamppeter: I believe that is already in gs904 - just me double check | 17:38.14 |
| | tkamppeter: yes, that's already on the gs904 branch. | 17:39.22 |
| Robin_Watts | So, with the following command: gs/debugbin/gswin32c.exe -dMaxBitmap=100000000 -P -r72 -sDEVICE=pkmraw -o new.pkm ../ghostpcl/tests_private/comparefiles/Bug689189.pdf | 18:02.24 |
| | block 153212 is allocated by alloc_save_space at line 425 | 18:02.58 |
| | That's then freed at 153222 by restore_free doing funky things with the chunk allocator (pulling the ripcord?) | 18:07.56 |
| | Later on (@155752) we do a VMreclaim, and during the ref marking phase, that writes into that freed block. | 18:08.43 |
| Robin_Watts | walks dogs. | 18:13.47 |
| tkamppeter | chrisl_away, thanks. | 19:13.49 |
| | Robin_Watts, mvrhel2, henrys, launch-leaflet and CityMap with cups output device and -dcupsColorSpace=17 have colors completely off. | 19:36.00 |
| henrys | rgbw? when did that break? | 19:42.08 |
| | and what devices are using rgbw? seems like I asked that before. | 19:45.19 |
| mvrhel2 | ugh | 19:45.49 |
| | is this related to bug 691922 | 19:46.35 |
| | is this a new issue? | 19:46.38 |
| | tkamppeter: I have to head out in a bit for this afternoon. if you could do git bisect to find when things changed that would be helpful. I can work on it tonight | 19:48.01 |
| | henrys: I have to help out with cub scout camp this afternoon | 19:48.16 |
| tkamppeter | henrys, it affects most HP inkjets, used with HPLIP. | 19:48.41 |
| henrys | okay | 19:48.45 |
| tkamppeter | henrys, it works correctly on Natty and is broken on Oneiric. | 19:49.31 |
| henrys | if you have time to bisect it that would help mvrhel2 a lot. | 19:50.05 |
| tkamppeter | henrys, Natty comes with GS 9.01 and Oneiric has the 9.04 snapshot of July 15. | 19:50.10 |
| henrys | oh well that's encouraging not too far apart. | 19:50.36 |
| tkamppeter | henrys, I have never bisected. I know what it means but I have never done it. | 19:52.04 |
| henrys | everyone should do git bisect at least once:http://kernel.org/pub/software/scm/git/docs/git-bisect.html | 19:52.58 |
| | but if you want to just report a bug go ahead and one of us will look. | 19:53.12 |
| | git checkout master; git bisect bad; git checkout ghostscript-9.01; git bisect good -- something like that to get you going. | 19:54.42 |
| | you need a git bisect start in there somewhere ... | 19:56.00 |
| tkamppeter | mvrhel2, henrys, looks like it is actually bug 691922. How far are your investigations on this bug? | 19:58.02 |
| | henrys, problem is that the poster of that bug only compared to 8.71 where the problem also did not occur. | 20:01.30 |
| mvrhel2 | tkamppeter: I need to review this tonight | 20:01.46 |
| | I need to understand the purpose of the W plane | 20:02.00 |
| | and how it was encoded properly n 8.71 and now is suddenly not | 20:02.15 |
| | iirc this had something to do with keeping track of text regions or something like that | 20:02.36 |
| | I have no idea how that could have been done in 8.71 | 20:02.46 |
| | it really is going to be up to the gdevcups.c to properly endcode the data | 20:03.01 |
| | need to head out now | 20:03.10 |
| tkamppeter | mvrhel2, one hint: The W plane has only two states: binary 0 means this is black text, ignore the RGB values and print this with a pixel of black ink, binary 1111... means, take the RGB values as they are. | 20:04.24 |
| | mvrhel2, see comment 23 (last paragraph) and comment 26 in http://bugs.ghostscript.com/show_bug.cgi?id=691922. | 20:06.46 |
| henrys | tkamppeter:I don't quite see how HPLIP uses cups for this, doesn't the driver hpijs generate the printer input? | 20:37.50 |
| tkamppeter | henrys, formerly, it was hpijs, now it is hpcups, a CUPS Raster driver. | 20:40.26 |
| Robin_Watts | I'm running up against the limits of my knowledge of the internal structure of the pdf engine here. | 21:01.29 |
| | henrys: got time to talk about this ? | 21:01.36 |
| tkamppeter | I am currently looking for incorrect handling of RGBW in gdevcups.c ... | 21:12.24 |
| | But note that these problems can be there already for long time. AFAIR I did not modify color handling in gdevcups.c. | 21:13.25 |
| mvrhel2 | tkamppeter: does it render wrong for all objects | 21:23.34 |
| | ? | 21:23.35 |
| | i.e. look at text_graphic_image.pdf in ./gs/examples | 21:24.02 |
| | and text_graph_image_cmyk_rgb.pdf | 21:24.12 |
| | If you can run these and post the results on the bug for me, I will take a look tonight | 21:24.40 |
| | have to run now | 21:24.56 |
| henrys | hi Robin_Watts I'm back | 21:37.13 |
| Robin_Watts | I can see that we allocate a bunch of refs as part of a dictionary. | 21:37.57 |
| malc_ | Robin_Watts: hi, around? | 21:38.07 |
| Robin_Watts | malc_: yes | 21:38.20 |
| | henrys: In dict_create_contents | 21:38.29 |
| | Line 196 of idict.c | 21:38.48 |
| malc_ | Robin_Watts: cbf50e333dc1e80cd968c5ee931b4d6886b116a4 made UnicodeStandard-6.0.pdf non openable | 21:38.48 |
| henrys | Robin_Watts:if it is not a graphics library problem it can probably just go back to alexcher, I was hoping it was the shading algorithm. | 21:38.54 |
| | but if you want to keep going I'll try to help | 21:39.14 |
| Robin_Watts | Then a bit later, the chunk that's in gets freed. | 21:39.20 |
| | Then a VMreclaim done a bit later even than that causes those refs to be marked, which of course involves writes to undefined memory. | 21:39.50 |
| | I kinda feel I ought to be able to see at least what the contents of the dictionary are, but I can't make head or tail of it in the debugger. | 21:40.24 |
| | malc_: Is that mupdf or ghostscript ? | 21:40.36 |
| malc_ | Robin_Watts: mupdf | 21:40.41 |
| | Robin_Watts: tor once mentioned that this is a pdf with an empty password or something to that effect | 21:41.09 |
| henrys | p debug_print_full_ref() | 21:41.53 |
| | ? | 21:41.54 |
| malc_ | i see nothing else in the logs that would have broken it but the aforementioned commit, but i haven't verified.. (this is slow machine, and i tend to not recompile stuff unless absolutelly necessary, sorry about that) | 21:41.57 |
| Robin_Watts | malc_: Can you open a bug, attach the file, and make a note in the bug that it might be that change? | 21:42.40 |
| | Point the bug at me, and I'll take a look tomorrow. | 21:42.53 |
| henrys | or debug_dump_refs() whole bunch of code in idebug.c for dumping stuff. | 21:43.23 |
| Robin_Watts | henrys: looking. | 21:43.53 |
| henrys | do you have a simple file? | 21:44.47 |
| Robin_Watts | henrys: No. | 21:45.02 |
| malc_ | Robin_Watts: i definitely won't attach 12M file, but opening a bug sure | 21:45.52 |
| Robin_Watts | malc_: As long as you can point me at a copy of the file, that's fine. | 21:46.11 |
| henrys | Robin_Watts:are you using the "simpler file" or the first one want to see it as you do. | 21:47.41 |
| Robin_Watts | The full one, plus alexchers patch. | 21:47.59 |
| | henrys: Actually, I'm wilting rapidly and I've got to go fetch Helen from the station in a bit. | 21:50.11 |
| | I might just call it a night and pass it back to Alex. | 21:50.19 |
| | I'll put a note on the bug describing what I found. | 21:50.35 |
| malc_ | Robin_Watts: filed, but it didn't let me assign anyone.. so it's asigned to Tor, you might want to change that: http://bugs.ghostscript.com/show_bug.cgi?id=692382 | 21:50.52 |
| Robin_Watts | malc_ perfect, thanks. | 21:51.24 |
| henrys | Robin_Watts okay I'll fool with it a bit and we can talk tomorrow | 21:51.45 |
| | but alexcher's fix fixes the problem and crashes in other regresion file right? | 22:00.17 |
| Robin_Watts | oh, sorry. being dim. | 22:00.29 |
| | The file I get crashes with is: | 22:00.39 |
| | gs/debugbin/gswin32c.exe -dMaxBitmap=100000000 -P -r72 -sDEVICE=pkmraw -o new.pkm ../ghostpcl/tests_private/comparefiles/Bug689189.pdf | 22:00.50 |
| | Sorry. | 22:01.12 |
| henrys | thanks I'm doing -Z business on the original file anyway. | 22:02.07 |
| Robin_Watts | The original file works fine with alexes fixes. | 22:02.30 |
| | Forward 1 day (to 2011/07/29)>>> | |
IRC Logs