| | <<<Back 1 day (to 2013/01/16) | 2013/01/17 |
| sebras | is it just me that gets almost an fling-feel when using mupdf on this pdf? 00:42 <Robin_Watts> A. Because it doesn't make sense. | 00:54.17 |
| | 00:42 <Robin_Watts> Q. Why don't we top post? | 00:54.20 |
| | asdfjjasfj!!! | 00:54.21 |
| | heres the link: http://www.enigmadistribution.com/cms/filarkiv/releaser%202012(1).pdf | 00:54.28 |
| | but yes, Robin _did_ have a good argument :) | 00:54.38 |
| mvrhel_laptop | oh hi ray_laptop | 05:31.37 |
| | I looked at your regression results | 05:31.48 |
| | I don't see how any of those diffs have anything to do with your fix | 05:31.59 |
| | sorry I wasn't available earlier | 05:32.15 |
| | ray_laptop: if your change fixes the issue I would commit it | 05:32.45 |
| | bedtime for me | 06:49.53 |
| jzmer | is mupdf on x11 supposed to handle input methods? | 10:34.32 |
| sebras | jzmer: no, it doesn't at the moment. | 11:04.33 |
| kens2 | sebras he seems to have gone. | 11:04.50 |
| sebras | kens2: I know... | 11:04.57 |
| kens2 | Well, if he reads the logs :-) | 11:05.04 |
| sebras | exactly. :) | 11:05.12 |
| sebras | is back! | 14:03.08 |
| kens | welcome back | 14:03.23 |
| ray_laptop | Robin_Watts: I committed the fix for bug 693557. You may want to read the bug to see why your ndev patch caused the regression. I was concerned I was down a rat hole when digging this out. | 14:05.57 |
| | now to open a new bug for mvrhel to document the screwy (and I think broken) devn_get_params. | 14:06.54 |
| Robin_Watts | ray_laptop: So, essentially there was a mismatch between the main device, and the 'cloned' device for the thread. | 14:07.56 |
| | And the fix is to eliminate that mismatch? | 14:08.05 |
| ray_laptop | Robin_Watts: correct. As I mentioned yesterday, a 'brute force' hack (that I almost resorted to) would be to just copy the cdev->color_info to the ndev after the put_deviceparams | 14:09.44 |
| | but I wanted to understand exactly why it was getting set wrong, and found much wrongness, some of which I improved (IMHO) | 14:10.30 |
| Robin_Watts | I have to confess to not entirely understanding the details of how the clone is done. Certainly the put params/get params stuff confuses the hell out of me whenever I have to look at it. | 14:10.41 |
| ray_laptop | Robin_Watts: using get_putdeviceparams on the original cdev and put_deviceparams on the copied device is really just an indirect way of setting the device structure, but since device structures vary, it is safer than just copying a block of memory (using the size of the struct) since there may be pointers and the like we don't want in the clone | 14:13.45 |
| Robin_Watts | yes, seems reasonable. | 14:14.03 |
| ray_laptop | Robin_Watts: the screwy thing for me is the function terminology. You have to set the param list to 'write' in order to do a get_deviceparams and then set it to 'read' in order to do the put_deviceparams | 14:15.03 |
| Robin_Watts | get is put and put and get. | 14:15.20 |
| ray_laptop | from the viewpoint of the parameter list it sort of makes sense | 14:15.24 |
| Robin_Watts | bad means good, and to shake your booty means to wiggle ones butt.</Homer> | 14:15.43 |
| ray_laptop | the get_deviceparams is going to write into the param list | 14:15.52 |
| Robin_Watts | yeah, I understand the logic, but it still confuses my tiny brain every single time. | 14:16.13 |
| | How is your neck etc? | 14:16.56 |
| | Does the fact you're up at 5am or some such time indicate that you can't sleep? | 14:17.13 |
| ray_laptop | Robin_Watts: my neck has improved a lot. | 14:19.43 |
| | Robin_Watts: Don't know why I woke up, but I had taken time to sleep, etc. and decided to get on and commit the fix (before mvrhel changed his mind ;-) ) | 14:20.49 |
| | I am a little concerned by the spurious SEGV's that are showing up with some of the sumatra files. Do we have bugs open for those ? | 14:23.20 |
| | I'm concerned going to release with this many | 14:23.33 |
| kens | Not that i'm aware of no | 14:23.33 |
| | THey aren't regressions, and I think the files amy (in some cases) be broken | 14:23.46 |
| | Not that we should SEGV of course | 14:23.55 |
| Robin_Watts | kens: It wouldn't be a bad idea for us to have a quick blitz on those files. | 14:24.04 |
| kens | They should 'probably' go to Alex for initial investigation | 14:24.36 |
| ray_laptop | Robin_Watts: the plank one (sumatra/1432_-_image_with_32_bpc_causes_division_by_zero.pdf.plank.72.0) is probably one for you to look at | 14:24.59 |
| kens | I'm suspicious of any file which only fails on one device/resolution | 14:25.26 |
| ray_laptop | since it doesn't involve pdfwrite | 14:25.27 |
| Robin_Watts | ray_laptop: Indeed. I got a patch to customer 532 that seems to work, and seems faster last night. | 14:26.10 |
| | Am waiting to hear back how much faster. | 14:26.16 |
| ray_laptop | BTW, I couldn't get sumatra/1432_-_image_with_32_bpc_causes_division_by_zero.pdf.plank.72.0 to fail for me with a debug build on peeves, but I may have missed some command line magic | 14:26.21 |
| kens | The fact tha pdfwrite produces invalid PDFs from (I assume) invalid PDF intput isn't too surprising, but GS shouldn't SEGV on our files. | 14:26.26 |
| ray_laptop | kens: I agree | 14:26.43 |
| Robin_Watts | I am looking to see if there are any other similar hotspots in the pdf14 stuff. | 14:26.44 |
| kens | ray_laptop : Am I misreading it , or do the PDF files we produce only fail at 300 dpi ? Does that make clist a suspect ? | 14:27.37 |
| | (and why does plank only fail at 72 dpi....) | 14:27.50 |
| Robin_Watts | I suspect the files may spuriously fail at all sorts of different resolutions. | 14:28.25 |
| ray_laptop | kens: probably not clist since they are 300.0 (but they might depending on page size) | 14:28.33 |
| Robin_Watts | http://ghostscript.com/cgi-bin/showdeltas.cgi?report=cb51890a39bb97de55c5ce4734c55cba060d8e79&project=ghostpdl | 14:28.41 |
| kens | ray_laptop : I'm just wondering why the 72 dpi cases aren't failing | 14:28.53 |
| ray_laptop | the .0 means page mode (-dMaxBitmap=300000000), .1 is forced clist mode | 14:29.04 |
| Robin_Watts | It's more than 300000000 now. | 14:29.25 |
| | might be 40000000 | 14:29.37 |
| Robin_Watts | lunches | 14:29.48 |
| ray_laptop | too bad we can't shift the regression script over to using 300m (or 400m), but then bisect searching doesn't work | 14:30.39 |
| kens | Looks like Scott is getting grumpy with BAE | 14:35.24 |
| ray_laptop | the VOX file doesn't fail on windoze -- also I get no warnings from pdfwrite when creating the pdf. with -dMaxBitmap=300m it is not clist mode | 14:40.15 |
| kens | What happens when you run the produced file back through GS ? pdfwrite never uses clsit | 14:41.03 |
| ray_laptop | kens: that's what I mean that it doesn't fail (and doesn't use clist). sorry I wasn't clear. I just used vanilla command line to create the file with gs: gswin32c -sDEVICE=pdfwrite -o sumatra_VOX.pdf tests_private/pdf/sumatra/VOX.pdf | 14:43.11 |
| kens | Well, must be something special about the cluster setup then | 14:43.28 |
| | I get that from time to time. COUld also be Linux specific | 14:43.41 |
| chrisl | I'll try it here when svn finally updates..... | 14:44.29 |
| ray_laptop | kens: I'm going to try on peeves next | 14:44.56 |
| kens | I'd have a go but my pdfwite is quite different to the repository at the moment. | 14:45.40 |
| ray_laptop | kens: no problem. Probably isn't pdfwrite anyway | 14:46.31 |
| kens | Well, it won't be pdfwrite causing the seg fault directly, but it maybe could do a better job producing the PDF. | 14:47.14 |
| | Oh, my test fialed to buildm that's odd, it odes here. | 14:47.37 |
| | Hmmm looks like VS is less picky | 14:47.57 |
| kens | tries again with explicit casting | 14:50.24 |
| ray_laptop | OK. I can reproduce the VOX ppmraw SEGV on peeves with my binary and the command line from the logs. progress | 14:52.55 |
| kens | well that's somethign anyay | 14:53.06 |
| | chrisl have you seen the GG share price ? Up 25% over the 2 weeks | 14:53.44 |
| chrisl | Cripes! I did here that Jaws 3.0 had won some show prize, and was going down very well with customers | 14:54.25 |
| ray_laptop | Robin_Watts: there's a typo in the -dMaxBitmap in the regression script. it is only -dMaxBitmap=40000000 (that's -dMaxBitmap=40,000,000 or 40m) so it probably _is_ using clist. | 14:55.32 |
| | :-( | 14:55.34 |
| | it succeeds with -dMaxBitmap=400m | 14:55.50 |
| kens | That might explain the 300 dpi ones ? | 14:56.06 |
| ray_laptop | kens: yep. | 14:56.12 |
| | building debug now and will try that next | 14:56.29 |
| | OK. I can get a failure on peeves debug build with -dMaxBitmap=40m. -Z: shows 45 bands. Maybe we only run the pdfwrite output through in non-clist (.0) mode ??? | 15:01.44 |
| | Ahh. Windoze fails also without the -dMaxBitmap=300m | 15:02.40 |
| kens | Well that makes life easier | 15:02.54 |
| ray_laptop | so maybe these started showing up when the cluster script was changed to -dMaxBitmap=40000000 | 15:03.37 |
| kens | Its possible I guess | 15:03.49 |
| chrisl | Hmmm, valgrind says "Syscall param write(buf) points to uninitialised byte(s)" from cmd_put_range_op() | 15:04.01 |
| | Then a bunch of "Conditional jump or move depends on uninitialised value(s)" in gx_icc_is_linear_in_triangle{} | 15:05.03 |
| | kens: can I ask a question about pdfwrite's Type1C writing? | 15:12.26 |
| kens | You can always ask, can't promise I know the answer | 15:12.39 |
| chrisl | Do you know if it always uses a predefined encoding (then a differences array for anything custom)? It looks to me like it does | 15:13.14 |
| kens | Sounds about right yes | 15:13.25 |
| chrisl | Hmm, I don't think I can reliably reconstruct a CFF font to pass into U*ST :-( | 15:14.24 |
| kens | Froma type 1 with type 2 charstrigns ? | 15:14.47 |
| chrisl | It doesn't support that for "complete fonts", and incrementally I can do that, but it doesn't support type 2 SEACs | 15:15.41 |
| kens | THen I think we are stuck | 15:20.20 |
| | Although I admit SEACs are a terrible kludge | 15:20.39 |
| chrisl | Yes, but the support is there for "normal" fonts, only missing for "soft fonts", which seems crazy | 15:21.22 |
| kens | Or perfectly normal fir U*ST | 15:21.42 |
| chrisl | Basically, building a complete CFF was my last punt at this, but I can't see a totally reliable way to rebuild a CFF encoding | 15:22.20 |
| | I don't really feel like writing a type 2 charstring "flattener"! | 15:25.07 |
| kens | Its probably possible, but what's teh point ? | 15:25.29 |
| | If people insist on using it, they'll just have to have FT as well. | 15:25.55 |
| chrisl | Yep, that's the way it will have to be | 15:26.23 |
| kens | AH, good, compiles on Linux now, thatr's an improvement. Silly picky compiler | 15:26.42 |
| Robin_Watts | kens: Could you cast your eye over my bmpcmp please? | 15:33.53 |
| | Are you aware of these files causing problems? | 15:34.01 |
| kens | OK | 15:34.02 |
| Robin_Watts | The only change is a tweak to planar devices. | 15:34.28 |
| | None of these files use planar devices. | 15:34.37 |
| kens | Those files are all indeterminate | 15:34.37 |
| | always | 15:34.40 |
| Robin_Watts | Ah, cool. | 15:34.41 |
| | That's great, thanks. | 15:34.46 |
| kens | NP | 15:34.51 |
| henrys | hmph There was an error sending mail from 'bugzilla-daemon@ghostscript.com' to 'gs-bugs@ghostscript.com': Error executing /usr/lib/sendmail: Cannot allocate memory | 15:58.50 |
| paulgardiner_ | I've forgotten the naming convention for this case: I'm writing a function that will create a new annotation, but the result will be owned by the page and there's no need to free it. pdf_make_ ? | 15:59.00 |
| chrisl | henrys: I believe mvrhel has that problem last week, too | 15:59.30 |
| henrys | well it worked anyway - I sent it 2x assuming it failed the first time so 2 comments oh well. | 16:00.37 |
| | well it updated the bugzilla bug but did not broadcast the email. | 16:02.25 |
| chrisl | I guess the database is updated before the mail is sent | 16:03.03 |
| henrys | Hah I'll make a bug | 16:03.45 |
| | I wonder if the other email recipients worked the only error is to gs-bugs. | 16:05.25 |
| | 693567 is the bug I guess I should mail marcosw directly. | 16:11.37 |
| Robin_Watts | paulgardiner_: I don't know. I can't see many fz_make or pdf_make functions. | 16:12.59 |
| paulgardiner_ | Robin_Watts: I think it may be an uncommon case. | 16:14.02 |
| kens | Robin_Watts : how does the regression dashborad loo to you ? | 16:24.47 |
| Robin_Watts | plausible, why? | 16:25.07 |
| kens | ff and chrome show me nothign exept 'loading' | 16:25.21 |
| Robin_Watts | oh, me too, now. | 16:25.32 |
| kens | well at least its not just me | 16:25.51 |
| | I'm wondering if my test has killed the cluster | 16:26.02 |
| Robin_Watts | I wonder if casper is unwell. | 16:26.05 |
| henrys | possible the bugzilla problem is another symptom | 16:26.33 |
| Robin_Watts | Running clustermonitor.cgi on casper works, but not when done via a browser. | 16:28.26 |
| kens | Boggles | 16:28.39 |
| ray_laptop | OK. kids at school now. Interesting that the original VOX from sumatra doesn't fail, but the one out of pdfwrite does | 16:30.44 |
| | during clist playback | 16:30.55 |
| Robin_Watts | /etc/apache2/httpd.conf is empty... that seems odd. | 16:31.44 |
| henrys | the dashboard is back I noticed when I first loged on 3 bugzilla processes were using up 75% of memory which seems odd. | 16:35.32 |
| ray_laptop | the VOX SEGV is another related to pattern load | 16:35.35 |
| | henrys: looking with top ? | 16:35.58 |
| henrys | yes | 16:37.16 |
| | I don't see anything obvious in the logs but I didn't look hard seems to be working now. | 16:44.48 |
| Robin_Watts | henrys: I saw some errors in the logs, but as you say... | 16:45.53 |
| henrys | well the fiscal cliff has struck my january pay stub. US folks compare your FICA numbers to last january - wow what a hit. | 16:48.30 |
| | http://www.shrm.org/hrdisciplines/compensation/Articles/Pages/FICA-Social-Security-Tax-2013.aspx | 16:49.24 |
| | mvrhel_laptop:oh what I just wrote applies to you too - thought you were here - see the logs. | 16:50.41 |
| mvrhel_laptop | oh ok | 16:50.51 |
| Robin_Watts | henrys: Net effect is that you all pay 2% more tax, right? | 16:51.21 |
| | No, sorry, that 2% more of your wages goes in tax. | 16:51.53 |
| henrys | basically it does vary with what you make a bit because it is capped. | 16:53.18 |
| mvrhel_laptop | yes. the party is over. time to pay the bill | 16:57.14 |
| henrys | I wish they'd get rid of the cap and lower the rate proportionately | 16:57.28 |
| mvrhel_laptop | the cap does not make a lot of sense | 16:57.40 |
| ray_laptop | henrys: wouldn't do that much good. The really big earners don't earn as 'wages' subject to FICA -- things like stock options and dividend/investment income | 16:58.24 |
| mvrhel_laptop | that is true | 16:58.35 |
| henrys | yeah mitt wouldn't be bothered at all. | 16:58.47 |
| Robin_Watts | As far as I can tell, all such tax fiddling the world over never hits the big earners who can afford to structure their income etc so it comes via offshore companies. | 17:00.05 |
| JamesMT | Alrighty, I am back, and I too late again? Got held up this morning by unforseen meetings :D | 17:00.28 |
| henrys | so we could move Artifex "offshore" | 17:01.01 |
| JamesMT | Are you around by chance tor8 ?? | 17:01.31 |
| Robin_Watts | henrys: The trick is to get artifex to pay a company, not you. and have that company offshore. | 17:01.33 |
| tor8 | JamesMT: I am. | 17:02.11 |
| JamesMT | Awesome. I have an issue with MuPDF (specifically for my area it is mudraw but I think its across the tools) where some Unicode characters are eaten up. | 17:02.54 |
| Robin_Watts | JamesMT: Have you got a file you can share with us yet? | 17:03.19 |
| tor8 | JamesMT: right. I've seen you mention it in the logs. have you by any chance got a sample file? | 17:03.21 |
| JamesMT | I have been trying to get a copy of a PDF with an example set of the characters in them that I could submit a bug with but that has proven to be somewhat delayed it would seem | 17:03.21 |
| | Let me check with the person who said they would get me a file real quick. I can atleast give you a few sample characters if that would be of any help | 17:03.49 |
| tor8 | JamesMT: given the warnings you see printed by mupdf, I'd assume the file is broken in some way | 17:03.51 |
| Robin_Watts | tor8: I think gs manages to display the files OK with no warnings. | 17:04.19 |
| JamesMT | Its possible I suppose. But gs and adobe itself reads the characters in for display | 17:04.21 |
| tor8 | but if other viewers can do it, it may well be a bug in mupdf | 17:04.33 |
| | if you have the "mutool" command compiled, you can use that to look at a few things for me (unless you can get me the file, which will be more expedient) | 17:04.48 |
| JamesMT | Was told I should have a file in one moment :) | 17:05.10 |
| | Alright, have the file. I am going to verify it still exhibits the symptoms | 17:08.19 |
| | And it doesnt. | 17:09.34 |
| tor8 | rats. | 17:10.33 |
| JamesMT | Yes and No, glad its just something is up with that file but annoying I can not yet provide that something that is up. | 17:11.26 |
| | give me one moment | 17:11.31 |
| tor8 | I know there are a few CJK encoding limitations in the mupdf code ... we don't handle characters with encoding values >65535 and some multi-character unicode things don't work properly | 17:11.34 |
| JamesMT | Ahh, let me compare the section he sent with it in the original file and see if this is even a section that exhibited this before | 17:12.20 |
| | This section does contain characters that do not show up from the other file.. leading more to that file being compiled poorly in some way. | 17:13.50 |
| | For example 溫å¸æ¸¥è¡æ© now all show up properly but before it only printed 溫å¸æ¸¥æ© | 17:14.20 |
| | tor8: Since it seems localized to that file we are going to get ahold of the client the file came from and seek permission to send it to you in a private manner. | 17:20.48 |
| kens | Time for me to go. Goodnight all | 17:21.24 |
| Robin_Watts | mvrhel_laptop, ray_laptop: In bug 693541, now I've fixed the main problem, it falls over with a SEGV at the end. | 17:23.23 |
| | I think this is related to a gs_error_undefinedfilename error caused by having a separation name with a % in it. | 17:23.44 |
| mvrhel_laptop | I thought alexecher did a fix related to bad separation names | 17:24.42 |
| ray_laptop | Robin_Watts: an undefinedfilename shouldn't cause a SEGV | 17:24.57 |
| mvrhel_laptop | s/alexecher/alexcher | 17:24.58 |
| Robin_Watts | The separation name being "45% 286 overprinting 186" | 17:25.00 |
| | ray_laptop: Indeed it should not. | 17:25.10 |
| mvrhel_laptop | ray_laptop: well of course not | 17:25.14 |
| ray_laptop | Robin_Watts: % isn't an illegal character | 17:25.20 |
| Robin_Watts | I see the UndefinedFilename error, then a bit later, we end up with a SEGV because the list of filenames appears to be NULL. I'm still debugging it. | 17:25.46 |
| tor8 | JamesMT: okay. | 17:27.40 |
| JamesMT | Is it ok if I /msg you tor8? | 17:28.50 |
| ray_laptop | mvrhel_laptop: the VOX segfault is yet another case where a pattern is written with one depth, but when reading back, the device depth is different. | 17:29.55 |
| | at least I know where to put all the breakpoints :-) | 17:30.10 |
| mvrhel_laptop | Robin_Watts: oh this was the commit I was thinking of http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=9b59e4d156deae8afd6c8eecad3ce8b83b2d7664 | 17:30.21 |
| | ray_laptop: wow another one... | 17:30.39 |
| tor8 | JamesMT: yes. but /msg:s don't end up in the logs so I might miss it. | 17:30.54 |
| mvrhel_laptop | ray_laptop: glad to hear that you are feeling better | 17:30.59 |
| ray_laptop | mvrhel_laptop: this one has nothing to do with NumRenderingThreads, however | 17:31.03 |
| Robin_Watts | mvrhel_laptop: The problem is that when we open test(% 123 blah).tif, we spot the % and think it's a %d or something | 17:31.54 |
| mvrhel_laptop | ray_laptop: when I need to take a break from this windoze c++ stuff I will work some on cleaning up the devn nightmare | 17:31.56 |
| | Robin_Watts: ah | 17:32.08 |
| Robin_Watts | Really, we should ignore %'s in the separation names. | 17:33.26 |
| | which we can do by doubling them when we copy them in. | 17:33.39 |
| ray_laptop | mvrhel_laptop: no problem. That's been broken a long time. I just did the bug so it gets noted. | 17:34.21 |
| mvrhel_laptop | ray_laptop: yes. thanks | 17:36.21 |
| Robin_Watts | OK, so I avoided using % in separation names, and it solves the undefinedfilename error. It still SEGVs later on though. | 17:50.47 |
| | There is a job for Gemma in QA... :( | 17:51.10 |
| | ray_laptop: This is now dying in gx_pattern_size_estimate as pinst == NULL | 17:52.13 |
| | The immediate call stack is: clist_playback_band => gx_dc_pattern_load => gx_pattern_load => gx_pattern_size_estimate | 17:53.13 |
| ray_laptop | Robin_Watts: that may be related to the clist pattern problems I'm tracing. I assume you are in clist_playback | 17:53.15 |
| Robin_Watts | Any easy way I can see if it's the same issue ? | 17:54.00 |
| | dev->color_info.num_components = dev->color_info.max_components = 14. dev->color_info.depth = 128 | 17:55.59 |
| | I'll commit the filename fix anyway. | 17:56.31 |
| ray_laptop | Robin_Watts: right. the gx_pattern_cache_lookup probably failed the test: ctile->depth == dev->color_info.depth) (line 1328 of gsptype1.c) | 17:56.37 |
| | Robin_Watts: dev->color_info.depth = 128 ??? I assume this is planar mode rendering ??? | 17:58.43 |
| Robin_Watts | ray_laptop: It is indeed failing that test (112 != 128) | 17:59.00 |
| | Yes, tiffsep | 17:59.04 |
| ray_laptop | still a depth of 128 doesn't correspond to 14 components | 17:59.04 |
| | 112 is better for 14 components :-) | 17:59.23 |
| Robin_Watts | the test gets hit a number of times with 112 == 112, then the separation names get printed, then it hits the test again with a depth of 128. | 17:59.42 |
| | so it sounds exactly like your issue. | 17:59.49 |
| ray_laptop | Robin_Watts: so if you want to look at how the dev->depth is getting set to 128. That would be interesting | 18:00.03 |
| Robin_Watts | I'll wait for you to fix it, unless you have other tests you want me to do. | 18:00.08 |
| | ok, I can look for that. | 18:00.13 |
| ray_laptop | probably a data breakpoint | 18:00.18 |
| | mvrhel_laptop: the problem I am seeing is that a pattern is being put into the pattern_cache (and the clist) and the pattern is being rendered after a begin_trans_mask that does pdf14_update_device_color_procs_push_c,num_components_old = 3 num_components_new = 1 | 18:02.29 |
| | mvrhel_laptop: I have -Zv set and I don't see any end_trans_mask prior to finishing rendering the pattern, which makes sense that the pattern is being rendered with depth 8 | 18:03.32 |
| mvrhel_laptop | ray_laptop: sounds like the update is fine. all patterns in softmasks should be 1 component | 18:03.33 |
| | they are all gray based | 18:03.36 |
| ray_laptop | mvrhel_laptop: I think the problem comes when the pattern is ALSO used to fill a path, not in the trans_mask. | 18:04.26 |
| mvrhel_laptop | ray_laptop: aha. this was the case I mentioned the other day | 18:04.41 |
| | I was wondering how we handle patterns that are doing double duty | 18:04.53 |
| | and it sounds like we dont :( | 18:05.02 |
| | if the pattern is going to be "rendered" in the clist in a particular color space, then we will have to make another version of it | 18:05.47 |
| | or come up with a way to keep it in some generic form that can be rendered in different color spaces | 18:06.06 |
| | ray_laptop: does that makes sense? | 18:07.42 |
| ray_laptop | mvrhel_laptop: hmm... I don't see the pattern with that ID used outside the making of the transparency mask :-( | 18:11.15 |
| | but in clist playback, I see the pattern being loaded _after_ the end_trans_mask (so the depth is back to 24 bits) | 18:12.01 |
| | I think I need to look at the PDFDEBUG :-( (how this is being created). I think I'll restart with a readable one, however. | 18:13.31 |
| Robin_Watts | ok, so the device in question is a pdf14cmykspot one. | 18:33.35 |
| | It's created in gs_pdf14_device_push by a call to gs_copydevice, which copies the prototype. | 18:34.09 |
| | The depth is never set to anything other than the prototypes. | 18:34.25 |
| | gs_pdf14_device_push resets num_components and max_components, but depth is never recalculated. | 18:35.47 |
| ray_laptop | Robin_Watts: doesn't sound right | 18:36.03 |
| Robin_Watts | I think I need to do the same fix there that I did... elsewhere. | 18:36.13 |
| ray_laptop | Robin_Watts: I agree | 18:36.21 |
| | pdf14 depth is always 8 bits per component | 18:37.29 |
| | so as long as you are getting num_components = 14, then 8*num_components is good for the depth | 18:38.18 |
| | all this color space change seems a bit fragile | 18:38.42 |
| Robin_Watts | ok. now runs to completion with no problems. | 18:41.03 |
| mvrhel_laptop | thats good | 18:41.08 |
| Robin_Watts | Memento shows leaktastic leakiness from lcms fapi and tiff_from_filep | 18:41.25 |
| mvrhel_laptop | there some new words for you | 18:41.43 |
| Robin_Watts | none of them usable in polite company? :) | 18:42.07 |
| mvrhel_laptop | perhaps. if you were to use those at a party, you might spend your time alone | 18:43.07 |
| ray_laptop | I need lunch to trace this VOX problem :-( | 18:49.16 |
| mvrhel_laptop | ray_laptop: if you want to hand this issue over the me that is fine. I am not sure how you and Robin_Watts have both ended up working on issues that probably should have been my problem | 18:51.15 |
| Robin_Watts | mvrhel_laptop: cos it was "my" commit :) | 18:51.41 |
| mvrhel_laptop | Robin_Watts: if you want to work on it that is fine, just feel free to pass it on if you want also | 18:55.26 |
| Robin_Watts | mvrhel_laptop: I think it's fixed now. | 18:55.40 |
| mvrhel_laptop | Robin_Watts: great!. I guess then my comments are for ray_laptop who seems to have a more difficult one | 18:56.18 |
| ray_laptop | mvrhel_laptop: Please feel free to have a look. If you do a "normal" pdfwrite of the tests_private/pdf/sumatra/VOX.pdf I used: gswin32c -sDEVICE=pdfwrite -o sumatra_VOX.pdf tests_private/pdf/sumatra/VOX.pdf | 19:00.40 |
| mvrhel_laptop | ok | 19:01.03 |
| ray_laptop | mvrhel_laptop: then run that file with: debugbin/gswin32c -r300 -sDEVICE=ppmraw -o x.ppm sumatr_VOX.pdf you will get the SEGV | 19:01.27 |
| | (spelling correctly, of course) | 19:01.44 |
| | you can bp in gx_pattern_cache_lookup when (ctile->id == id) && (ctile->depth != dev->color_info.depth)) in gsptype1.c line 1325 | 19:04.12 |
| Robin_Watts | ray_laptop: Is it possible that my fixes might solve this? | 19:04.42 |
| ray_laptop | the id I get the failure on (which should be repeatable) is 0x56a1 | 19:04.49 |
| mvrhel_laptop | ray_laptop: ok. when I get to a good stopping point on this stuff, I will take a look at it | 19:05.13 |
| Robin_Watts | I will double check here in case my fixes fix it. | 19:05.30 |
| ray_laptop | Robin_Watts: I don't think so. The dev->color_info.depth agrees with the num_components (24 and 3), but the ctile created when writing the SMask is 8 bit, 1 component | 19:07.20 |
| Robin_Watts | fair enough. | 19:07.51 |
| ray_laptop | Robin_Watts: mvrhel_laptop: I see the push_trans_mask and pop_trans_mask in the -Zv output before it does the pattern_load. It's like the pop_trans_mask is too early because I should be seeing the 'f' painting this into the SMask before it gets popped | 19:11.44 |
| mvrhel_laptop | is this during reading or writing (clist) | 19:12.22 |
| | ray_laptop: ^^ | 19:12.44 |
| Robin_Watts | (I can confirm that my fixes do not fix it) | 19:12.51 |
| ray_laptop | the above is during reading. During writing, I see a reasonable sequence (I think) | 19:12.52 |
| mvrhel_laptop | oh this will be a fun one to find.... | 19:13.18 |
| ray_laptop | mvrhel_laptop: I am going to get lunch and let you beat on it a bit. You may come up with a better way to understand it. | 19:13.40 |
| mvrhel_laptop | ray_laptop: ok. I will take a break in a few minutes from my c++ run | 19:14.11 |
| | fun | 19:14.12 |
| ray_laptop | mvrhel_laptop: I recommend doing pdfclean -d on the pdfwrite output so you can edit it more easily and relate it to the -dPDFDEBUG output during writing the clist | 19:14.33 |
| mvrhel_laptop | ray_laptop: yes, my first step will be to edit down | 19:15.06 |
| Robin_Watts | Let me see if I can cut the test file down to a more reasonable size. | 19:15.07 |
| ray_laptop | the pdfclean -d version still fails the same, it's just easier to make sense of the file (for me) | 19:15.09 |
| mvrhel_laptop | oh or I will let Robin_Watts do it... | 19:15.24 |
| ray_laptop | mvrhel_laptop: I'll check the logs before diving back in later | 19:15.38 |
| mvrhel_laptop | Robin_Watts: finally! I have the windoze streaming stuff working with fitz. that took long enough, but at least it is working. mupdf read got everything it needed did what it needed to parse up the pdf | 19:42.16 |
| | good stopping point. now I will look at this fun issue that ray was working on | 19:43.08 |
| | ray_laptop: back from lunch already. I havent done anything yet | 19:43.23 |
| Robin_Watts | mvrhel_laptop: I have a much reduced file. | 19:43.38 |
| mvrhel_laptop | oh great | 19:43.42 |
| | Robin_Watts: can you share it | 19:44.11 |
| Robin_Watts | sure. I'm still shrinking it if you want to give me a few more minutes. | 19:44.27 |
| mvrhel_laptop | definitely | 19:44.37 |
| | thanks Robin_Watts | 19:44.45 |
| Robin_Watts | np. | 19:44.50 |
| | ok, cutdown4.pdf in my home dir on casper | 19:47.09 |
| | mvrhel_laptop: ^ | 19:47.17 |
| mvrhel_laptop | ok thanks | 19:48.07 |
| | I don't see anything drawn (at least with AR) | 19:51.17 |
| Robin_Watts | mvrhel_laptop: No, I probably removed everything :) | 19:51.37 |
| mvrhel_laptop | looks like there is an image.. | 19:52.14 |
| Robin_Watts | There is. I've just reduced that to a 1x1 CMYK image here. | 19:52.35 |
| mvrhel_laptop | ha | 19:52.44 |
| | ok. if it still has the issue let me get that one | 19:52.53 |
| Robin_Watts | cutdown5.pdf in my home dir | 19:54.50 |
| mvrhel_laptop | ok thanks. | 19:55.29 |
| | ok. I am going to look over the content for a minute while I eat lunch | 19:56.03 |
| Robin_Watts | OK, cutdown6.pdf has some better names for the resources. | 19:58.03 |
| henrys | my apple cinema display 3 years RIP geez... | 20:03.47 |
| Robin_Watts | henrys: jeez. terminal ? | 20:04.01 |
| henrys | $660 was the estimate to fix it, I can buy one for a bit more | 20:04.46 |
| Robin_Watts | The price those things go for, you'd expect some build quality. | 20:04.55 |
| henrys | you can get 50 bucks for the scrap I opted to leave it at the apple store. | 20:09.20 |
| Robin_Watts | 714UKP here. Crumbs. | 20:13.29 |
| mvrhel_laptop | Robin_Watts: so basically we have an RGB transparency group, a soft mask that is filled with pattern (that is an empty pattern), and an CMYK image that is drawn with that mask in the RGB group | 20:23.16 |
| | I don't quite understand why we would be having issues with this one | 20:23.31 |
| | but I will fire up GS now and see what explodes | 20:23.46 |
| Robin_Watts | changing the bboxes and stuff makes it stop crashing. | 20:24.16 |
| | That may be expected. | 20:24.21 |
| | I suspect softmasks filled with patterns are rare. | 20:25.02 |
| mvrhel_laptop | Robin_Watts: yes. I don't know how many of those I have seen | 20:25.33 |
| Robin_Watts | oh, bugger. | 20:28.15 |
| | alexcher: In a moment of stupidity here, I've managed to remove your last commit from gs. | 20:30.36 |
| | I pushed a commit of mine up with a -f flag by accident. | 20:31.02 |
| alexcher | Robin_Watts: OK, I'll check and recommit. | 20:31.22 |
| Robin_Watts | alexcher: Thanks, and sorry! | 20:31.31 |
| | oh, it's henrys, not alexchers. | 20:32.07 |
| | Let me see if I can fix it here. | 20:32.14 |
| | I hope that's fixed now. Sorry about that. | 20:44.47 |
| henrys | now I see no difference between my head and remote did you pull out your change? | 20:48.17 |
| Robin_Watts | henrys: If you pull, you should get my patch after yours | 20:59.36 |
| | http://git.ghostscript.com/?p=ghostpdl.git;a=summary <- looks right to me | 20:59.56 |
| henrys | yup looks good | 21:00.26 |
| alexcher | marcosw: Please add 'alex_i3770' to the cluster. My son wants to join the quest. | 21:14.44 |
| marcosw | alexcher: will do later today, I'm in a meeting currently. | 21:15.10 |
| mvrhel_laptop | there is something weird going on in the interpreter end of this file | 21:27.47 |
| | it ends up resolving the pattern and doing the same fill twice | 21:28.02 |
| | bbiaw | 21:55.32 |
| | Forward 1 day (to 2013/01/18)>>> | |
IRC Logs