| | <<<Back 1 day (to 2011/07/17) | 2011/07/18 |
| ray_laptop | cryptopsy: is pptx PowerPoint ? | 01:30.08 |
| | cryptopsy: usually you pint to pdf (using something like primopdf or another gs based PDF writer) Then gs or mupdf can manipulate the PDF | 01:31.26 |
| cryptopsy | pptx is powerpoint | 01:35.46 |
| | how is mupdf and gs related, beside sharing the channel? | 01:36.03 |
| | it would be great if we could control mupdf from outside of it's interface | 01:36.19 |
| | but its great that it's very light | 01:36.33 |
| | i'd like to also have mupdf zoom the doc based on the window's size - is it wrong to think this way? | 01:37.02 |
| | when i want to browse multiple pages at a time i create a very tall window which forces to display multiple pages per the window | 01:37.35 |
| | xpdf called it 'initialZoom width' | 01:37.55 |
| Love4Boobies | Hey. I'm an expert in neither GS, nor GSView. However, I have some PS files and I can only view their first page. Should I link you to them so you can see what's wrong? | 04:38.34 |
| | The files themselves are ok, I've checked with other programs... | 04:38.50 |
| | Hmm, actually I suspect the new GSView beta. IIRC, I did open them with the previous version (not 100% sure). | 04:41.23 |
| ghostgum2 | If you can only see one page, then someone probably "printed" a multipage file to an EPS file, which by definition has only one page. | 04:49.30 |
| | Workaround in GSview is Options, Ignore DSC. | 04:49.50 |
| Love4Boobies | ghostgum2: Thanks, that did it :D | 05:00.17 |
| | Btw, pg. down will take me to the next page but pg. up won't take me to the previous one. | 05:02.48 |
| ghostgum2 | Correct, if you don't have correct DSC comments and appropriate page structure, then the only way to go to page N is to display all pages 1..N. | 05:10.22 |
| | If you do want random access, then convert it to PDF. | 05:10.36 |
| Love4Boobies | Makes sense | 05:16.42 |
| kens | chrisl have you looked at the TextAlphaBits issue SaGS reported overnight ? | 07:02.55 |
| chrisl | kens: it's fixed by Robin's a1ee78a6de94b8b4292b9ce3b71b54ed3ae7502b commit | 07:05.46 |
| kens | Ah, I was wondering because my old source here shows it Thanks. | 07:06.06 |
| chrisl | I've got for fix imported onto the 9.03 branch, but I haven't pushed it up to casper yet. | 07:06.48 |
| | s/for/the | 07:06.57 |
| kens | I see the commit on the branch now thanks. | 07:07.02 |
| | Sometime on the 15th or 16th someone has made a cmooit that breaks a pdfwrite nightly regression test as well :-( | 07:07.47 |
| | Oh, I'm going to close SaGS's bug too, since its assigned to me ;-) | 07:08.21 |
| chrisl | kens: do you know which commit breaks pdfwrite? | 07:22.34 |
| kens | Sadly no. | 07:22.49 |
| | The regression on the 14th was OK, the one on the 16th was not. | 07:23.01 |
| | But there were a lot of commits on the 15th | 07:23.09 |
| | I *susspect* its one of Robin's pattern changes but I'm not certain | 07:23.33 |
| | I'll update my source and try it. | 07:23.52 |
| | Just doing a clean and rebuild | 07:27.32 |
| chrisl | Not even 9 in the morning, and I'm already struggling to type..... :-( | 07:27.49 |
| kens | I always have tha tproblem ;-) | 07:28.05 |
| | (He says, immediately exhibiting it) | 07:28.22 |
| chrisl | :-) It bothers me when I lose the ability stuff I use regularly, like git commands! | 07:28.52 |
| Love4Boobies | chrisl: Or to type meaningful sentences, apparently :) | 07:31.31 |
| chrisl | Love4Boobies: true, very true :-( | 07:32.08 |
| kens | Deal with enough custoemr for whom English is a second language, and you develop the ability to interpret almost anything :-) | 07:32.10 |
| Love4Boobies | English is my 2nd language as well ^_^ | 07:32.44 |
| kens | I'm not criticising anyone, many of these customers use languages I have no inkling of, and their English is way better than my Japanese/Chinese/Korean/<insert exotic language> | 07:33.55 |
| | chrisl I don't know what setup marcos uses for the nightly regressions, but a quick test of pdfwrite on the master code (Windows 32-bit) doesn't reveal a problem. | 07:35.00 |
| chrisl | kens: I believe nightly uses the same invocation as a user "push" so you could try a clusterpush with what you have just now | 07:36.09 |
| kens | OK, I'll try that. | 07:36.19 |
| | chrisl its off, we'll see what happens | 07:37.49 |
| chrisl | Cool. Nothing of significance went into 9.03 on on those days, so I don't think I need worry on that front. | 07:38.35 |
| kens | It wasn't 9.03 I was worried about ;-) | 07:38.51 |
| | It was the fact that someone had introduced a regression into pdfwrite, and not fixed it, leaving it to me to pick up the pieces :-( | 07:39.16 |
| | Of course, its possible that it *doesn't* show up in the regular cluster tests, in which case it would be undertandable (but I'm still handing it back to whoever did it ;-) | 07:39.57 |
| chrisl | That would also suggest it would be worth knowing what the difference is between a normal push, and the nightly tests. | 07:40.42 |
| kens | Possibly the test doesn't get run except on nightly runs. | 07:40.59 |
| | coffee, back shortly | 07:54.49 |
| | chrisl that file is not reported as a failure on a regression run. Whether that's because there's a diference in the way the test is run, or the file simply isn't tested, I'll have to leave to Marcos. | 08:13.24 |
| | However, I see some alarming problems in the run. | 08:13.37 |
| | The QL PS3 CET tests 35-01, 36-01, 37-01 all fail 'error reading input file' on all devices. | 08:14.17 |
| | Err, sorry, 36-01 and 37-01 only | 08:14.58 |
| | FWIW they don;t fail for me on a simple test. | 08:17.47 |
| chrisl | kens: It's odd (but not outside the bounds of possibility) that they fail that way *only* for pdfwrite. | 08:19.54 |
| kens | I'm seeing those 2 files fail on all devices. | 08:20.13 |
| chrisl | Oh, yes, sorry, I misread | 08:20.29 |
| kens | Eg: | 08:20.39 |
| | The following 38 regression file(s) have started producing errors: | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.cups.300.1 gs macpro i7b Error_reading_input_file | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.pam.72.0 gs henrysx6 miles Error_reading_input_file | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.pbmraw.300.0 gs kilometers macpro Error_reading_input_file | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.pbmraw.300.1 gs i7a kilometers Error_reading_input_file | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.pbmraw.72.0 gs macpro peeves Error_reading_input_file | 08:20.40 |
| | tests_private/ps/ps3cet/36-01.PS.pdf.pkmraw.300.0 gs pdfwrite i7a peeves Error_reading_input_file | 08:20.41 |
| | Would you mind trying a push please ? To make sure its not me. | 08:21.07 |
| | I can't reproduce the problem here on Windows | 08:21.18 |
| chrisl | This is just the master/HEAD code? | 08:21.27 |
| kens | Not quite, it had my textwrite code, but that should not have caused problems with other devices. | 08:21.50 |
| | but otherwise, yes, its the master | 08:21.58 |
| | Ah, I had a changed cidfmap. That is probably the problem, forget it. | 08:22.43 |
| | I bet those files test fonts | 08:22.53 |
| chrisl | Okay, aborted..... | 08:23.32 |
| kens | Sorry about that, I thought I had reverted that change, I have now. | 08:23.49 |
| | More mail to marcos about the nightly regression failure. Now I can get back to something else. | 08:24.45 |
| | Well thank goodness that's out of the way. congratulations on finally getting the release out chrisl | 09:08.32 |
| chrisl | kens: Thanks, yeh, I feel like a month to recover from that "quicky release". | 09:10.00 |
| kens | But you've only got 2 weeks :-( | 09:10.12 |
| chrisl | *And* we've got to try to get all those issues fixed properly in master before then :-( | 09:10.56 |
| kens | Yes, I was going to say that. Especially the UTF/Unicode thing | 09:11.11 |
| chrisl | Well, there may not be complete a solution for that with the current approach | 09:11.49 |
| kens | I read the logs, but didn't really try to follow it | 09:12.04 |
| | Windows' Unicode handling makes my head hurt | 09:12.19 |
| chrisl | Basically, we're doing something a bit hacky and calling the wide char functions directly, instead of #defining UNICODE and letting the header file choose between the ASCII and wide char variants. | 09:13.21 |
| kens | Yes, that much I followed. I've done that before myself | 09:13.41 |
| chrisl | Now that works for almost everything except, apparently, for the Window title text on Windows7, and the only way I could get it to display correctly was to define UNICODE, which would potentially cause us other problems. | 09:15.10 |
| kens | That does sound more like a bug in WIndows 7 than anything else, to me. | 09:15.28 |
| chrisl | Well, except that the *A vs *W variants are not really part of the public API, so really they can behave any way MS cares to make them - using the published API, it works as documented. | 09:17.11 |
| kens | :-( | 09:17.29 |
| Robin_Watts | chrisl: Just reading the logs. | 09:18.21 |
| | We could swap to just calling the W variants directly. | 09:18.39 |
| chrisl | Robin_Watts: we do call the W variants directly, that's kind of the problem | 09:19.18 |
| Robin_Watts | No, at the moment we call a mixture. | 09:19.29 |
| | some 'A's, some 'W's, some unsuffixed ones. | 09:19.55 |
| chrisl | Oh, I see, so CreateMessage and co all get the *A and *W treatment? | 09:20.12 |
| Robin_Watts | The problem is that they broke something in Windows 7 that stopped what we were doing before working. | 09:20.49 |
| | So we need to move to a different combination. | 09:21.20 |
| | We could move to all unsuffixed, and set UNICODE, I guess. | 09:21.34 |
| | But we need to check that that doesn't have unwanted side effects. | 09:21.47 |
| chrisl | Robin_Watts: Well, sort of: as I said to kens, what we're doing is not using the "published" API, so the stuff is subject to change without notice | 09:22.07 |
| Robin_Watts | I guess. | 09:23.00 |
| chrisl | Ugh, windows.h is included in quite a few places :-( | 09:23.31 |
| kens | Hmm, imagine driving along and finding this behind you: | 09:56.52 |
| | http://www.youtube.com/watch?v=nZSBpFMWk-M&feature=player_embedded | 09:56.52 |
| | He needs to work o nthe secret lair some more though | 09:57.01 |
| Robin_Watts | kens, chrisl: I have a postscript question if I may... | 10:58.12 |
| kens | Go ahead, I think chris is away | 10:58.21 |
| | Oh no, he's back | 10:58.26 |
| Robin_Watts | http://ghostscript.com/~robin/cmykpattern.ps | 10:58.26 |
| | The image I have there works fine by itself. | 10:58.43 |
| kens | OK | 10:58.47 |
| Robin_Watts | put it in a pattern and it gets upset. | 10:58.51 |
| kens | AH, patterns in patterns | 10:58.57 |
| Robin_Watts | I suspect it's because of the /DataSource current file thing ? | 10:59.03 |
| kens | upset in what way ? | 10:59.03 |
| Robin_Watts | /ioerror in --image-- | 10:59.21 |
| | No, it's an image in a pattern | 10:59.37 |
| | not a pattern in a pattern. | 10:59.41 |
| kens | Hmm, yes, I suspect by the time the pattern is rendered, the current file has moved on. | 11:00.01 |
| | Let me play a moment | 11:00.09 |
| Robin_Watts | indeed. | 11:00.10 |
| | thanks. | 11:00.13 |
| chrisl | Robin_Watts: you'd be better making the data source a string for something as simple as that. | 11:00.27 |
| kens | phone | 11:00.27 |
| | agreed | 11:00.34 |
| Robin_Watts | I'm looking at the PLRM for how to do that now. | 11:00.44 |
| chrisl | /PaintProc { | 11:02.18 |
| | begin | 11:02.19 |
| | /DeviceCMYK setcolorspace | 11:02.21 |
| | 0 0 translate | 11:02.23 |
| | 10 10 scale | 11:02.25 |
| | << | 11:02.26 |
| | /ImageType 1 | 11:02.28 |
| | /Width 4 | 11:02.29 |
| | /Height 4 | 11:02.31 |
| | /BitsPerComponent 8 | 11:02.33 |
| | /Decode [0 1 0 1 0 1 0 1] | 11:02.35 |
| | /ImageMatrix [4 0 0 4 0 0] | 11:02.36 |
| | /DataSource < | 11:02.38 |
| | 00000000 000000ff 0000ff00 0000ffff | 11:02.39 |
| | 00ff0000 00ff00ff 00ffff00 00ffffff | 11:02.41 |
| | ff000000 ff0000ff ff00ff00 ff00ffff | 11:02.43 |
| | ffff0000 ffff00ff ffffff00 ffffffff> | 11:02.44 |
| | >> | 11:02.46 |
| | image | 11:02.47 |
| | end | 11:02.49 |
| | } | 11:02.50 |
| kens | Robin_Watts : the execution of PaintProc can occur at ay time, so you sren't supposed to use stuff which relies on currentfile, or has side-effects. Somewhere in teh PLRM it says that, or words like it. | 11:02.58 |
| chrisl | You might need to change the whitespace | 11:02.59 |
| Robin_Watts | chrisl: Brilliant. I had that, but with "/ASCIIHexDecode filter" on the end of the string and it wasn't working. | 11:03.33 |
| | thanks. | 11:03.34 |
| kens | p209 of the PLRM: | 11:05.03 |
| | The PaintProc procedure is expected to consume its dictionary operand and to use the information at hand to paint the form. It must obey certain guidelines to avoid disrupting the environment in which it is executed: | 11:05.03 |
| | ... | 11:05.03 |
| | It should depend only on information in the form dictionary andshould produce the same effect every time it is called. | 11:05.03 |
| | Obviously the effect of currentfile is different when the PaintProc is executed. | 11:05.34 |
| Robin_Watts | That makes entire sense, and I figured it was something like that. | 11:05.34 |
| chrisl | Robin_Watts: if you leave the filter in place make it an ordinary "()" string, rather than a hex string "<>" | 11:05.36 |
| Robin_Watts | but I lacked the experience in PS to know the syntax for the alternative way of doing it. | 11:05.50 |
| | chrisl: Ah, of course, thanks. | 11:06.01 |
| kens | Ah, well chris has you sorted there then, its pretty easy | 11:06.07 |
| Robin_Watts | I now have a simple example file. | 11:06.27 |
| kens | For a problem ? | 11:06.38 |
| Robin_Watts | halftoning planar cmyk stuff. | 11:06.56 |
| | I think it's only outputting single planes at the end or something. | 11:07.06 |
| | and I should be able to see what's going on now. | 11:07.19 |
| kens | Seems reasonable | 11:07.33 |
| Robin_Watts | Well, all the colours in that file should give 'pure' halftones. | 11:16.55 |
| | and indeed on the pamcmyk4 device, I get solid colors out. | 11:17.11 |
| | on the plank device (the same thing, but planar), I only get 3 of the 4 columns, the patterns are 1/4 of the width they should be and the halftones are horribly wrong. | 11:17.52 |
| | But aside from that it's perfect :) | 11:17.57 |
| kens | close enough, ship it :-) | 11:18.17 |
| Robin_Watts | Hmm. The build checks for a dirent.h file, and if it's there #defines HAVE_DIRECT_H | 13:30.54 |
| | My dirent.h file says: #error "dirent.h" not supported. | 13:31.18 |
| chrisl | Robin_Watts: that seems an especially dumb idea - shipping a file whose only purpose is to tell you file isn't supported. | 13:45.27 |
| Robin_Watts | actually, it's not that nonsensical. | 13:45.44 |
| | the dirent.h #includes <sys/dirent.h> | 13:45.59 |
| | the idea being that different sys/dirent.h's can be provided for different sys. | 13:46.15 |
| | and the default sys/dirent.h says "#error ...." | 13:46.33 |
| chrisl | But if you just leave the file out, that's pretty good indication that it's not support, I'd have thought. | 13:47.17 |
| | We could add a compile check for it in configure | 13:47.40 |
| Robin_Watts | Don't sweat it. | 13:47.50 |
| | I'm happy to hack it locally. | 13:48.01 |
| | If only I can figure out what to hack it too. | 13:48.08 |
| | The lack of a filing system makes ghostscript sad. | 13:48.19 |
| chrisl | You mean the lack of standard C library function calls makes GS sad...... | 13:49.01 |
| Robin_Watts | yeah. | 13:52.06 |
| chrisl | Kind of poor having (even) an embedded development environment that doesn't even comply with basic POSIX | 13:53.09 |
| Robin_Watts | actually, I've found another set of headers buried down that provides a posix.h and that includes enough for basic io | 14:02.37 |
| | gs/base/dirent_.h | 14:03.10 |
| | typedef struct direct dir_entry; | 14:03.21 |
| | does that look like a typo to you? | 14:03.27 |
| chrisl | It does, yes. | 14:04.07 |
| Robin_Watts | The icc34.h header file from lcms defines a load of types (icInt8Number etc). | 14:19.59 |
| | But in the #if defined(__GNUC__) || defined(__unix__) || defined(__unix) branch, it doesn't. It just includes sys/types.h | 14:20.36 |
| | sys/types.h isn't supposed to define such things is it? | 14:21.10 |
| | oh. no, ignore me. | 14:21.44 |
| kens | Morning ray_laptop | 14:35.56 |
| ray_laptop | morning, kens (and chrisl and Robin_Watts and tor) | 14:41.57 |
| Robin_Watts | Morning | 14:42.04 |
| chrisl | hiya ray_laptop | 14:42.12 |
| ray_laptop | chrisl: I haven't read email, but I assume that 9.03 is OK with UNICODE turned off ? | 14:42.19 |
| tor8 | hello | 14:42.21 |
| ray_laptop | 'cause I noticed you (chrisl) re-tagged 9.03 | 14:42.52 |
| chrisl | ray_laptop: yes, I did some quick tests, and chucked it over the wall...... | 14:42.53 |
| ray_laptop | chrisl: did you load it for the customer ???? | 14:43.08 |
| chrisl | ray_laptop: I don't have access, so I let them download it from my user area on casper | 14:43.39 |
| | ray_laptop: either you can stick the files up in the normal place, or you can e-mail me the details, and I'll do it. | 14:45.01 |
| ray_laptop | chrisl: I have created a ~customer/ on casper (/home/customer/public_html ) that you _should_ have priveleges to as member of gs-priv. I was going to put it in a sub-directory there: ghostscript-9.03.OoB | 14:45.35 |
| chrisl | ray_laptop: okay, give me a minute | 14:46.19 |
| ray_laptop | that way (similar to the way we "hide" things onhttp://www.artifex.com) we can distribute stuff to customers more easily. The default 'index.htm' there doesn't show the directory. | 14:47.05 |
| | of course, now that I mentioned the sub-directory here, we'll have to take 9.03 down (or rename it) shortly so that others won't try and use it | 14:47.47 |
| chrisl | ray_laptop: hmm, permission denied. | 14:48.32 |
| ray_laptop | chrisl: what does your 'groups' say ? | 14:49.00 |
| ray_laptop | relied on us all being in "gs-priv" | 14:49.17 |
| chrisl | ray_laptop: "chrisl gs-pub gs-priv" - I'm definitely in the group | 14:49.47 |
| ray_laptop | ls -l shows: drw-rw-r-- 2 ray gs-priv 4096 2011-07-15 19:41 ghostscript-9.03.OoB | 14:50.27 |
| | does it need to be 774 ? | 14:50.51 |
| chrisl | Oh, I can never remember the permissions :-( | 14:51.40 |
| ray_laptop | chrisl: in case that's it, please try again. I changed it | 14:51.48 |
| chrisl | ray_laptop: I'll a minute or two, I accidentally deleted the files from my user area on casper - idiot! | 14:53.23 |
| kens | goes for a caffeine top up | 14:54.17 |
| ray_laptop | chrisl: can you try to 'touch' a file in ~customer/___/ ? | 14:54.58 |
| chrisl | ray_laptop: Works! | 14:56.17 |
| Robin_Watts | ray_laptop: I can touch a file in there. | 14:56.22 |
| chrisl | ray_laptop: the files are now in the above directory, should I go ahead and rename it? | 15:00.28 |
| ray_laptop | chrisl: Sure. Just make sure and send Heinz an email with the new name (in case he didn't get it from your ~chrisl ) and cc support. | 15:03.00 |
| | so even if you have 'w' permission to a directory, you need 'x' permission to write to it. Obvious :-/ | 15:03.49 |
| chrisl | That's strange.... | 15:04.09 |
| ray_laptop | that's unix | 15:04.26 |
| | just 'cause it's more sane than windows, doesn't mean it doesn't have its quirks | 15:05.06 |
| chrisl | True, but I'd never noticed that one before | 15:05.27 |
| | ray_laptop: shall I push Sags's changes onto master? | 15:10.23 |
| ray_laptop | chrisl: sure. | 15:10.35 |
| chrisl | ray_laptop: done | 15:11.23 |
| ray_laptop | we probably need to open a bug and assign it to Robin_Watts to make the UNICODE stuff work. | 15:11.41 |
| | and we all need to make sure and identify other 'blocker' bugs (as I think you mentioned, chrisl ) | 15:13.16 |
| chrisl | ray_laptop: I did, I was going to mention it again during the IRC meeting tomorrow, to maybe catch everyone's attention. | 15:14.07 |
| henrys | ray_laptop:the bug you marked this morning got on my radar too, that's not a good one. | 15:14.08 |
| ray_laptop | I just bumped bug 692352 up to P1 for mvrhel (to at least look at prior to release) | 15:14.21 |
| kens | That may be mine actually | 15:14.50 |
| ray_laptop | kens: really ? in zusparam ?? | 15:15.04 |
| kens | Wel, I thought it was against pdfwrite | 15:15.23 |
| henrys | I wonder if lcms ever checks it's mallocs - not enough memory is one thing crashing another. | 15:15.32 |
| kens | Yes, should be a VMerror | 15:15.43 |
| ray_laptop | kens: that one is JPEG | 15:16.30 |
| chrisl | henrys: on the upside, gigabytes of ram going awol should be easier to track down than a few k | 15:16.47 |
| ray_laptop | of course, why it is using up 1.8Gb is another (separate issue) | 15:17.00 |
| kens | My mistake must have been thinking of another bug | 15:17.10 |
| ray_laptop | kens: np | 15:17.22 |
| kens | Oh, the title misled me, it says 'PDF conversion', when it measn PDF rendering | 15:18.05 |
| | The PDF isn't that excessive at 2.8Mb | 15:19.45 |
| henrys | Robin_Watts:what is the status of the ubuntu problem tkamppeter reported? Are we still on track to be put back in the distribution? | 15:20.39 |
| | that was a goal of this release. | 15:21.00 |
| Robin_Watts | henrys: I believe we're in regardless. | 15:21.13 |
| | I haven't looked back at it yet. | 15:21.19 |
| | Will do so in a bit. | 15:21.23 |
| henrys | okay just concerned about being in the distribution. | 15:23.13 |
| | Robin_Watts:you can also bounty the unicode stuff and cc: sags but we would like it before the release. | 15:25.46 |
| Robin_Watts | I'll try and bash on the release critical stuff before the meeting tomorrow. | 15:26.40 |
| | at the moment I'm banging on Company M stuff. | 15:27.29 |
| ray_laptop | that bug 692352 is interesting. Some images that are DCT (no problem there) but then it starts doing shading and the memory starts going up fast. | 15:29.23 |
| henrys | Robin_Watts:you are about to get more hardware stuff I'm afraid unless somebody else wants to have a whack at porting to a board. | 15:29.31 |
| Robin_Watts | henrys: cool. | 15:29.48 |
| kens | ray_laptop : I was about ot take a look, but maybe you can cut it down, since you're ahead ;-) | 15:30.02 |
| Robin_Watts | I'm away on holiday from 8th August for 18 days or something. | 15:30.13 |
| | so as long as it's not needed in that timescale, it's fine. | 15:30.44 |
| henrys | okay | 15:30.49 |
| ray_laptop | with -dPDFSTEP it starts around step 61000 | 15:31.36 |
| kens | ray_laptop : I htink th problem is the 'spotty' backdrop | 15:32.57 |
| ray_laptop | kens: if you want to poke around with '352, fine. I've got a couple of cust 532 issues... | 15:33.06 |
| kens | I can have a go, but its a bit outside my normal area. Michael's too probably. | 15:33.28 |
| | Except for the actual crash | 15:33.35 |
| ray_laptop | kens: well, maybe you can trace the allocations (-ZA is sort of noisy, but if you use PDFSTEP you can stop before the whole thing is done) | 15:36.43 |
| kens | This file is a lot more complex than it looks | 15:36.57 |
| Robin_Watts | If it's shadings, then it's probably mine. | 15:37.21 |
| | but any help that anyone can give would be appreciated. | 15:37.30 |
| kens | Let me play for a few minutes | 15:37.37 |
| | The file has patterns, shadings, patterns with shadings (I think), images and text. | 15:37.57 |
| | I'm trying to reduce the scale | 15:38.04 |
| henrys | kens:if you run out of time today assign it to alex for preprocessing - actually I think that should be the regular protocol for these kinds of bugs. | 15:39.31 |
| | that's what I've been doing anyway. | 15:39.44 |
| kens | OK, I'll mess for a bit since I've started, the nre-assign to Alex with anything I've found out | 15:40.04 |
| | This PDF file has > 100 colour spaces :-( | 16:01.53 |
| | And 3200 shadings | 16:02.26 |
| | It seems every spot on the page is done as a shading, and also (I think) as an image | 16:03.57 |
| | Each one in its own graphics state, carefully save/restored, even though the GS are the same apart from the CTM. | 16:04.46 |
| | I have a sneaky suspicion that there is a problem with q/Q balancing. It looks like each dpot (or circular feature) is drawn inside two 'q' (gsave) but only does 1 grestore. | 16:05.57 |
| | Which probably explains the explosion in memory. | 16:06.09 |
| | Oh dear..... It seems the file was produced by Adobe InDesign CS4..... | 16:11.02 |
| Robin_Watts | Hey mvrhel2 | 16:11.40 |
| mvrhel2 | good morning Robin_Watts | 16:11.51 |
| Robin_Watts | I spent some time this morning making an example file to show problems with the planar halftoning stuff. | 16:12.07 |
| | simple file with a pattern with an image in. | 16:12.14 |
| mvrhel2 | oh great | 16:12.19 |
| Robin_Watts | a 4x4 image that uses each combination of the 0/1 component-valued colours. | 16:12.53 |
| | (that was poorly expressed, but you know what I mean.) | 16:13.06 |
| mvrhel2 | I understand | 16:13.11 |
| chrisl | kens: CS4 shipped in 2008, I find it hard to believe if it was really making files as buggy as you suggest we wouldn't have fallen over it by now. | 16:13.16 |
| kens | It is an unusually complex file. | 16:13.31 |
| | I suspect we don't care if we end the job nested in gsaves. | 16:13.55 |
| Robin_Watts | The planar stuff only shows 3 out of the 4 columns, and then at 3/4 of the width they should be. | 16:13.56 |
| | with halftones that aren't right. | 16:14.06 |
| ray_laptop | kens: how much RAM does it take to complete the job ? | 16:14.19 |
| kens | No idea. | 16:14.25 |
| chrisl | kens: I thought we issued a warning for unblanced q/Q | 16:14.30 |
| kens | I haven't let it cokplete yet | 16:14.33 |
| | chrisl possibly when we grestore too many times ? | 16:14.49 |
| ray_laptop | chrisl: the warning only happens at the end of a file | 16:14.54 |
| kens | ray_laptop : at 72 dpi it eats as much memory as 600 dpi and crashes. | 16:15.04 |
| chrisl | ray_laptop: it tops out at about 3.8Gb or thereabouts for me, and I don't get an unbalanced q/Q warning when it completes | 16:15.32 |
| ray_laptop | chrisl: actually too many 'Q's are detected, but extra 'q's are only at the end of the page | 16:15.36 |
| mvrhel2 | Robin_Watts: ok can you share the file with me. I am going to fix one more bug/issue that related to source gray to device CMYK that I want to get into 9.04 then I will jump back on the planar/HT issue | 16:15.43 |
| Robin_Watts | sure. | 16:15.51 |
| | mvrhel2: http://ghostscript.com/~robin/cmykpattern.ps | 16:16.17 |
| kens | ray_laptop : well perhaps I'm wrong, but I see *many* cases where there are a group of operations that use one more 'q' than 'Q'. And there are a lot of these groups | 16:16.19 |
| ray_laptop | chrisl: if you do -dPDFDEBUG are there a bunch of 'q's at the end ? | 16:16.20 |
| kens | doesn't have 3.8 Gb to spare. | 16:16.35 |
| chrisl | ray_laptop: running now, it does take a while....... | 16:16.57 |
| ray_laptop | chrisl: I'll bet | 16:17.04 |
| | I think we may warn of too many 'q's at the end of a Form (exiting a 'Do') | 16:17.36 |
| | alexcher would know better | 16:17.44 |
| mvrhel2 | ok got it | 16:17.48 |
| kens | chrisl actually I think I see the missing 'Q' operations, so its not that. | 16:18.02 |
| chrisl | ray_laptop, kens: Indeed, -PDFDEBUG suggests the q/Q's are okay. | 16:18.37 |
| kens | One of them (in groups) was tacked onto the end of a /BDC | 16:18.57 |
| ray_laptop | kens: did you try -ZA ? Using it with -K should let you stop before it eats your computer | 16:18.58 |
| kens | ray_laptop : that's the problem it gets so slow its unusable. | 16:19.18 |
| chrisl | Also running with -dNOINTERPOLATE and/or -dNOTRANSPRENCY doesn't make a notable difference | 16:19.19 |
| kens | I removed all the obvious images, so its not them, its somethign crazy about hte (hundreds) of little ellipses. | 16:19.49 |
| ray_laptop | kens: -K will cause it to stop (VMerror). I suggest -K500000 | 16:19.53 |
| kens | OK, let me see | 16:20.01 |
| | ray_laptop : causes a GPF :-) | 16:20.45 |
| | Probably the same problem as the original report | 16:20.57 |
| ray_laptop | kens: well, that was the other part of the problem | 16:21.04 |
| kens | <sigh> Wasn't a debug build :-( | 16:21.30 |
| ray_laptop | I'm going to grab a cuppa -- bbiab | 16:21.32 |
| | kens: yeah, -ZA only works on debugbin/gswin32c | 16:21.51 |
| kens | I know, I figured that out, my fault for using the wrong directory | 16:22.08 |
| | Huh, 16 Mb of output :-( | 16:23.33 |
| alexcher | ray_laptop: We detect and discard excessive q's. | 16:23.35 |
| kens | alexcher : My fault, its a red herring | 16:23.47 |
| chrisl | kens: is that all? The entire job dumps 284Mb from -ZA! | 16:24.13 |
| kens | Yes, but I limited the memory per Ray's suggestion to 500000 | 16:24.32 |
| | crashes in gs_malloc(lcms) exceeded limit | 16:24.52 |
| | I think someone better than me with the memory manager is going tohave to look at the usage problem | 16:25.49 |
| | OK I have to go, I haven't found anything useful, so I'll assign this to Alwex per henry's instructions. | 16:29.26 |
| | Hmm, or maybe I shuld leave it with Michael, to solve the crash. I think this maybe should be 2 bugs. | 16:29.46 |
| henrys | or Alex is fine ;-) | 16:29.47 |
| kens | Alex is even better :-) | 16:29.57 |
| | Been a long day | 16:30.02 |
| henrys | I think Alex should "front end it" and then reassign it as necessary. | 16:30.45 |
| | I'd like to pull the lx5000 device before the release - chrisl and I are both waiting for the other to do it ;-). Want me to do it chrisl? | 16:34.57 |
| ray_laptop | henrys: can I pull the wtsimdi device too ? | 16:35.24 |
| henrys | yes but you need to update the language makefiles too. | 16:36.20 |
| ray_laptop | henrys: np. be glad to (if we can get rid of it) | 16:37.05 |
| chrisl | henrys: it's on my list, I won't complain if you do it, though | 16:37.16 |
| henrys | chrisl:okay thanks | 16:37.32 |
| kens | FWIW 8.71 uses a lot of memory too, but nowhere near as much, for me it peaks at 1.2Gb which is stilll a lot. also it doesn't (unsurprisingly) crash | 16:39.07 |
| Robin_Watts | mvrhel2: When you get yourself free of stuff, can we talk about the stars.pdf bug please ? | 16:39.14 |
| kens | So anyway, goodnight all, time for me to go off. | 16:39.22 |
| Robin_Watts | night kens | 16:39.44 |
| mvrhel2 | Robin_Watts: while I am waiting for my bmpcmp to finish up we can do it | 16:39.53 |
| ray_laptop | g'nite, kens | 16:39.54 |
| henrys | ray_laptop:looks like you can close 692143 I think marcos wanted you to check it. | 16:41.13 |
| Robin_Watts | It looks to me like were using the ptile->cdev != NULL case. | 16:41.19 |
| | That is to say, each pattern has a clist in in order to achieve transparency. | 16:41.35 |
| mvrhel2 | ok. that should work well in this file I would think | 16:42.06 |
| | since each pattern is not drawn too many times | 16:42.18 |
| Robin_Watts | There are 6 stars on the page, and I see 6 calls to gx_trans_pattern_fill_rect with x=0, y=0, w=5953, h=31 with a phase of (0,0) | 16:42.36 |
| | Then I see 6 calls to gx_trans_pattern_fill_Rect with x=0, y=0, w=5953, h=31 with a phase of (0,31) | 16:42.58 |
| | Then I see 6 calls to gx_trans_pattern_fill_Rect with x=0, y=0, w=5953, h=31 with a phase of (0,62) | 16:43.01 |
| | Which sounds plausible. | 16:43.15 |
| mvrhel2 | ok | 16:43.39 |
| Robin_Watts | I think the problem is, therefore, that we are blending loads more than we actually need to. | 16:43.40 |
| mvrhel2 | what does the profiler show? | 16:43.55 |
| Robin_Watts | The profiler shows 50% of CPU time in the pdf14 blending function. | 16:44.10 |
| mvrhel2 | ah | 16:44.15 |
| Robin_Watts | Now, we did some code as part of this work to allow for tiles having a subrectangle, and us only tiling that subrectangle. | 16:45.04 |
| mvrhel2 | yes | 16:45.21 |
| Robin_Watts | does that not apply in this case ? | 16:45.35 |
| | (was that just in the transparent, but not clist case?) | 16:45.47 |
| mvrhel2 | that is what I am wondering now | 16:46.17 |
| | that width seems to be the whole width of the page? | 16:46.44 |
| | not the width of the drawn star | 16:46.55 |
| Robin_Watts | sounds like it to me. | 16:46.58 |
| | Because I get 6 calls with the same values. | 16:47.10 |
| mvrhel2 | yes | 16:47.18 |
| | and the starts are different sizes yes | 16:47.24 |
| Robin_Watts | yes. | 16:47.29 |
| mvrhel2 | it seems to be the whole band size | 16:47.32 |
| Robin_Watts | sounds like it to me. | 16:47.40 |
| mvrhel2 | ok. so during the clist writing we need to add in that new bounding box information | 16:48.05 |
| | and make sure we draw with the proper offset during the reading | 16:48.25 |
| | good job figuring this out. this has to be the issue | 16:48.49 |
| Robin_Watts | The key thing is that we need to get in early enough to stop the pdf14 compositor buffers being created, AIUI. | 16:49.26 |
| | (or being created too large) | 16:49.37 |
| mvrhel2 | yes, I need to review where the size information is determined in the non-clist case | 16:50.02 |
| Robin_Watts | Ah, OK. you're at the same stage that I am. | 16:50.11 |
| mvrhel2 | to you know where that was? | 16:50.12 |
| | I wrote it and dont remember :( | 16:50.31 |
| Robin_Watts | when I worked with this stuff before I never had to see how it was generated, I just had to use it. | 16:50.34 |
| mvrhel2 | let me look and see if I can find | 16:50.53 |
| Robin_Watts | ptile->ttrans->rect is where it ends up being stored, AIUI. | 16:50.55 |
| mvrhel2 | it | 16:50.55 |
| ray_laptop | so the rect should be a subset of the pattern Width and Height | 16:52.05 |
| Robin_Watts | Given that we need it in the non ttrans case, should we move the rect up into ptile ? | 16:52.15 |
| | It may not be easy to obtain the information though. | 16:53.49 |
| ray_laptop | Robin_Watts: well, the transparency case is what's biting us now and fixing/changing (right before release) the non-trans case is probably better left 'til later (IMHO) | 16:54.01 |
| mvrhel2 | ray_laptop: the issue was that the pattern pushes a trans group that is the full page | 16:54.02 |
| | and then just draws in one small area | 16:54.12 |
| ray_laptop | mvrhel2: yes, I recall | 16:54.15 |
| | and I thought you collected the 'marked' bbox during the drawing | 16:54.39 |
| Robin_Watts | ray_laptop: He does. For the 'ttrans' case. | 16:54.48 |
| mvrhel2 | that is just what I was thinking. | 16:54.50 |
| ray_laptop | but the 'stars' _is_ trans, rught ? | 16:55.08 |
| mvrhel2 | it is in a clist | 16:55.17 |
| ray_laptop | s/rught/right/ | 16:55.18 |
| Robin_Watts | The stars is clist trans, not ttrans. | 16:55.23 |
| ray_laptop | OK. I see, so the clist painting isn't collecting a bbox | 16:55.56 |
| Robin_Watts | I fear the mechanism that he uses to gather the rect in the ttrans case is NOT available to us in the clist trans case. | 16:55.57 |
| mvrhel2 | the thing is, why would blending be that expensive, I should end up skipping the unmarked locations during the blending | 16:56.02 |
| | I realize it is a wasted operation but I am not really doing any blending for those points | 16:56.30 |
| Robin_Watts | Right. | 16:56.36 |
| | So it sounds like there is a separate issue there. | 16:56.53 |
| mvrhel2 | yes | 16:57.00 |
| ray_laptop | mvrhel2: you still have to look at each pixel, right ? (or does pdf_mark_fill_rect keep a bbox of marked areas) ? | 16:57.03 |
| Robin_Watts | but that might be one that's easier to fix. | 16:57.07 |
| mvrhel2 | ray_laptop: I forget how in the case were we create a tile how I found the bbox | 16:57.41 |
| ray_laptop | mvrhel2: I was asking about the blending. Do we collect a box for the actual area that needs blending when we pop ? | 16:58.49 |
| mvrhel2 | ray_laptop: I don't believe so | 16:59.44 |
| | I think it goes over the whole group | 16:59.54 |
| | but I would need to double check thtat | 17:00.07 |
| | hold on | 17:00.10 |
| ray_laptop | mvrhel2: so then, you'd have to "look" at every pixel during blending. | 17:00.15 |
| mvrhel2 | yes I think that is what it does now | 17:00.26 |
| | I think | 17:00.32 |
| | I need to look | 17:00.34 |
| | hold on | 17:00.36 |
| Robin_Watts | Now I'm confused. | 17:00.57 |
| | mvrhel2 said: "I should end up skipping the unmarked locations during the blending". From that I assumed that you had a 'marked' bbox. Are you now saying you don't ? | 17:01.36 |
| mvrhel2 | hold on | 17:02.00 |
| Robin_Watts | holding, sorry. | 17:02.06 |
| mvrhel2 | let me look at the code for sec | 17:02.07 |
| ray_laptop | is glad that I am not the only one that has to go check the code ;-) | 17:03.03 |
| mvrhel2 | so the composition occurs over the intersection of the bbox for the top of the stack and the next on the stack groups | 17:03.46 |
| | so, if the bbox for the pattern is large it will go over the whole thing | 17:04.01 |
| | my suspicion is that the bbox for the pattern is the whole band size | 17:04.26 |
| Robin_Watts | Yes. | 17:04.33 |
| mvrhel2 | even though it should be smaller. | 17:04.34 |
| | we need to make this logic a bit smarter | 17:04.46 |
| | so that we have a drawn bbox | 17:04.58 |
| Robin_Watts | just to be clear, by "it should be smaller" you mean "we should add some code to make it smaller" | 17:05.00 |
| mvrhel2 | well we have to allocate the size of the group buffer | 17:05.16 |
| Robin_Watts | rather than "there should be code in there that makes it smaller already" | 17:05.19 |
| mvrhel2 | we don't know where we will draw | 17:05.31 |
| Robin_Watts | indeed. | 17:05.37 |
| mvrhel2 | but after we have drawn we should have a range | 17:05.45 |
| | and we could be smart about the blending when we pop | 17:05.53 |
| Robin_Watts | Ah, you mean after we call the clist rendering functions, we'd hope that we should have a bbox. | 17:06.14 |
| mvrhel2 | this I believe is how this problem should be handled | 17:06.19 |
| Robin_Watts | and then just blend that. | 17:06.20 |
| mvrhel2 | yes | 17:06.28 |
| Robin_Watts | How would the clist rendering functions return us such a bbox ? | 17:06.46 |
| | or are you saying the buffer that the clist renders into can collect us a bbox ? | 17:07.22 |
| mvrhel2 | hold on let me write for a sec | 17:07.38 |
| | so we push the buffer size that the clist indicates that we need to push for the group. we then execute the drawings that we have to do in the group. all of these go through mark_fill_rectangle. we keep track of where we drew, updating a bbox that contains where we have drawn. when we pop the group, we will then know over what range we should blend with the group that is under us in the... | 17:09.29 |
| | ...stack (and in fact have its drawn group bbox which we will update also) | 17:09.30 |
| | so all of these changes need to be down in the gdevp14.c and gxblend1.c files | 17:10.00 |
| | really there is nothing to do in the clist or with the pattern code | 17:10.13 |
| | this is a general fix for the transparency code | 17:10.28 |
| | ok done typing. sorry | 17:10.37 |
| Robin_Watts | no worries. | 17:10.54 |
| | That sounds entirely plausible. | 17:11.00 |
| mvrhel2 | It should help transparency in general | 17:11.24 |
| | Is this something that has to be done for 9.04? | 17:11.51 |
| | for Ubuntu? | 17:11.56 |
| Robin_Watts | when you say "and in fact have its drawn group bbox which we will update also", the "drawn group bbox" is a transparency thing ? | 17:12.00 |
| mvrhel2 | i.e. till | 17:12.02 |
| Robin_Watts | mvrhel2: Yes, ideally. | 17:12.07 |
| | This is the bug that caused us to be taken out. | 17:12.20 |
| mvrhel2 | yes the drawn group bbox | 17:12.26 |
| Robin_Watts | mvrhel2: Is this an easy thing to do? a) for you, b) for someone with no experience of the internals of the transparency code ? | 17:13.07 |
| mvrhel2 | so the top of the stack (tos) will have a drawn group bbox and so will the next on the stack (nos) | 17:13.22 |
| | Robin_Watts: I be you could do it pretty easily | 17:13.36 |
| Robin_Watts | top of stack! next on stack! | 17:13.38 |
| | I'm learning already :) | 17:13.44 |
| | I'd wondered what tos and nos were :) | 17:13.54 |
| mvrhel2 | ok so you are halfway there :) | 17:14.04 |
| | do you want me to show you where you will need to do the fix? | 17:14.37 |
| Robin_Watts | any pointers you can give me would be appreciated. | 17:14.55 |
| chrisl | mvrhel2, Robin_Watts: (sorry to butt in) I thought it was planned to maintain a bbox during clist *writing* so that on playback we can allocate accurately sized buffers? | 17:15.37 |
| mvrhel2 | ok. Let me type them off in an email to you as it will be easier and less prone to typos | 17:15.41 |
| | If we can do that, that would be fine | 17:16.10 |
| | i.e. bbox during clist writing | 17:16.19 |
| | I am fine either way | 17:16.26 |
| | in fact that would be better | 17:16.34 |
| Robin_Watts | ok. It looks to me like pdf14_mark_fill_rectangle already keeps a rectangle | 17:16.35 |
| ray_laptop | chrisl: that was actually an enhancement bug | 17:16.36 |
| mvrhel2 | do avoid doing that allocation | 17:16.38 |
| | s/do/to/ | 17:16.50 |
| | Robin_Watts oh is it? | 17:16.58 |
| Robin_Watts | or two in fact. | 17:17.00 |
| | line 4122 | 17:17.12 |
| | buf->rect | 17:17.27 |
| | line 4132 buf->bbox | 17:17.38 |
| mvrhel2 | oh yes | 17:17.51 |
| chrisl | Well, I think both approaches would be beneficial, but the getting the bbox during clist writing looks like the more important one to me - given that the clist case is the limited memory case. | 17:17.54 |
| mvrhel2 | ok then this may already be doing this | 17:17.57 |
| ray_laptop | see bug http://bugs.ghostscript.com/show_bug.cgi?id=691607 | 17:18.10 |
| Robin_Watts | Oh, wait... buf->rect is the bounding box of the buffer. | 17:18.15 |
| mvrhel2 | Robin_Watts: put a break point at pdf14_compose_group | 17:18.20 |
| | and see what the range is that it is blending over | 17:18.31 |
| chrisl | ray_laptop: I knew I remembered it from somewhere! | 17:18.33 |
| Robin_Watts | so 4122 is doing what peter would do with a fit_copy macro (or something equally macrotastic) | 17:18.56 |
| | 4132 is keeping the actual marked bbox in buf->bboc | 17:19.15 |
| | x | 17:19.17 |
| ray_laptop | chrisl: but that one was a little more advanced in that it also called for painting in 'non-trans' mode outside the area that needed transparency | 17:19.21 |
| mvrhel2 | oh that is assigned to me | 17:19.35 |
| Robin_Watts | ok, I'm in pdf14_compose_groupd | 17:19.59 |
| mvrhel2 | Robin_Watts: see if when you get the compose group for one of the pattern tiles if it is the whole band that is getting blended | 17:20.35 |
| Robin_Watts | Right. rect = 0,0 5953,31 | 17:20.55 |
| | bbox= 5953,31 0,0 | 17:21.07 |
| mvrhel2 | line 297 is the actual loop | 17:21.10 |
| Robin_Watts | so that's looking good. | 17:21.15 |
| mvrhel2 | looking good for some optimization | 17:21.26 |
| Robin_Watts | For nos both are 0, 0 5953,31 | 17:22.05 |
| mvrhel2 | Robin_Watts: and in the loop at line 297 is it going over the whole buffer? | 17:23.10 |
| Robin_Watts | rect_merge(nos->bbox, tos->bbox) leaves nos->bbox being the full buffer. | 17:23.41 |
| | And yes, that means we do the whole buffer. | 17:24.15 |
| mvrhel2 | so what you will want to do is to collect a drawn_bbox which keeps track of what area has been drawn into in a group. so that when it is popped we only compose that into the nos | 17:24.20 |
| | and update the nos drawn_bbox to include the part that was popped into it | 17:24.39 |
| | in case we have a stack of these things | 17:24.46 |
| Robin_Watts | mvrhel2: Actually... the loop bounds are unaffected by the bbox entirely. | 17:25.03 |
| | mvrhel2: I believe that the bbox field is exactly that area. | 17:25.25 |
| mvrhel2 | the thing that bothers me is that when the put image occurs at the end, we do have a bbox of what we have drawn into | 17:25.42 |
| | so we must have this information already | 17:25.52 |
| | hold on | 17:25.54 |
| Robin_Watts | I think I know what the problem is. | 17:26.05 |
| | We should find the intersection of tos->bbox and nos->bbox, and then intersect that with the loop bounds. | 17:26.37 |
| mvrhel2 | look at the rect | 17:26.59 |
| | Robin_Watts: ok | 17:27.14 |
| Robin_Watts | The rect's are the actual sizes of the buffer. | 17:27.17 |
| | the bboxes are the areas that have been marked. | 17:27.23 |
| mvrhel2 | ah | 17:27.25 |
| Robin_Watts | tos has an invalid bbox (i.e. it hasn't been marked at all) | 17:27.48 |
| | nos has a valid bbox (it has been marked, presumably with the background or something) | 17:28.07 |
| mvrhel2 | ok. I see. in pdf14_pop_transparency_group we are using the rect and not the bbox | 17:28.44 |
| | good grief how was that missed | 17:28.50 |
| | ok, well that should be easy to get fixed for 9.04 | 17:29.09 |
| Robin_Watts | The existing code correctly combines the union of the two bboxes (and writes that into nos->bbox) | 17:29.22 |
| mvrhel2 | ok | 17:29.30 |
| Robin_Watts | but it fails to take the intersection and limit the loop bounds by that. | 17:29.56 |
| | I was going to fix it purely in pdf14_compose_group | 17:30.13 |
| | but are you saying it should be done higher in pdf14_pop_transparency_group ? | 17:30.32 |
| | Right, yes, I see. | 17:31.00 |
| | So it should be changed in pdf14_pop_transparency_group. | 17:31.12 |
| | I'll give that a whirl. | 17:31.15 |
| mvrhel2 | yes exactly | 17:31.46 |
| | firefox crash while looking at bmpcmp results.... | 17:39.08 |
| Robin_Watts | Visual Studio has soiled itself. I need to do a rebuild. | 17:39.13 |
| mvrhel2 | ha | 17:39.22 |
| | ok. I think I have the rendering intent stuff done. had some progressions, fixed a customer bug and added new features that other customers wanted. | 17:46.15 |
| ray_laptop | mvrhel2: GREAT !!! | 17:47.10 |
| Robin_Watts | Damn. It's really screwed itself. Got to reboot. bbs. | 17:47.15 |
| ray_laptop | mvrhel2: does it work with NumRenderingThread > 1 ? | 17:47.30 |
| | i.e., does it match NumRenderingThreads=0 output | 17:48.10 |
| mvrhel2 | ray_laptop manages to rain on my parade... :) | 17:48.10 |
| | need to check that | 17:48.14 |
| | it should though | 17:48.31 |
| | going to push it now though and then I will check MT | 17:48.54 |
| | oh ray_laptop: I was wondering if you could take a look at a bug for me | 17:50.38 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692105 | 17:50.55 |
| | for some reason the PDF file errors out after increasing GS_CLIENT_COLOR_MAX_COMPONENTS | 17:51.41 |
| | the PS file works fine | 17:51.50 |
| | testing MT case now | 17:55.10 |
| | are we regression testing NumRenderingThreads>0 now? | 18:00.31 |
| | ok MT case looks good | 18:01.30 |
| ray_laptop | mvrhel2: I have to run a quick errand -- then I'll take a look at the bug. | 18:03.12 |
| mvrhel2 | ray_laptop: ok thanks | 18:03.46 |
| | hmmm I did not see that warning during my clusterpush I think | 18:23.09 |
| | now my visual studio seems to have soiled itself too | 18:29.47 |
| Robin_Watts | hmm. Simply changing bbox to rect doesn't work. | 18:35.08 |
| | nothing is rendered at all. | 18:35.17 |
| | tkamppeter: We have a line on what's going wrong with stars.pdf. Am trying to fix it now. | 18:37.50 |
| tkamppeter | Robin_Watts, great. | 18:39.34 |
| mvrhel2 | bbiaw | 18:44.05 |
| Robin_Watts | mvrhel2: I have something. clusterpushing it in a mo. | 20:32.25 |
| mvrhel2 | great | 20:35.23 |
| | I have to head out. bbiab | 20:35.30 |
| Robin_Watts | cyl. | 20:36.10 |
| henrys | Robin_Watts:is the pattern issue the only open problem with planar - how much testing has been done? | 21:10.33 |
| ray_laptop | henrys: I think the pattern issue Robin_Watts was working on was to address the re-opened 'stars.pdf' performance issue | 21:14.43 |
| | henrys: I don't think it relates to planar at all | 21:15.05 |
| | but that was just today -- previously he had been looking into making the pattern accum device operate in planar mode | 21:16.08 |
| henrys | no I think there is a problem with planar and the pattern accumulator discovered in the "rops" test file. | 21:23.49 |
| | oh sorry I didn't read your last sentence. | 21:24.56 |
| | I know he's not working on it today. | 21:25.18 |
| | Robin_Watts:a new board should be sent out next week. I hope you'll receive it before you go on vacation and can start when you return. If you want to do something different let me know. If you think it won't make it before you leave then we should do something else. | 22:00.22 |
| Robin_Watts | henrys: The pattern accumulator problem is the only *known* problem. | 23:12.08 |
| | but no, it needs more testing. | 23:12.28 |
| | henrys: OK. These boards have been turning up fairly quickly. | 23:12.48 |
| henrys | thanks | 23:13.51 |
| Robin_Watts | With my fix in, stars.pdf completes in 30 mins. | 23:14.00 |
| | and looks right. | 23:14.10 |
| | Unfortunately it also causes lots of SEGVs. | 23:14.22 |
| | I have an electrician due in tomorrow to wire in a second RCD to try and avoid the solar panels tripping the rest of the house, so bear with me falling off the net. | 23:24.45 |
| henrys | okay, it looks like acrobat is pretty slow 600 dpi rendering but nowhere near 30 minutes. | 23:27.26 |
| Robin_Watts | I think I may have a fix for the SEGVs. | 23:33.33 |
| | I'll re-profile it tomorrow. | 23:33.47 |
| | the hotspot may have shifted somewhere else. | 23:33.58 |
| | (29 minutes 5seconds was 720dpi) | 23:34.13 |
| | and I'll try and look at the UNICODE thing. | 23:34.52 |
| henrys | the 720 dpi rendering is around 3 minutes on acrobat | 23:41.55 |
| | Forward 1 day (to 2011/07/19)>>> | |
IRC Logs