| | <<<Back 1 day (to 2013/12/17) | 2013/12/18 |
| Robin_Watts_ | mvrhel_laptop: Did that sort the bug OK? | 00:52.29 |
| | mvrhel_laptop: And excellent news about the Windows 8 thing :) | 00:52.49 |
| mvrhel_laptop | Robin_Watts_: yes that is good news | 00:56.25 |
| | Robin_Watts_: just got back from picking up in-laws from airport | 00:56.40 |
| | have not accomplished much today | 00:56.45 |
| | hope to get the bugs wrapped up tonight | 00:56.53 |
| Robin_Watts_ | No worries, was just wondering :) | 00:57.41 |
| Robin_Watts_ | wonders if anyone ever gets the car rental invoice and goes "ah yes, those were the charges I was expecting". | 00:58.20 |
| | I prepaid 189 UKP for renting, then upgraded the car. They credited me for $189 :( | 00:58.51 |
| mvrhel_laptop | that is not right | 01:03.15 |
| | Robin_Watts_: ok the customer file runs correctly | 01:07.14 |
| | Let me check the other file now | 01:08.23 |
| | Ok that one still fails | 01:10.45 |
| Robin_Watts_ | ah. | 01:11.37 |
| mvrhel_laptop | This one has something to a mask fill | 01:11.49 |
| Robin_Watts_ | Going through the stroking stuff again? | 01:11.51 |
| mvrhel_laptop | no stroking | 01:11.55 |
| Robin_Watts_ | Ok, so perhaps not surprising that didn't fix it. | 01:12.06 |
| mvrhel_laptop | s/to/to do with/ | 01:12.10 |
| | Same crash point though so I was hopeful | 01:12.21 |
| | I will look further at this one tonight | 01:12.34 |
| Robin_Watts_ | If you want me to look into anything leave a message on here. | 01:12.38 |
| | I'll read logs in the morning. | 01:12.44 |
| mvrhel_laptop | ok thanks | 01:12.46 |
| | have a good night | 01:12.51 |
| Robin_Watts_ | np. Night. | 01:12.51 |
| mvrhel_laptop | morning kens | 06:52.18 |
| kens | Morning Michael | 06:52.25 |
| chrisl | kens: good morning - you see Till raised the bug about the duplex stuff | 07:07.56 |
| kens | I saw it last night | 07:08.02 |
| | I'm part way through it | 07:08.11 |
| chrisl | Good, I've fulfilled my promise.... | 07:08.25 |
| kens | :) | 07:08.30 |
| chrisl | BTW, I don't think you need to store the pagesize specially | 07:08.53 |
| kens | No ? | 07:09.01 |
| | How do I tell the difference between a requested page size that was not satisified, and a new and different page size ? | 07:09.21 |
| chrisl | Oh, you want to cover that - I was thinking with a new, initial setpagedevice before the first page, the existing pagesize check would be sufficient | 07:10.44 |
| kens | I think I still need to be able to tell if the document changed page size part way through and request a different media | 07:11.13 |
| | Otherwise someone will complain about that..... | 07:11.28 |
| chrisl | Yeh, you are probably right. | 07:12.11 |
| kens | Like I said, I got part way through it yesterday, it shouldn't take long to finish it up | 07:12.36 |
| | I thought the JBIG2 decoding problem would take longer, but it was fairly easy, and I threw it to Henry | 07:12.58 |
| | Sorry that was the *encoder* | 07:13.12 |
| | It doesn't like being passed 0 bytes to encode ;-) | 07:13.25 |
| | Hmm looks like the preflight thingy is right, we should emit an EOL before endstream, and sometimes we don't | 07:14.09 |
| chrisl | Hopefully that encoder issue with be fairly easy to fix.... | 07:14.48 |
| kens | Well I just returned 0 instead of throwing an error, if there were no bytes input and no pending writes | 07:15.16 |
| | All the other encoders are happy with being passed 0 bytes of data to encode | 07:15.51 |
| chrisl | I'm pretty sure they have to be | 07:16.13 |
| kens | Yes, I thought so too, the JBIG2 encoder looks wrong to me in this case | 07:16.36 |
| | But then, hgow often does it get used ? | 07:16.45 |
| chrisl | Extremely rarely - only available in the commercial release, only by request, and almost totally pointless...... | 07:17.36 |
| kens | Yep. And probably only pdfwrite can even use it | 07:18.01 |
| chrisl | There is a jbig2 output device, but I don't think it gets built by default | 07:18.31 |
| kens | Oh didn't know that one | 07:18.49 |
| chrisl | gdevjbig2.c | 07:19.12 |
| kens | I bet that never gets used either | 07:19.25 |
| chrisl | Someone asked about it earlier this year - I may have added it into the build back then, can't remember | 07:20.19 |
| kens | Hmm all the occurences of endstream seem to be guarded by a '\n' if pdev->PDFA is not 0. I wonder how the file ends up without them | 07:23.15 |
| | AH because he hasn't produced a PDF/A file :-) | 07:28.55 |
| mvrhel_laptop | so I have tracked down where Bug 693365 is going wrong during the clist reading phase. very strange | 07:38.55 |
| | done for the night now | 07:39.00 |
| kens | Goodnight mvrhel_laptop | 07:39.07 |
| mvrhel_laptop | good night | 07:39.12 |
| tor8 | sebras: regarding the type3 fonts in EITM01-rapport-493-346.pdf I don't see anything odd about them. you sure you're not just seeing the odd effects of gamma correction not being applied? | 08:48.21 |
| | sebras: you can try the tor/gamma branch and see if you prefer the look of that | 08:51.06 |
| kens | Oh great a 127 Mb PDF file. | 09:16.12 |
| | And of course its a 132 page PDF file, o apparent attempt to reduce the file size | 09:19.06 |
| tor8 | kens: interesting. I have found a way to travel door to door by train to your place :) only takes slightly under 21 hours! | 10:06.26 |
| kens | O.O ! | 10:06.40 |
| tor8 | and 4 train changes :) | 10:06.56 |
| kens | Seems like a long time when you could train to Copenhagen, fly to Gatwick and train to Horsham | 10:07.00 |
| | 4 is less than I would expect | 10:07.13 |
| tor8 | yup. but it's doable. | 10:07.14 |
| kens | Well, if you really really wnt to :-) | 10:07.24 |
| tor8 | lund -> copenhagen, night train to cologne, intercity to brussels, eurostar to london | 10:07.36 |
| kens | Well, that's not door to door to get here, you'd have at least 1 more change in London to get here | 10:08.15 |
| tor8 | and then the schnellzug to horsham | 10:08.33 |
| kens | There's a fast train ? News to me :-) | 10:08.53 |
| tor8 | says so on bahn.de! :) | 10:09.04 |
| sebras | tor8: it might very well be gamma correction. the issues I saw were just text rendering quality. | 10:09.06 |
| kens | Presumably London = Kins Cross St Pancras | 10:09.12 |
| sebras | to me it seems as if it has been better before. | 10:09.18 |
| tor8 | yeah, St. Pancras intl | 10:09.26 |
| kens | Well, you could get the Thameslink service to Horsham I guess | 10:09.40 |
| tor8 | sebras: to me it looks like it always has. you might be seeing it on a different monitor though? | 10:09.40 |
| | kens: it says "E 2309" is the line | 10:09.55 |
| kens | ROFL never heard of it :-) | 10:10.05 |
| tor8 | london victoria - horsham. might involve some walking to get to victoria from st pancras. | 10:10.42 |
| sebras | tor8: no, my own screen at home so it should be the same. maybe my memories are just playing tricks on me. | 10:10.50 |
| kens | More than a bit! | 10:10.52 |
| | tor8 you would want to take the Underground to Victoria, and that's 2 underground liens as well I thiunk | 10:11.20 |
| sebras | tor8: basically I worry about the non-evenness of stem widths of the characters. | 10:11.21 |
| | when I zoom in they all look alright, but when zoomed out they look uneven. | 10:11.33 |
| tor8 | sebras: are the wide stems gray and the narrow stems black? | 10:11.34 |
| kens | tor8 but there is a rail service from Kings Cross (next door to St Pancras, literally) which goes direct to Horsham | 10:11.49 |
| tor8 | I see some of that, and the "unevenness" you see should be attributable to blending in a non-linear colorspace | 10:12.02 |
| | kens: I'm just surprised how many options there are to get around europe by train | 10:12.25 |
| sebras | tor8: is the blending something we've changed recently? | 10:12.32 |
| tor8 | getting to Istanbul is a hell of a ride though. 60 hours! | 10:12.38 |
| kens | Oh you can go almost anywhere in Europe by train,albeit slowly | 10:12.42 |
| sebras | maybe I have not been viewing latex-generated documents for quite some time. | 10:12.55 |
| kens | Its good if you have a flyign phbia | 10:12.59 |
| tor8 | kens: most of northern central europe is reachable in a day (or by night train) from here | 10:13.17 |
| kens | Yep, slow :-( | 10:13.29 |
| sebras | kens: it is better to cure your flying phobia imho. at least that worked for me. :) | 10:13.33 |
| kens | does not have a phobia | 10:13.46 |
| tor8 | copenhagen to prague, 15 hours by night train. almost beats flying, depending on how comfortable the train is. | 10:13.47 |
| kens | A sleeper would be OK | 10:14.00 |
| tor8 | sebras: we have not changed blending. we have improved image resampling (which was a long time ago) | 10:14.42 |
| kens | I've considered flying to JFK and then train to SFO before now, its supposed to be quite scenic, though again rather slow | 10:14.44 |
| tor8 | give the tor/gamma branch a try, it does blending in a linear colorspace | 10:14.59 |
| | kens: yeah, that would be an interesting trip. get to see much of the countryside from a much closer distance than 30k feet up. | 10:15.47 |
| | but I fear the boredom would take hold rather fast | 10:16.14 |
| kens | Sadly it takes several days also, maybe one day when Melanie is at university | 10:16.15 |
| | WOuld be OK if the train has WiFi :-) | 10:16.33 |
| tor8 | kens: that's not so far :) | 10:16.36 |
| | kens: and power! | 10:16.39 |
| kens | Oh yeah power too | 10:16.45 |
| | Stella and Melanie are in Nottingham today for an interview there | 10:17.07 |
| | 5 hours of tests, group sessions and interviews. And a dress code..... | 10:17.34 |
| tor8 | oh my. that's quite a handful. | 10:17.50 |
| kens | Kings was much the same | 10:17.57 |
| | I imagine Cardiff and UCL will be too. Portsmouth made an offer without seeing her (but it is her backup choice) | 10:18.24 |
| | Apparently Nottingham is the top place in the country | 10:18.48 |
| | (for studying pharmacy) | 10:18.55 |
| tor8 | she's dead set on pharmacy then? | 10:19.03 |
| | or leaving the biochemistry as backup? | 10:19.13 |
| kens | Bit of both | 10:19.21 |
| | SHe wants to start with pharmacy and if she hates it she can fall back to one of the other bio-sciences | 10:19.40 |
| | OK I think that''s Till's stuff done, just a cluster push to check I haven't broken anything | 10:20.44 |
| tor8 | sebras: the tor/gamma branch does make a lot of text "lighter" on the page, and it's not what you're used to seeing, so we haven't made it standard. | 10:23.22 |
| | it may also be completely broken, but I think it should work :( | 10:23.33 |
| sebras | tor8: maybe I should checkout earlier versions and try with those before complaining. :) | 10:24.35 |
| tor8 | Robin_Watts: something else I noticed: limiting the subpixel precision of text layout in the vertical direction fails spectacularly when the page is rotated 90 degrees. and I guess it'll look dreadful for any vertical writing systems in normal rotations as well. | 10:26.10 |
| Robin_Watts | tor8: I wasn't aware I'd changed vertical to be different to horizontal. | 10:55.03 |
| tor8 | oh, but we have. since 1.2 anyway. | 10:58.15 |
| | or we've got a sign error | 10:59.13 |
| | rotate any page 90 degrees and look how bad the spacing is | 10:59.23 |
| henrys | chrisl: this gravity light you are talking about must have a tiny wattage⦠it really takes a lot of work to light a bulb I know going my max on a bike is only enough to light a few light bulbs. | 14:30.55 |
| kens | low energy bulbs are only a few watts | 14:32.57 |
| chrisl | henrys: http://deciwatt.org/ | 14:34.44 |
| henrys | yes I just watched it, I was imaging lighting a room and it won't do that. | 14:35.19 |
| | imagining | 14:35.36 |
| chrisl | No, it's intended to replace a kerosene lamp, and those don't kick out a huge amount of light | 14:35.52 |
| | I've no idea what my wattage output is on the bike - I haven't got a cycle computer yet...... | 14:37.25 |
| Robin_Watts | chrisl: I backed that. | 14:40.56 |
| henrys | chrisl: I used that because bikes are actually fairly efficient I hold about 200-300 watts and a pro would double that. When my kids were little I took them to a museum that had a crank powered 100 watt light and it was amazing how hard you had to crank to get it to light. | 14:40.57 |
| kens | Low energy bulbs run on 10s of watts | 14:41.56 |
| henrys | kens:yea led improvements | 14:42.23 |
| Robin_Watts | The gravity light is a really great idea that has potential to transform many peoples lives; it enables clean efficient, cheap lighting, and even charging of small devices. | 14:42.35 |
| | kens: halogens are 10s of watts. LEDs are <=10 watts | 14:42.51 |
| | a 10 watt LED light is typically equivalent to a 75-80Watt lightbulb. | 14:43.14 |
| kens | CFCs in the 5-10 watt range usually | 14:43.17 |
| | But can be more for bright lights | 14:43.26 |
| chrisl | henrys: you just reminded me that I keep meaning to get a computer for the bike, but most have the speed sensor on the front wheel, and as I want it to work on the turbo trainer, I need the speed sensor on the rear wheel. | 14:43.31 |
| Robin_Watts | An 11W halogen is equivalent to a 45watt bulb here, for one I have in the house. | 14:44.05 |
| | henrys: I have a solution to bug 694528. | 14:44.31 |
| henrys | chrisl: I'm getting a wattage meter for my outdoor bike this year, everyone in triathlon has them these days. | 14:44.37 |
| Robin_Watts | Well, I have 2. One that I've tested and works, and another one that I prefer that I came up with while running. I'm going to test that one now. | 14:45.08 |
| henrys | Robin_Watts: oh great | 14:45.38 |
| | chrisl: well at least folks that do the long course. Nothing like it for pacing | 14:46.24 |
| chrisl | henrys: yeh, they are a good training aid - I'm more interested in cadence, though. | 14:47.03 |
| henrys | not to put down the gravity light - but it seems trivial the breakthrough was lumens per watt being high enough... | 14:49.06 |
| Robin_Watts | The trick with the gravity light is to make them cheaply enough, and robustly enough. | 14:50.20 |
| | And if it was such a simple idea, why had no one done it before? :) | 14:50.51 |
| chrisl | Yeh, knocking them out for 10usd each, in a package robust enough for "developing nations" is quite a feat | 14:51.32 |
| henrys | Robin_Watts: it's only fairly recent that lumens per watt would allow such a device. | 14:51.43 |
| Robin_Watts | kerosene lamps are a health hazard (nasty smoky things leading to respiratory problems), give poor light, cost a lot ($2 a refill, which is a lot when these people live on much less than a $1 a day), and tend to burn things down when you knock 'em over :) | 14:52.46 |
| | henrys: Yes. And the 'linear pull' dynamo thing it uses was only really around about 5 years ago, when Bayliss did the wind up radio thing. | 14:53.23 |
| henrys | can't people just sleep at night ;-) | 14:54.46 |
| chrisl | henrys: I've got the changes to get rid of "floatp" - for once, a simple search and replace actually worked! | 14:59.06 |
| henrys | chrisl: I think that is a nice change. | 15:00.02 |
| chrisl | henrys: So I should just push the commit? | 15:00.20 |
| henrys | chrisl: sure | 15:00.42 |
| chrisl | henrys: done! I shall now await the complaints about the non-fast forwardable pulls people get...... | 15:01.43 |
| henrys | chrisl: let the whining commence ;-) | 15:02.22 |
| kens | It fast-forwarded for me | 15:09.15 |
| chrisl | Well, that encouraging - it just touched quite a few files. Although fewer than I expected, originally | 15:09.47 |
| kens | I oculd whine a bit if it helps | 15:10.02 |
| chrisl | It wouldn't matter, I'd ignore it | 15:10.20 |
| paulgardiner | Robin_Watts, tor8: commit on paul/master with a few android improvements | 15:14.37 |
| Robin_Watts | Did you see the password bug? | 15:15.11 |
| paulgardiner | Robin_Watts: no. where was that reported? | 15:15.41 |
| Robin_Watts | http://bugs.ghostscript.com/show_bug.cgi?id=694849 | 15:16.02 |
| paulgardiner | Oh okay. I have a passworded file somewhere, but I might as well wait for the reporter to upload. | 15:18.12 |
| Robin_Watts | In that commit, the loop over the children removing them from the layout... why is that not needed? | 15:19.53 |
| paulgardiner | Because the next onLayout call will do it since mResetLayout is set true. | 15:20.43 |
| Robin_Watts | Then it looks fine to me. | 15:20.54 |
| paulgardiner | Great. ta | 15:20.59 |
| Robin_Watts | henrys: My proposed patch can be seen at the end of: http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=robin (just the gsptype1.c changes) | 15:28.34 |
| chrisl | Robin_Watts: if we go ahead with your patch, how about putting the FLT_EPSILON define in somewhere like stdpre.h? I can see it being useful elsewhere in the future..... | 15:33.06 |
| Robin_Watts | chrisl: Sure. Ideally we should be getting it from float.h | 15:33.23 |
| henrys | Robin_Watts: ugh, but okay | 15:34.54 |
| Robin_Watts | henrys: It's the correct fix, I believe. | 15:35.09 |
| | It would be lovely to be able to trust floating point to always know that a == a, but we can't. | 15:35.54 |
| henrys | Robin_Watts: understood but this algorithm is about a pixel being out of range which is identified by an integer coordinate ideally so why are we in floating point land in the first place. | 15:37.47 |
| | ? | 15:37.47 |
| Robin_Watts | henrys: Well, we could try for a fixed point version. | 15:38.05 |
| chrisl | Robin_Watts: so, FLT_EPSILON should probably go in base/math_.h | 15:38.31 |
| Robin_Watts | AIUI, the bbox that this code is building is in device space. | 15:38.42 |
| henrys | Robin_Watts: I think your fix is probably the expedient thing to do. | 15:38.44 |
| | Robin_Watts: yes I don't think we have the concern you raised yesterday about rotations and such. | 15:39.12 |
| Robin_Watts | Let's put my fix in, and I'll have a quick look to see if a fixed point version is simple. | 15:39.19 |
| henrys | Robin_Watts: sorry my explanation yesterday was a bit misleading the floating point difference goes through a few steps before it directly affects the bounding box. | 15:41.20 |
| Robin_Watts | it's specifically the test for 'did the bbox for this repeat end up non empty' that fails. | 15:42.17 |
| mvrhel_laptop | Robin_Watts: do you have a few minutes to talk about patterns, clist, and the pattern cache | 15:42.30 |
| | This is for but 693365 | 15:42.49 |
| | s/but/bug/ | 15:42.56 |
| Robin_Watts | I'm not sure we actually need to check ALL the repeats of the pattern. There should be a better algorithm here. | 15:43.07 |
| | mvrhel_laptop: OOh! All my favourite subjects at once! | 15:43.22 |
| mvrhel_laptop | your lucky day | 15:43.34 |
| | is this a good time? | 15:43.40 |
| kens | Don't forget transparency | 15:43.40 |
| Robin_Watts | Actually, you missed transparency. | 15:43.43 |
| | kens :) | 15:43.46 |
| mvrhel_laptop | Yes, that is in here too | 15:43.49 |
| Robin_Watts | mvrhel_laptop: As good as it's going to get. | 15:43.57 |
| kens | Bingo! | 15:44.04 |
| mvrhel_laptop | Ok. so let me describe what is happening | 15:44.05 |
| Robin_Watts | fetches the gin. | 15:44.16 |
| mvrhel_laptop | The simplified file has a few patterns | 15:44.17 |
| henrys | Robin_Watts: you look at all this we're going to a christmas party ;-) | 15:44.17 |
| Robin_Watts | ha! | 15:44.35 |
| mvrhel_laptop | and they all get rendered at transparency buffers | 15:44.40 |
| | s/at/as | 15:44.49 |
| | for most of the clist reading, each time we get a new pattern, the old pattern is removed from the cache due to its size and the new one is added | 15:45.50 |
| | each time we have a sequence of cleaning the cache, reloading with a new pattern, push a group, pop a group, repeat | 15:46.26 |
| | this works fine. | 15:46.29 |
| | but is not optimal | 15:46.35 |
| | at some point, we have a case, where we reload the new pattern, | 15:46.55 |
| | push a group | 15:46.59 |
| | and then reload the same pattern | 15:47.05 |
| | which cleans the cache | 15:47.12 |
| | unfortunately, this is an issue | 15:47.20 |
| Robin_Watts | so the pattern use is nested ? | 15:47.31 |
| mvrhel_laptop | since the pattern had a pointer to the buffer that we tile into | 15:47.31 |
| | no | 15:47.35 |
| | in fact this tile, was previously used in another band just fine | 15:48.16 |
| | for some reason, in the middle of the mask fill (these are all mask fills with tiles) we reload the color | 15:48.39 |
| | so that is problem 1) | 15:48.55 |
| | however, my question for you is on the clist writing stage | 15:49.13 |
| Robin_Watts | So problem 1) a pattern is cleared out of the cache while still being used. | 15:49.32 |
| mvrhel_laptop | yes | 15:49.39 |
| Robin_Watts | OK. | 15:49.42 |
| mvrhel_laptop | problem 2) is related in a way | 15:49.46 |
| | during clist reading, cmd_put_drawing_color. | 15:49.58 |
| | we end up repeatedly writing out the tile into the clist | 15:50.54 |
| | instead of the tile id | 15:50.57 |
| | so in gxclpath.c | 15:51.12 |
| | line 185 test never works | 15:51.26 |
| Robin_Watts | during clist *reading* ? | 15:51.49 |
| mvrhel_laptop | pcls->pattern_id == pattern_id is never true | 15:51.50 |
| | during writting | 15:51.53 |
| Robin_Watts | OK. | 15:51.57 |
| | So pcls->pattern_id is different each time ? | 15:52.47 |
| mvrhel_laptop | yes | 15:52.55 |
| | I have a patch that hooks in a bunch of debug prints that monitors this | 15:53.05 |
| | along with the tile caching, deletion, trans group pushes and pops | 15:53.30 |
| | can I share that with you? | 15:53.37 |
| Robin_Watts | great. | 15:53.46 |
| | pcls = the clist state. | 15:53.59 |
| | Is that per band? | 15:54.02 |
| mvrhel_laptop | yes | 15:54.04 |
| | yes about the = | 15:54.20 |
| | I don't know the answer to the other question | 15:54.32 |
| Robin_Watts | I wonder if there is a different pcls for each band. | 15:54.44 |
| | hence pcls->pattern_id might appear to change, but it's actually pcls that's changing. | 15:54.59 |
| | IYSWIM. | 15:55.13 |
| mvrhel_laptop | that could be | 15:56.12 |
| | Robin_Watts: patch was sent | 15:57.34 |
| | so I am running this with psdcmyk device at 300 dpi | 15:57.53 |
| | oh let me add the simplified file | 15:57.59 |
| | to the bug | 15:58.01 |
| | hold on Robin_Watts | 15:58.03 |
| | Robin_Watts: ok the file is with the bug | 16:01.30 |
| Robin_Watts | ok, patch applied. simple tasks take me a while when I try to apply a mupdf patch to gs etc :( | 16:03.40 |
| mvrhel_laptop | sorry about the tabs in the patch | 16:04.24 |
| | I had opened VS with tabs apparently | 16:04.36 |
| | Robin_Watts: so the patch you want to run with -Z? | 16:04.59 |
| | to see the debug statements of interest | 16:05.09 |
| | if you let it rip, you will see the repeated pattern during clist reading and where it explodes | 16:05.35 |
| Robin_Watts | There are 2 simplified files on the bug. | 16:06.08 |
| | Alex's and yours. I assume I should be using yours ? | 16:06.20 |
| mvrhel_laptop | also if you put a break point at during during clist writing of the patterns you will see the repeated tile writing | 16:06.24 |
| | yes, mine is simplier and related to the bug of rays | 16:06.35 |
| Robin_Watts | Alex's is only 3K though :) | 16:06.46 |
| mvrhel_laptop | ray unfortunately, reopened this bug with a new file and a new problem | 16:06.58 |
| | not sure why | 16:07.00 |
| | I should split this bug | 16:07.06 |
| Robin_Watts | So gs/debugbin/gswin32c.exe -sDEVICE=psdcmyk -o out.psd -r300 -Z? ../MyTests/Bug693365_simple.pdf explodes for me. | 16:08.01 |
| mvrhel_laptop | hmm let me see if alex's file has the problem | 16:08.02 |
| Robin_Watts | mvrhel_laptop: I am happy to work with yours :) | 16:08.12 |
| mvrhel_laptop | ok | 16:08.15 |
| Robin_Watts | Though, as I am a bear of small brain, I might try and shrink it further. | 16:08.48 |
| mvrhel_laptop | ok. | 16:09.44 |
| | Robin_Watts: one other issue that I have is that I don't see why the psdcmyk device would be an issue here | 16:10.02 |
| | if I do tiff32nc for example, the file runs fine | 16:10.12 |
| Robin_Watts | Does that keep writing/evicting the pattern too ? | 16:10.36 |
| mvrhel_laptop | yes | 16:13.30 |
| | Robin_Watts: need to get daughter out door | 16:13.39 |
| | bbiam | 16:13.42 |
| | Robin_Watts: ok back. so are you seeing the same sort of thing that I described? | 16:24.44 |
| Robin_Watts | I'm seeing a crash. I haven't tracked down where yet, still simplifying the file. | 16:25.07 |
| mvrhel_laptop | ok thanks. now I need to help in-laws. bbia longer m | 16:25.53 |
| Robin_Watts | mvrhel_laptop: I have a much simpler file that still crashes. | 16:53.53 |
| | Crashes in a different place in the transparency handling. | 16:54.34 |
| | The file contained the contents spread over several different pdf objects. i.e. /Contents[ 5 0 R 6 0 R 7 0 R ... ] | 16:55.20 |
| | by pulling the same contents into a single stream I could get the crashing to stop. | 16:55.33 |
| | This suggests to me that the problem is probably a memory corruption of some kind. | 16:55.54 |
| | The new crash I am getting would seem to suggest that too. | 16:56.07 |
| mvrhel_laptop | Robin_Watts: oh ok | 17:04.57 |
| Robin_Watts | Let me attach the simpler file to the bug. | 17:07.09 |
| | Attached. | 17:08.17 |
| mvrhel_laptop | Robin_Watts: ok grabbing it | 17:14.48 |
| | oh it is crashing in my debug statment | 17:16.30 |
| | Robin_Watts: ok this is interesting | 17:18.15 |
| | I should be able to track this down | 17:18.23 |
| Robin_Watts | Is it? | 17:18.24 |
| mvrhel_laptop | well, yes. much simplier | 17:18.33 |
| Robin_Watts | For me, it's crashing in pdf14_pop_transparency_group because ctx=0xcdcdcdcd | 17:18.46 |
| kens | uninitialised memory | 17:19.00 |
| | or variable | 17:19.08 |
| mvrhel_laptop | Robin_Watts: yes me to | 17:19.08 |
| Robin_Watts | kens: indeed. | 17:19.14 |
| | penum->clip_image=8 | 17:19.28 |
| mvrhel_laptop | Robin_Watts: need to head out for about 15 minutes. | 17:19.37 |
| Robin_Watts | 8 seems a suspicious number to me. Isn't that a bool? | 17:19.41 |
| mvrhel_laptop | this is the way my week is going to go... | 17:19.51 |
| kens | TIme for me to be off too, night all | 17:32.27 |
| Robin_Watts | ok, so penum->clip_image is a bitmask, and 8 makes sense. | 17:39.25 |
| mvrhel_laptop | ok back. let me dig into this | 17:41.18 |
| Robin_Watts | So gs_copydevice is being called from gs_pdf14_device_push, but no forwarding device is ever assigned. | 17:43.50 |
| | oh. | 17:44.08 |
| | A copydevice is being done from a forwarding device, and the ->forward field is not being copied maybe? | 17:44.35 |
| | no. | 17:45.47 |
| | ah, so that code is assuming that if we have a clip image, then the target to our forwarding device will be a pdf14 one, and it's actually an image8. | 17:47.54 |
| | I'm going to leave this to mvrhel_laptop I think. | 17:48.12 |
| mvrhel_laptop | Robin_Watts: ok. I will drag you back in if I need to | 17:53.40 |
| | thanks for helping me | 17:53.46 |
| Robin_Watts | sure. If you fix this problem, and it doesn't solve the larger one, let me know and I'll resimplify the file. | 17:54.02 |
| mvrhel_laptop | ok. Yes. this seems like a different issue | 18:04.00 |
| | very weird. the penum->clip_image test | 18:04.15 |
| | I added that code... | 18:04.29 |
| | removing it and the file runs fine. | 18:06.39 |
| | aha! | 18:11.31 |
| | so my test is faulty there Robin_Watts | 18:11.51 |
| | the clip device is installed if penum->clip_image && pcpath | 18:12.02 |
| | line 892 in gxipixel.c | 18:12.17 |
| Robin_Watts | OK. | 18:12.19 |
| mvrhel_laptop | and I am just testing on penum->clip_imag | 18:12.27 |
| | so let me get that fixed | 18:12.37 |
| | I suspect this is a different issue than the other one | 18:12.44 |
| | but maybe not | 18:13.12 |
| | hopefully not | 18:13.13 |
| Robin_Watts | Whenever I see code that magically knows what types of things are on the stack, it makes me worried. | 18:13.58 |
| | "If it's a monday, and the moon is full, it must be a clip device". | 18:14.23 |
| | For instance in this case, should it perhaps be: | 18:15.29 |
| | Or rather, should we be watching for penum->use_rop too? | 18:16.29 |
| | cos if penum->use_rop, then we know that there is a rop texture device on top of any clip image device there may be. | 18:16.55 |
| mvrhel_laptop | does that ever occur in pdf transparency? | 18:17.24 |
| Robin_Watts | Dunno. | 18:17.39 |
| mvrhel_laptop | I thought rops were all pcl | 18:17.47 |
| Robin_Watts | But I shouldn't need to know that to read the code and know that it's correct. | 18:17.55 |
| | We should have a better way of chaining devices, so that we can cope with these cases. | 18:18.50 |
| mvrhel_laptop | Robin_Watts: I guess what I need to do is to use a special op and drill down to the pdf14 device | 18:18.55 |
| Robin_Watts | A special op to 'get the next pdf14 device' would be nicer architecturally, I think. | 18:19.21 |
| mvrhel_laptop | did you type that at the same time or after me? | 18:19.42 |
| Robin_Watts | I was agreeing with you (so after you) | 18:20.04 |
| | but I'm not suggesting we need to actually do that now, just that it should be something we consider for the future. | 18:20.14 |
| mvrhel_laptop | ok. let me do that approach. much nicer I agree | 18:20.16 |
| | no, I think it should be done now | 18:20.26 |
| Robin_Watts | You know, for the time when we have no other bugs and lots of time to kill :) | 18:20.27 |
| mvrhel_laptop | it wont take long | 18:20.29 |
| Robin_Watts | OK, I'll not argue against neatness :) | 18:20.37 |
| mvrhel_laptop | otherwise it will never get done in my lifetime | 18:20.49 |
| Robin_Watts | Does this solve the larger bug? | 18:20.59 |
| mvrhel_laptop | let me check that | 18:21.06 |
| Robin_Watts | If it doesn't solve the larger bug, I'll set to work resimplifying. | 18:21.31 |
| mvrhel_laptop | Robin_Watts: this file does need that forwarding since it does to a push | 18:23.37 |
| | on the stack | 18:23.40 |
| | s/to/do/ | 18:24.01 |
| Robin_Watts | how are you solving this? We don't have pcpath at the point at which we need to test it do we? | 18:24.20 |
| mvrhel_laptop | no. I can't test it is what I am saying | 18:24.33 |
| Robin_Watts | ah, right. | 18:24.37 |
| mvrhel_laptop | let me do the special op | 18:24.48 |
| | then we will go from there | 18:24.54 |
| Robin_Watts | Can we do a quick crap test to check that the device name begins with pdf14 ? | 18:24.58 |
| mvrhel_laptop | I may actually have a special op for this | 18:25.12 |
| | that will work already | 18:25.19 |
| Robin_Watts | excellent. | 18:25.46 |
| | I added gxdso_device_child ages ago, so I could walk devices safely, but I'm not sure it's implemented everywhere. | 18:26.52 |
| | I can see gxdso_is_pdf14_device, which will tell us if a given device is a pdf14 one. | 18:27.46 |
| | Don't we also need a way of safely saying "is this a forwarding device?" | 18:28.08 |
| | If we had that we could walk down until we find a child device that responds to gxdso_is_pdf14_device | 18:28.38 |
| mvrhel_laptop | Robin_Watts: yes. this is what I was thinking | 18:31.10 |
| | however, that has to be the case | 18:32.10 |
| | at some point we have to hit the pdf 14 device | 18:32.20 |
| | and it has be forwarded from the parents | 18:32.32 |
| | if not, then something is wrong | 18:32.37 |
| Robin_Watts | mvrhel_laptop: So we have 2 options here. | 18:32.42 |
| mvrhel_laptop | so why do we need to check that? | 18:32.46 |
| | we would simply do the forwarding to the pdf14 device until we hit it | 18:33.09 |
| Robin_Watts | Ah, so you are 100% sure that we WILL have a forwarding device when we reach this point in the code? | 18:33.19 |
| mvrhel_laptop | yes. there is no other way for it to work | 18:33.30 |
| Robin_Watts | And we are 100% sure that all devices that forward are derived from gx_device_forward ? | 18:33.50 |
| mvrhel_laptop | it is either all ready a pdf14 device or we have a series of forwarding devices to one | 18:34.03 |
| Robin_Watts | Then you're right, it can be done with what you have already. | 18:34.18 |
| mvrhel_laptop | if someone made their own forwarding device in front of a pdf14 device they have big problems to deal with | 18:34.46 |
| | this would be one small problem on a long list | 18:35.00 |
| | that is their own custom type | 18:35.10 |
| | Robin_Watts: ok do you want to do this or do you want me to? | 18:35.42 |
| Robin_Watts | mvrhel_laptop: I'll do it if you want, but I'm perfectly happy to leave it to you. | 18:36.30 |
| | Just wanted to understand the proposed fix. | 18:36.35 |
| mvrhel_laptop | Please go ahead | 18:38.05 |
| | Robin_Watts: | 18:38.08 |
| Robin_Watts | ok. | 18:38.15 |
| mvrhel_laptop | tv is on volume 11 | 18:40.58 |
| Robin_Watts | and are they watching kwality programmes? Like reruns of Fraiser, Americans Most Explosive Cop Car Chases etc ? | 18:45.20 |
| | I can't get to my telly when the in laws are here. It's soul destroying :( | 18:45.46 |
| mvrhel_laptop | The Bourne legacy movie is on I think. | 18:46.20 |
| Robin_Watts | http://ghostscript.com/~robin/0001-Bug-693365-Add-find_pdf14_device-function-and-use-it.patch | 18:49.19 |
| | mvrhel_laptop: ^ | 18:49.24 |
| | Oh, that's surprisingly watchable. | 18:49.33 |
| | Full file still dies. | 18:50.29 |
| | So, I'll simplify again. | 18:50.57 |
| mvrhel_laptop | Robin_Watts: I would go ahead and commit that patch | 18:57.59 |
| Robin_Watts | ah, no, cos it doesn't work :( | 19:00.42 |
| | When we do gxdso_is_pdf14_device, the forwarding device doesn't understand the question. | 19:01.29 |
| | So it forwards it to its child. | 19:01.37 |
| | and that says "Yes, I'm a pdf14 device". | 19:01.45 |
| | So we think the parent is such a device. | 19:01.51 |
| | So... either we need another gxdso that doesn't forward, or we need to be more cunning. | 19:03.33 |
| | How would you feel about me amending gxdso_is_pdf14_device such that if a data pointer is given, it's a pdf14_device **, and the implementer of gsdxo_is_pdf14_device will fill it in if it's non NULL ? | 19:04.35 |
| | Hi ray_laptop. How are you feeling? | 19:06.15 |
| mvrhel_laptop | Robin_Watts: I am not sure I understand the last comment | 19:06.26 |
| Robin_Watts | mvrhel_laptop: I'll show you a new patch in a mo, and you can 'ew' at it. | 19:06.57 |
| mvrhel_laptop | ok | 19:07.02 |
| ray_laptop | Hi Robin_Watts (et el.): OK, but vertigo and drowsiness had me sleeping a lot yesterday -- only about 1 hour or so of work. | 19:08.32 |
| | the biggest issue is my eye not blinking. I can patch it closed, but that gets uncomfortable and doesn't work that well. And if I don't then it dries out rather quickly | 19:09.50 |
| | I had coffee this AM and the drowsiness is reduced. | 19:10.26 |
| | Robin_Watts: I see you and mvrhel_laptop have been digging into the '365 issue. | 19:11.00 |
| Robin_Watts | ray_laptop: Can you blink it manually or have you got eye drops? | 19:11.50 |
| ray_laptop | so rather that 'is_pdf14_device' it will really be 'get_pdf14_device' which just returns OK if it is (and it's target pointer was NULL) otherwise returns the pdf14 device ? | 19:13.11 |
| paulgardiner | ray_laptop: Nasty. Have you been given an estimate for how long you're likely to have to put up with that? | 19:13.12 |
| Robin_Watts | mvrhel_laptop: Updated patch in the same place. | 19:15.28 |
| ray_laptop | paulgardiner: if varies widely. Some people get past most of Bell's in 5 days or so. But when caused by shingles, it takes longer, usually 10. In some cases there are permanent problems (rare) but I've seen diaries of people where it takes > 1 month | 19:15.32 |
| | So, a note to all: if you've had chickenpox, I recommend the shingles 'booster' vaccine | 19:16.14 |
| mvrhel_laptop | I never had chickenpox | 19:16.58 |
| ray_laptop | even topical shingles is painful according to people I know that have had it (my Dad, my sister) | 19:17.00 |
| | this variant is not all that painful, but is quite inconvenient | 19:18.00 |
| paulgardiner | Well good luck with it. Hope you have the 5 day recovery. | 19:18.31 |
| mvrhel_laptop | Robin_Watts: ok I see what you did | 19:19.03 |
| | that makes sense | 19:19.14 |
| ray_laptop | paulgardiner: thanks | 19:19.16 |
| mvrhel_laptop | I have to head out now for a bit | 19:19.21 |
| | ray_laptop: yes. I hope you get better soon | 19:19.30 |
| Robin_Watts | mvrhel_laptop: I will commit this patch and then try to resimplify. | 19:19.39 |
| mvrhel_laptop | ok thank you | 19:19.53 |
| Robin_Watts | ray_laptop: It sounds like an ideal excuse to down tools until new year to me. | 19:19.56 |
| mvrhel_laptop | yes | 19:20.04 |
| Robin_Watts | Then when we get phoned by 532 saying "Has Ray died?" we can say "Well...." | 19:20.20 |
| | mvrhel_laptop: (For the logs) new simplified file attached. | 20:23.32 |
| | It's dying in the tile_rect_trans_simple with a null fill_trans_buffer as before. | 20:23.56 |
| | Running it under memento is informative. It crashes slightly earlier in pdf14_pattern_trans_render trying to call: ptile->ttrans->image_render | 20:25.41 |
| | ptile->ttrans is allocated, but image_render has never been assigned. | 20:26.19 |
| ray_laptop | Robin_Watts: image_render is supposed to be set in the begin_typed_image | 20:27.15 |
| | Robin_Watts: -ZL /might/ help | 20:27.28 |
| | Robin_Watts: in a debugger, you can set gs_debug['L'] just when it's playing back the tile | 20:28.15 |
| mvrhel_laptop | Robin_Watts: ok thanks! | 20:41.26 |
| | my afternoon is shot, so I will work on this later tonight | 20:41.41 |
| Robin_Watts | mvrhel_laptop: I'll keep burbling my findings into here, but I'll probably stop soon. | 20:42.32 |
| mvrhel_laptop | ok thank you for all your help | 20:42.48 |
| Robin_Watts | no worries. | 20:42.53 |
| | I wonder if it's because the image is 0 sized? | 20:47.17 |
| | "reading for bands (16,16)" Does that mean 'reading for band range 16 to 16' ? | 21:06.55 |
| | Forward 1 day (to 2013/12/19)>>> | |
IRC Logs