| | <<<Back 1 day (to 2012/02/20) | 2012/02/21 |
| Robin_Watts | ray_laptop: (For the logs) Wow! Excellent. | 01:04.38 |
| mfwitten | Anybody know a `malc'? | 06:45.33 |
| Robin_Watts | mfwitten: Yes, malc often arrives here, why? | 10:11.04 |
| sebras | Robin_Watts: still tied up in gs? | 10:28.08 |
| Robin_Watts | sebras: No. Tied up in mupdf :) | 10:28.36 |
| sebras | Robin_Watts: when you have time, have a look at sebras/master and see if those things are ok. | 10:31.31 |
| Robin_Watts | The XML looks plausible. | 10:32.35 |
| sebras | Robin_Watts: also I have stayed off of multi-threading on sebras/doc since it seems a bit unclear how it is supposed to work. the same goes for the text device and pixmap-stuff (which you recently changed). | 10:32.47 |
| Robin_Watts | Sure. I'll write stuff on that (possibly on the plane, actually) | 10:33.27 |
| kens2 | marcosw_ you really there ? | 10:34.51 |
| Robin_Watts | sebras: The PS_OP_BITSHIFT changes; a stray - ? | 10:35.20 |
| | sorry. I mean, aren't you missing a - ? | 10:35.39 |
| | i1 >> -i2 surely? | 10:35.49 |
| | For what value of d can: !isnan(d) && CLAMP(d, -FLT_MAX, FLT_MAX) != d ? | 10:38.05 |
| | Oh, d is a doulbe. | 10:38.28 |
| | double. | 10:38.31 |
| | OK, all that looks plausible except the shift thing. | 10:38.44 |
| sebras | Robin_Watts: well, you found a bug I believe. I never actually changed the shifting, just the test... | 10:44.46 |
| | but yes, it should be -i2. | 10:45.09 |
| | thanks for the review. | 10:47.27 |
| Robin_Watts | Ah :) | 10:55.40 |
| | You're welcome. | 10:55.44 |
| Robin_Watts | runs. back soon. | 10:56.26 |
| kens2 | paulgardiner : Robin has gone for a run and tor isn't here right now | 11:07.21 |
| | If you were looking for them | 11:07.34 |
| paulgardiner | kens2: Thanks. I was hoping to talk to Tor, but I wasn't necessarily expecting to find him yet. I just thought I'd hang around - catch him later. | 11:14.07 |
| kens2 | No problem :-) | 11:17.13 |
| paulgardiner | There's a lot more people here than I was expecting at this time, given where I thought most people were based. Must be a lot of early risers. :-) | 11:23.54 |
| kens2 | A lot of them aren't really here as such, just logged in and recording | 11:24.24 |
| paulgardiner | Ah right. | 11:24.35 |
| kens2 | I see we do have a troll present too :-) | 11:24.46 |
| paulgardiner | :-) | 11:25.00 |
| Robin_Watts | troll ? | 12:10.42 |
| kens2 | Chrysoprase | 12:10.53 |
| kens2 | suspects Robin does not read Discworld | 12:11.26 |
| Robin_Watts | Not for a while. | 12:11.40 |
| kens2 | Chrysoprae the troll runs the mafia equivalent, the 'Breccia' | 12:12.07 |
| tor8 | morning all | 12:12.38 |
| kens2 | Hi tor8 | 12:13.26 |
| paulgardiner | Hi Tor | 12:15.16 |
| sebras | tor8: yo! | 12:16.47 |
| paulgardiner | tor8: I've just made the two changes you requested: clamping vertical movement, and tap to previous/next. I'm just sticking patches in an email. | 12:20.36 |
| tor8 | great. I'll take a look at that today then. | 12:22.48 |
| sebras | I noticed a small UI-omission when I tested the android app. | 12:29.47 |
| | If I search for a word that I know exists then it is highlighted, if I then start to edit the search text it remains highlighted, even if I ultimately search for a word that does not exist. | 12:31.08 |
| | I think the ios app clears the highlights as soon as the edit field is changed. but tor8 would know the details. | 12:31.42 |
| paulgardiner | tor8: I also have an idea for improving scroll performance. Not something quick I'd be keen to work into the original quote, and not something I'm certain will work, but at least worth mentioning. | 12:32.51 |
| | The fact that your removing the textured background doubled the speed, suggests that Android isn't special casing opaque views, and is drawing below them. | 12:33.49 |
| tor8 | okay, I don't know what sort of agreement you have with henrys but I'm sure he might be open to negotiating | 12:34.05 |
| paulgardiner | Even with the background taken away, that behaviour of android would slow things down, because the hq patch overlays the lq cache of the page. | 12:35.24 |
| | If we could get android to draw just what is visible, then it may be very much faster. Views allow their draw method to be overridden, so I believe there is nothing stopping us using our own more efficient algorithm. | 12:37.39 |
| tor8 | paulgardiner: you mean to override the container/background view draw method? | 12:39.22 |
| paulgardiner | Yes. Well, to change the draw method for all the views involved in the app. I think there's only two levels at which we'd have to get in. ReaderView and PageView. | 12:40.30 |
| | All the container views I guess I mean | 12:41.08 |
| | Against doing that... there may be some way I'm not currently aware of to just tell Android to use a better algorithm. Also I wonder if just building for a higher API level might change behaviour. | 12:42.12 |
| Robin_Watts | I bet building for a higher API won't solve it. | 12:42.41 |
| paulgardiner | Probably not. Just a randome thought. | 12:42.59 |
| | I was just thinking it would be bad to do all that work, only later to find there was a simpler approach. | 12:44.16 |
| tor8 | paulgardiner: what unit is ReaderView.SCROLL_SPEED given in? | 12:45.26 |
| | it's a bit too slow | 12:45.34 |
| | or, well, the deceleration is a bit slow | 12:45.50 |
| paulgardiner | Can't find SCROLL_SPEED at the moment. The Scroller does have a friction setting though. | 12:47.17 |
| | Just looking now. | 12:47.25 |
| tor8 | at the top, it's set to 2. I think you use it as a multiplier to keep the number of pixels to travel proportional with the duration | 12:48.16 |
| paulgardiner | Helps if I look at the right file :-) | 12:48.21 |
| | Yeah that's exactly it | 12:48.45 |
| | And it was determined by trial an error. | 12:49.00 |
| tor8 | doesn't work well on a 10" tablet :) | 12:49.09 |
| | grr. damn ant build system is broken :( | 12:49.34 |
| | doesn't rebuild when things change | 12:49.40 |
| paulgardiner | :-) No. I suppose it wouldn't | 12:49.52 |
| | It might be better to just use a constant duration, or perhaps logarithmic on distance | 12:50.38 |
| tor8 | 500ms seems to work rather well | 12:53.20 |
| | oh, in ios I use a 400ms duration | 12:54.16 |
| paulgardiner | Ah! I should have looked. | 12:54.38 |
| tor8 | paulgardiner: I had to go through some contortions there though, since if you tapped again while it was animating the animation layer would go haywire | 12:57.50 |
| | it'd start a new animation that played at the same time as the old one! | 12:58.08 |
| | 400ms feels a bit too fast though, but that may just be because of the lower framerate | 12:59.12 |
| paulgardiner | Oh yeah. I didn't give it much testing. | 12:59.16 |
| | Did you put in a test for whether the scroller was active? | 12:59.58 |
| tor8 | it just seems to drop some of the taps on the android, which isn't a big deal if the animation is fast enough | 12:59.58 |
| | I reimplemented the animation at a lower level (create my own animation instead of calling the setContentOffset:animated: method) which solved it | 13:01.21 |
| | the problem was that the default scroller animation didn't use the real animation layer, so it had all sorts of weirdness going on that the real animation framework would have solved | 13:01.57 |
| paulgardiner | Oh I see. I thought you meant you had to alter the stuff I sent you. | 13:02.33 |
| tor8 | no, the stuff I have here from you works quite well at a fixed 400ms duration for the scrolling | 13:02.57 |
| paulgardiner | Actually the thing I was just worrying about cannot happen because I have just the one scroller instance. | 13:04.08 |
| tor8 | you mentioned earlier that you suspect it doesn't respect the isOpaque thing and redraws everything, I think you're right | 13:04.15 |
| Robin_Watts | paulgardiner: Sell unidisp to google! | 13:04.40 |
| tor8 | when zoomed in a bit so we get the HQ patch on top, the framerate halves again | 13:05.08 |
| paulgardiner | Robin_Watts: :-) I was just thinking that actually it was your nice recursive painting algorithm we need here. | 13:05.26 |
| | tor8: Right! I think that proves it. | 13:05.48 |
| Robin_Watts | tor8: Are you still intending to move fz_obj to be pdf_obj at some point ? | 13:06.11 |
| tor8 | which should be solved by using opengl and drawing front-to-back with the z-buffer ;) | 13:06.25 |
| | or just being smart about what regions to blit :) | 13:06.35 |
| | Robin_Watts: yeah, why not? | 13:06.47 |
| paulgardiner | tor8: on the downside, I think the speed you get when zoomed right out, and with no background is as fast as we'll manage. | 13:07.03 |
| Robin_Watts | tor8: I think it's the right thing to do. It will have some knock on effects in the hash table code (which currently relies on fz_indirect and fz_objcmp). | 13:07.22 |
| | I think I need to rejig that bit now though... | 13:07.32 |
| tor8 | that looks to be around 30fps (when it's not doing the button layer fade) so should be adequate | 13:07.32 |
| paulgardiner | Ok. Worth considering then. | 13:07.58 |
| tor8 | to get it to 60 I'm sure we have to hook into some HW acceleration | 13:08.00 |
| paulgardiner | I'm surprised Android isn't using HW | 13:08.22 |
| tor8 | maybe there are some flags to the bitmap class to make it load better as a texture? | 13:08.33 |
| | they *say* they use HW for the regular ui stuff but given the performance I'm seeing here | 13:08.48 |
| Robin_Watts | One of the criticisms raised at android was that they couldn't use hardware for the UI stuff. | 13:09.10 |
| tor8 | ....my old software rasteriser pumping bitmaps to x11 on a 144mhz sparc performed better :( | 13:09.13 |
| paulgardiner | Strangely, I don't think the HTC Desire I have here varies in speed with the amount of zoom and the presence of the background | 13:09.14 |
| tor8 | paulgardiner: I think it's probably more than fast enough at that display resolution | 13:09.35 |
| Robin_Watts | That may have been fixed in the tablet fork (v3) | 13:09.44 |
| tor8 | quadruple it it starts bogging down | 13:09.47 |
| | the pixel doubled mode probably uses HW to scale up | 13:09.57 |
| Robin_Watts | or maybe they fixed it in Froyo and NOT the tablet fork, and the fixes will come to tablets in v4 (ICS). | 13:10.15 |
| tor8 | because in pixel doubled mode it's smooth as butter, even with the textured back | 13:10.35 |
| paulgardiner | Yeah, sounds smoother than I see on the Desire from how you describe it. | 13:11.16 |
| tor8 | huh, switching from zoomed to high res mode makes the tiled background black on the repaint | 13:11.54 |
| | there's something weird going on with that background! | 13:12.02 |
| paulgardiner | On an earlier subjet, Scroller has a setFriction method. | 13:12.53 |
| tor8 | paulgardiner: another thing I noticed, the scroll indicator in the outline view overlaps the last digit on the page numbers | 13:18.42 |
| | paulgardiner: hm, is there a problem with spaces in filenames when trying to open files from the android file viewer? | 13:22.49 |
| | I get "Unable to open document" there, but if I drop the file in Downloads I can open it from within MuPDF | 13:23.16 |
| paulgardiner | Oh. That would explain a file that I was unable to open. Hadn't linked it to spaces in the name. | 13:24.22 |
| | That's really strange. The mechanisms for triggering the viewer are almost identical in those two situations. | 13:25.19 |
| | Could be a bug in the file explorer. Would be worth seeing if the same happens from the browser. | 13:26.15 |
| | Which file explorer are you using? | 13:26.42 |
| tor8 | "My files" ... something that came pre-installed with the tablet | 13:27.23 |
| | other apps can open the same file though | 13:27.38 |
| paulgardiner | Unlikely a bug there then. I think the same is happening with OI File Manager | 13:27.50 |
| | Looks like getEncodedPath is the wrong thing to call. I'm seeing %20 in place of spaces | 13:36.28 |
| | Fixed that. I'll send another patch. | 13:41.00 |
| Robin_Watts | Need to reboot. brb. | 13:55.02 |
| tor8 | paulgardiner: when you hit "Done" in the search field, shouldn't it start the search? | 14:32.29 |
| paulgardiner | Does it not? | 14:35.45 |
| tor8 | nope, it just hides the keyboard but doesn't launch a search | 14:36.13 |
| paulgardiner | "Done" button on the keyboard? | 14:36.49 |
| tor8 | yeah, the on-screen keyboard button that says you're finished typing | 14:37.52 |
| | maybe it's only on tablet devices? | 14:37.59 |
| | let me dig out my phone | 14:38.04 |
| paulgardiner | You're right. It doesn't. | 14:38.32 |
| | I think I looked at that, and it wasn't hard to get working. I'll look again now. | 14:39.22 |
| | tor8: Another patch in the mail | 14:48.55 |
| tor8 | is it just me or is the enabled/disabled state of android buttons nigh impossible to tell visually? | 15:01.51 |
| | paulgardiner: just a thought, could the fact that the buttons view covers the full screen cause the slowdown? one would hope that the transparent area in the middle doesn't get composited | 15:11.06 |
| | in case it draws each view to a texture with an alpha plane for combining | 15:11.25 |
| paulgardiner | tor8: I wondered that too. I don't think anything daft would be done when the buttons view is completely visible, but possibly during the fade. | 15:13.29 |
| Robin_Watts | Rather than fading on/off, could we slide on/off? | 15:13.51 |
| | IF we think the alpha is causing the problem? (i.e. keep everything solid as much as possible) | 15:14.20 |
| paulgardiner | Didn't the dade speed up when I changed back to using a direct animation, rather than ViewAnimator? | 15:15.12 |
| | Is it the fade that's slow? Or is it scolling that slows down when beneath the buttons? | 15:15.45 |
| tor8 | the fade wreaks havoc with everything on the tablet | 15:16.49 |
| | let me double check the scrolling speed with the buttons on/off | 15:17.10 |
| | no visible diff, so it's probably just during the cross fade | 15:17.52 |
| paulgardiner | Could try just setVisible calls in place of the animation creation.. Shall I make a patch to try it? | 15:17.59 |
| tor8 | how about robin's suggestion, with a slide instead of fade, or would that be difficult with the android layout things? | 15:18.30 |
| paulgardiner | Hmmm, would look odd if the whole lot slid on from the side, so I'm guessing you'd want the button bar slide in from the top, and the seek bar/page number from the bottom? | 15:21.12 |
| tor8 | yeah. I had that from the start with iOS but it messed up their very fragile scroll view setup | 15:21.41 |
| | panning it in from the top would automatically add offsets to the scroll view underneath it! | 15:22.03 |
| paulgardiner | Ok. That shouldn't be difficult. I'll have a go. | 15:23.52 |
| | Did the last two patches seem to work ok? | 15:24.35 |
| tor8 | paulgardiner: yes, they work great! | 15:25.38 |
| | I'm fiddling with the icons | 15:25.50 |
| | the iOS app store automatically adds rounded corners and drop shadows to the launcher, but no such luck for android... | 15:26.20 |
| | paulgardiner: I tried a heavier file with big images and that impacts the fade a lot. is it triggering relayouts that cause you to re-render the page perhaps? | 15:48.04 |
| paulgardiner | Sorry, lost me there. I cannot think how big images would make a difference. You mean a PDF file containing big images? | 15:50.43 |
| | Unless it is shortage of memory as Robin suggested. | 15:51.06 |
| tor8 | I tried a CBZ file, and there's a very noticeable delay between tapping and the fade starting to happen | 15:51.25 |
| Robin_Watts | I think tor8 meant he tried a PDF file with large images in. | 15:51.27 |
| tor8 | and the same happens on pdf:s that take a long time to parse | 15:51.39 |
| | like ones with large images in them | 15:51.49 |
| paulgardiner | Must be the background processing impacting on the UI thread | 15:52.30 |
| tor8 | could be, or something gets hung up on a lock waiting for a page to finish processing | 15:53.44 |
| | just guessing wildly here, it looks like it may be the rendering of the next/previous pages in the background that impacts it | 15:54.06 |
| | because it's only after I recently flip to a page that it happens | 15:54.24 |
| | yeah. If I flip forward so I see the loading spinner, tap in the middle it locks up until the page is ready | 15:55.33 |
| paulgardiner | It shouldn't be to do with locking: the UI doesn't ever wait on the core lock. | 15:55.33 |
| | ASyncTask could be running out of worker threads, I guess, but still that shouldn't stall the UI | 15:56.08 |
| tor8 | the UI is definitely stalled here :( | 15:56.25 |
| | but it only happens on the animation fade, never anything else | 15:56.50 |
| paulgardiner | Maybe android uses the same worker thread set for ASyncTask and animations. | 16:00.32 |
| henrys | tor8, paulgardiner:is there more to do? paulgardiner can just bill us hourly until things are wrapped up. | 16:05.40 |
| tor8 | henrys: nothing major, but there are a few performance issues on the tablet which don't really show up on a phone device | 16:06.16 |
| henrys | and we know the performance problems are in the ui vs mupdf. | 16:07.52 |
| | sorry that was a question | 16:09.32 |
| Robin_Watts | henrys: Yes. | 16:10.13 |
| | It's to do with fading controls on/off etc, or scrolling while said controls are on the screen. | 16:10.37 |
| | It's looking (AIUI) like a flaw in androids underlying redraw behaviour. | 16:11.01 |
| henrys | well if it makes sense to get paulgardiner a tablet, assuming he wants to work on it, we can pay for the work. | 16:11.19 |
| | we are saying this does not have a solution in the current incantation of the gui code? | 16:12.07 |
| Robin_Watts | I believe at the moment there are sufficient unknowns for that not to be clear. | 16:12.55 |
| | It may be we can fix it by just changing things slightly (say my moving to scrolling things on rather than fading them on). | 16:13.22 |
| | s/my/by/ | 16:13.31 |
| paulgardiner | We might get the one to do with fading sorted today. | 16:13.33 |
| henrys | paulgardiner:well don't work for free just send an invoice to miles and I'll explain the overage | 16:14.35 |
| paulgardiner | henrys; Thanks. That's brilliant. The little tweeks I've been doing today haven't been a problem, but the idea we have for improving the scroll speed would be a fairly significant change. | 16:15.58 |
| henrys | which table do you have tor8? | 16:17.03 |
| | tablet | 16:17.08 |
| tor8 | samsung galaxy 10.1" | 16:17.55 |
| henrys | did I mention that I hate doing the meeting agenda? | 16:21.56 |
| Robin_Watts | Should I buy a samsung galaxy 10.1 and get it to Paul ? | 16:23.24 |
| | (or should Paul just buy one and add it to the invoice?) | 16:24.03 |
| tor8 | Robin_Watts: it may make sense to buy an android 4 tablet for testing though | 16:24.24 |
| Robin_Watts | tor8: I've been looking, believe me :) | 16:24.37 |
| | I was going to buy an asus transformer prime, but they have been beset with problems. | 16:24.56 |
| henrys | I agree with tor8 - I think Robin_Watts should buy one and lend it to Paul. | 16:25.02 |
| Robin_Watts | OK. Currys apparently have Transformer Primes available for next day delivery at 500 quid. | 16:27.47 |
| | It ships as 3.2 (which is probably the same as tor8's device?) but is promised an ICS update any day. | 16:28.39 |
| | oh. apparently ICS is out for it already. | 16:29.11 |
| tor8 | yeah. the galaxy tab is (as usual with samsung) not planned for any updates | 16:29.27 |
| Robin_Watts | OK, I'm buying it now... speak quickly otherwise... | 16:31.08 |
| sebras | tor8 Robin_Watts: http://goo.gl/4iYdJ | 16:37.58 |
| | so yes, the have stated that there will be an ICS upgrade...sometime. | 16:38.18 |
| | s/the/they/ | 16:38.40 |
| tor8 | they've said similar things before and not honored them | 16:39.35 |
| | but we'll just have to wait and see | 16:39.41 |
| | Robin_Watts, paulgardiner: I've pushed some icon and layout tweaks to casper's pg_android branch | 16:40.43 |
| sebras | I guess that's the vendors trying to encourage you to buy their new models... | 16:41.25 |
| paulgardiner | tor8: great. Could you push the patches too, assuming they're all good. | 16:42.04 |
| tor8 | I added the patches I got from your mail as well | 16:42.18 |
| paulgardiner | tor8: magic. | 16:42.26 |
| | I have another I'm about to send - sliding instead of fading | 16:42.48 |
| kens | marcosw_ ping | 16:43.42 |
| | Too slow :-( | 16:43.48 |
| paulgardiner | tor8: on the Desire, the sliding in of the buttons is very smooth. Smother than the doc scroll. | 16:47.22 |
| henrys | meeting time | 16:59.35 |
| kens | OK | 16:59.41 |
| | is marcosw_ really here ? | 16:59.48 |
| marcosw_ | no | 16:59.55 |
| kens | Aha. | 17:00.01 |
| henrys | kens:I think I simplified the raster pattern file all I can. | 17:00.01 |
| kens | This delightful bug you've wished on me... | 17:00.08 |
| marcosw_ | kens: I saw you're email regarding the pdfwrite issue. | 17:00.11 |
| kens | henrys, that's fine thanks, I've been looking at somethign else alll day | 17:00.26 |
| henrys | np | 17:00.35 |
| kens | marcosw_ yes that's the one, is that a sufficient work-around, does it work for you ? | 17:00.39 |
| marcosw_ | the customer is in the process of upgrading to a newer release, but needs a patch for 8.71 as well :-( | 17:00.42 |
| kens | Can they just use -dUseCIEColor ? | 17:00.54 |
| | Thyeir current settings don't work properly without it anyway | 17:01.10 |
| henrys | ray_laptop:I assume you are not going to sf right? | 17:01.11 |
| marcosw_ | You ask a valid question, I presume they have some reason for using it even though it doesn't make sense. I'll ask them. | 17:01.29 |
| kens | Best to check if the problem goes away for them too that way. | 17:01.44 |
| ray_laptop | henrys: right. I discussed it with Miles yesterday. I'll be on IRC during the meeting if anything comes up. | 17:02.05 |
| kens | THe problem 'appears' to be the colour space (Indexed colour) in the form gets corrupted, I have no idea why and executing 500 times takes an age. | 17:02.18 |
| henrys | okay new hotel wonder how the internet will be? | 17:02.29 |
| Robin_Watts | ray_laptop: If you want to skype in at any point, I can share skype details with you. | 17:02.32 |
| chrisl | marcosw_: 8.71 is unsupported now, isn't it? | 17:02.40 |
| ray_laptop | If someone can set up a mic and skype me in (no need for visuals) I can hear the discussion | 17:02.43 |
| kens | 9.0 uses the CMS and so the problem vanishes. Also there are significant changes to colour handling and the way pdfwrite idetifies identical images. | 17:02.48 |
| | chrisl its not quite 2 years yet :-( | 17:02.57 |
| marcosw_ | kens: and it only fails under Windows, so none of the tools that I usually use under Linux are applicable. | 17:03.01 |
| mvrhel_laptop | really? 8.71 is less than 2 years still | 17:03.13 |
| kens | marcosw_ yes, its a bugger :-( | 17:03.17 |
| henrys | for this meeting I had questions about a few bug on alexcher_ plate. | 17:03.22 |
| marcosw_ | chrisl: I think ken is correct, we are supporting 8.71 until the next release in August. | 17:03.40 |
| Robin_Watts | ray_laptop: See private message. | 17:03.49 |
| henrys | the portfolio thing seems stalled and the disappearing text patch. | 17:03.52 |
| chrisl | kens, marcosw_ : ah - still going to hard to back-port the ICC workflow! | 17:03.54 |
| alexcher_ | henrys: which ones? | 17:03.59 |
| kens | Its 2 years are up in March I think, or April | 17:04.02 |
| | chrisl, I'm not sure that's the change that 'fixed' it. | 17:04.20 |
| chrisl | I thought it was this month..... | 17:04.24 |
| kens | Seems we released later 2 years ago | 17:04.36 |
| mvrhel_laptop | can a product go unsupported in the middle of a bug fix | 17:05.00 |
| henrys | alexcher_:692832 | 17:05.04 |
| kens | I can continue to work on it, but its going to be very slow, for an obselete version of GS. I'd rather spend the time on more producrtive issues if possible. And there is a possible work-around | 17:05.39 |
| henrys | tor8:anything for the meeting? | 17:05.42 |
| tor8 | henrys: nope, not really | 17:06.46 |
| henrys | kens I thought I saw a february month on an 8.71 fileset. | 17:06.48 |
| kens | henrys, well I could be mistaken, I did a web search and it said it was reeased in March or April as I recall. | 17:07.13 |
| alexcher_ | henrys: re 692832, the attached patch is the best I can do quickly. | 17:07.29 |
| chrisl | Version 8.71 (2010-02-10) - From History8.htm | 17:07.49 |
| kens | http://pages.cs.wisc.edu/~ghost/doc/GPL/gpl871.htm | 17:07.54 |
| marcosw_ | kens: I was hoping you had a valgrind equiv. for windows that might show something. I agree that debugging by hand would be time consuming. Let me get back to the customer before you spend more time on it. | 17:07.59 |
| henrys | alexcher:the other one was the portfolio issue, which I thought was easy - adding an option. | 17:08.11 |
| kens | Which is probably why. THe date at the bottom is 2010-04-13 | 17:08.15 |
| | marcosw_ no, no valgrind for Windows | 17:08.23 |
| marcosw_ | we released 8.71 on 2010-02-10, so it's been two years. | 17:08.25 |
| kens | Well, its a paying customer.... | 17:08.36 |
| henrys | alexcher_:chrisl can you weigh in on alexcher's patch and anyone else? | 17:09.02 |
| Robin_Watts | kens, marcosw_: I feel I should say "memento" at this point on principle... | 17:09.03 |
| kens | But like I said, if they can use the work-around of actually setting -dUseCIEColor (like the Gjhostscript message tells them to) then it would be better | 17:09.05 |
| marcosw_ | Does memento exist in 8.71? | 17:09.21 |
| kens | Robin_Watts : Not on 8.71 | 17:09.22 |
| Robin_Watts | It can easily be backported. | 17:09.29 |
| kens | And will almost certainly destory the bug | 17:09.39 |
| | Its *very* sensitive to the source I find | 17:09.47 |
| mvrhel_laptop | sounds like -sdUseCIEColor is the answer | 17:09.56 |
| | -dUseCIEColor | 17:10.05 |
| kens | Well, it works for me, and it makes more sense than not setting it | 17:10.10 |
| henrys | marcosw_:I don't think enough effort has been put into telling the customer to upgrade. | 17:10.18 |
| kens | Since they are setting UseDeviceIndependentColor | 17:10.24 |
| mvrhel_laptop | then certainly it makes sense | 17:10.37 |
| alexcher | henrys: the portfolio is simple. I'm adding a loop that will dump the data for all files. | 17:10.51 |
| kens | OK so I will back off on this until marcosw_ approaches the customer with the work-around at least | 17:11.18 |
| marcosw_ | henrys: they are in the process of upgrading to 9.04 (or perhaps 9.05), but want a fix for 8.71 as well. I'll push back with leaving off the -dUseCIEColor option. | 17:11.32 |
| chrisl | henrys: alexcher and I discussed it originally - give that we're dealing with a broken file, and we don't know for sure what CPSI does, I think Alex's is a reasonable heuristic to work around the issue. | 17:11.35 |
| henrys | alexcher great I didn't know if it had been dropped since we discussed it quite some time ago. | 17:11.48 |
| kens | marcosw_ If I do have to debug this, it will be a long while before they get a fix, that may be information affecting the customer's decision about the work-around.... | 17:11.50 |
| | marcosw_ THey need to *add* -dUseCIEColor, not leave it off | 17:12.13 |
| marcosw_ | kens: right. | 17:12.28 |
| henrys | chrisl:sounds like we should commit the fix. | 17:12.28 |
| chrisl | henrys: the other option would be to spend a indeterminate amount of time experimenting with various broken type 3 fonts in CPSI, which I really don't think it worth our time | 17:13.29 |
| alexcher | marcosw_: Purify is a commercial memory checker for Windows. It's now distributed by IBM. | 17:13.45 |
| kens | alexcher, will it work with our garbage collector and memory management ? | 17:14.05 |
| marcosw_ | Yes, I've used Purify in the past. Do we own a copy? | 17:14.07 |
| henrys | chrisl:I don't think that is warranted. | 17:14.08 |
| marcosw_ | It used to be very expensive but worked really well. | 17:14.22 |
| kens | I'm not convinced Purify will woork in this case | 17:14.27 |
| Robin_Watts | It's still very expensive. | 17:14.35 |
| kens | Its memory being managed by GS | 17:14.36 |
| ray_laptop | usually the GC 'reloc' totally confuses most memory tools | 17:14.47 |
| | but if you can get it to fail with every object in its own GC chunk, then the reloc is out of the picture | 17:15.23 |
| henrys | marcosw_:any customer issues you think need attention? | 17:15.37 |
| | beyond what we are talking about? | 17:15.48 |
| kens | ray_laptop : I'm willing to try that, but have no idea how. My guess is it will not fail | 17:15.50 |
| alexcher | marcosw_: Last time I checked it was below $1000. I tested it on Ghostscript but prefer Valgrind. | 17:16.07 |
| henrys | and mvrhel_laptop:are you setup with alexcher and output intent or should we discuss? | 17:16.34 |
| mvrhel_laptop | I have not heard from him about it | 17:16.44 |
| chrisl | http://code.google.com/p/drmemory/ might be worth a look | 17:16.47 |
| mvrhel_laptop | I was going to ask at the end of the meeting | 17:16.52 |
| marcosw_ | henrys: it would be nice if mvrhel_laptop could take a look at http://bugs.ghostscript.com/show_bug.cgi?id=692865, it's a regression. | 17:17.00 |
| henrys | mvrhel_laptop:also you were going to move the user param code into the graphics library. | 17:17.01 |
| mvrhel_laptop | henrys: yes. I started that and then last week got cut short for me. I will get it done before the meeting | 17:17.28 |
| | ray_laptop is sucking me into customer 532 stuff.... | 17:17.42 |
| henrys | great. | 17:17.46 |
| | more 532 stuff? | 17:17.55 |
| mvrhel_laptop | screen creation.... | 17:18.19 |
| henrys | I thought you made all these great tools that lets the user make those. | 17:19.01 |
| marcosw_ | there is a partially functional purify trial that I might try⦠The retail version is $951 but I believe that only includes a 1 year license (it might be an indefinite license with one year of support, I didn't read the small print). | 17:19.42 |
| henrys | so alexcher it seems like we have a go ahead for committing your patch for missing type 3 text. | 17:20.03 |
| Robin_Watts | marcosw_: It's probably 1 seat, non-floating too though :( | 17:20.04 |
| mvrhel_laptop | yes. well I will let ray_laptop explain it all but apparently there is some political issue between japan and the US engineers about a particular issue which is likely due to them using screens with a transfer function which is causing the loss of levels in the light regsions | 17:20.37 |
| ray_laptop | kens: setting -M1 will set the chunk size to 1K. Other than that you can zap psi/imainarg.c to make the -M set it smaller | 17:21.03 |
| mvrhel_laptop | so it may be easy enough for us to go ahead and create some screens that demonstrate that this is the issue | 17:21.15 |
| | i.e. which have the same embedded transfer function but more levels | 17:21.42 |
| henrys | mvrhel_laptop:okay | 17:21.49 |
| marcosw_ | Robin_Watts: true | 17:21.55 |
| ray_laptop | henrys: I asked mvrhel_laptop to use his color screen generation tool to make screens that are similar to theirs but that have more levels | 17:21.56 |
| kens | ray_laptop : these are pretty small string, indexed RGB colour spaces, but that might do it. | 17:21.57 |
| mvrhel_laptop | alexcher: so did you get a chance to add in the interpreter parts for the output intent? | 17:22.43 |
| ray_laptop | kens: is this the thing where the palette is getting polluted ? | 17:22.56 |
| alexcher | mvrhel_laptop: not yet. | 17:23.35 |
| kens | ray_laptop : yes, the colour space being written is from an /Indexed space, and the space is incorrect. | 17:23.41 |
| ray_laptop | kens: it looks to me like someone is keeping a pointer to the palette data that doesn't track when the GC reloc's the object | 17:23.43 |
| kens | It has been corrupted | 17:23.46 |
| henrys | I'm concerned 532 is getting too much priority at the expense of other customers. It just seems non ending. | 17:23.55 |
| kens | ray_laptop : We are comparing an old colour space to the new one. We write a new space if they don't match, using the current colour space. | 17:24.11 |
| | So its the current space which is corrupted | 17:24.18 |
| ray_laptop | kens: when I looked at the palette data at one point it contains string data | 17:24.24 |
| kens | I get somewhere between 6 sand 12 warnings in gs_vmrecalim | 17:24.41 |
| | But I don't know what they are telling me | 17:24.55 |
| marcosw_ | I realized that I hadn't tried valgrind on the 32 bit build under Linux (I constantly forget that the default for linux is 64 bit and for windows it's 32 bit). There are some warnings produced that don't come up with the 64 bit build that may be related (i.e. in pdf_indexed_color_space()). I'll reassign the problem to me to continue this line of inquiry. | 17:25.20 |
| kens | FWIW the problem persists with -M1 | 17:25.21 |
| ray_laptop | kens: what kind of warnings ? | 17:25.28 |
| henrys | it does seem to me alexcher is a bit swamped again and him teaming up with kens or possibly chrisl again would be worthwhile. Of course that would stall what kens or chrisl are working on. Thoughts? | 17:26.04 |
| kens | ray_laptop : String pointer 0x....[765] outside [0x...0x...) | 17:26.18 |
| | And yes, the brackets are of different types | 17:26.40 |
| | The warnigns are on line (15) of psi\igcstr.c | 17:26.58 |
| | (153) sorry | 17:27.07 |
| ray_laptop | kens: ahh -- that definitely sounds like a hit. So is the string the palette ? | 17:27.07 |
| kens | It looks like it | 17:27.15 |
| chrisl | henrys: I'm happy to help out with Alex's queue, but probably won't have much time for a bit | 17:28.20 |
| ray_laptop | kens: so you need to see what structure has that pointer to the string. If you set a breakpoint, you can see if it is in an 'enum' or 'reloc' stage | 17:28.29 |
| kens | One minute ray I had to rebuild for my breakpoint to work | 17:28.57 |
| henrys | Robin_Watts:could you take a look at the xps crash for mvrhel_laptop if that makes sense to both of you? | 17:29.17 |
| kens | Its a gs_gc_reclaim, does that help ? | 17:29.28 |
| ray_laptop | kens: if you go up in the call stack, then you get to a point where the 'pre' object is visible and you can look at its type | 17:29.29 |
| mvrhel_laptop | I was just digging into that one | 17:29.31 |
| Robin_Watts | henrys: I could, but I'm right in the middle of some mupdf stuff at the moment. | 17:29.43 |
| henrys | mvrhel_laptop:okay nvm | 17:29.45 |
| Robin_Watts | Can it wait til after the meeting ? | 17:29.50 |
| | oh, I'll leave it to mvrhel. | 17:30.01 |
| henrys | Robin_Watts:sounds like mvrhel_laptop is on it. | 17:30.15 |
| Robin_Watts | The MuPDF customer has 2 problems at the moment. | 17:30.20 |
| kens | ray_laptop : Can't see a 'pre' object. | 17:30.30 |
| ray_laptop | mvrhel_laptop: BTW, thanks for responding to the customer about the FastColor option | 17:30.44 |
| Robin_Watts | 1) They are concerned about speed (something is up with the profiles of the new code on at least one particular test page) | 17:30.48 |
| mvrhel_laptop | no problem | 17:30.51 |
| Robin_Watts | 2) They need image decompression on demand, so I've done most of that. | 17:31.05 |
| ray_laptop | kens: what's the (top of the) call stack ?? | 17:31.13 |
| henrys | Robin_Watts:this is the company you recently had the conference with? | 17:31.34 |
| Robin_Watts | Yes. | 17:31.42 |
| kens | interp->interp_reclaim->ireclaim->gs_vmreclaim->context_reclaim->gs_gc_reclaim->gc_trace->gc_string_mark | 17:32.10 |
| henrys | okay 2 minutes past meeting over... I'll be around most of the day. | 17:33.09 |
| kens | It appears to be handling local VM ray | 17:33.14 |
| | Hmm, interestingly, unlike last time, this is now pointing at uninitialised memory. | 17:34.51 |
| ray_laptop | kens: sometimes it helps to run with -Z@$? | 17:36.51 |
| marcosw_ | tor8: are you flying through Frankfurt? The ground controllers are striking and my brother's flight this morning from Frankfurt to the US was cancelled, he had to re-route via LHR. | 17:36.59 |
| kens | ray_laptop : I can try thast but I doubt I will understadn the reams of output. Give me a minute | 17:37.17 |
| ray_laptop | kens: -Z@$? doesn't (usually) generate any output | 17:37.41 |
| kens | Well it made the GC problem go away | 17:38.18 |
| ray_laptop | the '?' causes pointers to be validated and sometimes generates messages when an object isn't defined in any chunk | 17:38.29 |
| kens | File is still broken | 17:38.35 |
| | Image comes out flat gray now | 17:38.50 |
| | Goes wrong much earlier though, o page 2 that's helpful | 17:39.54 |
| ray_laptop | kens: try it without the -Z@ the '@' fills memory when allocated/freed | 17:39.59 |
| kens | so -Z$ | 17:40.37 |
| ray_laptop | kens: but if it is failing that quickly and well defined with -Z@ it should be much easier to track down. | 17:40.38 |
| | kens: or -Z$? | 17:40.50 |
| kens | -z$ produces more gc errors | 17:41.00 |
| ray_laptop | kens: this is with 8.71 ? | 17:41.01 |
| kens | Yes, all with 8.71 | 17:41.10 |
| | HEAD works fine | 17:41.18 |
| | Taking away the '@' gives more errors, and the images are back to corrupted again (instead of the same all the time) | 17:41.54 |
| ray_laptop | kens: I'll take a look at it. I've been in memory hell before and know some tricks. It's probably getting late for you. | 17:42.04 |
| kens | I think I'll use -Z@$ because it goes wrong much faster | 17:42.10 |
| ray_laptop | builds 8.71 | 17:42.28 |
| chrisl | kens: I fixed a garbage collector problem, IIRC, strings in indexed color spaces | 17:42.29 |
| kens | ray_laptop : I'd be grateful, but its hard to get it to fail, you need a pretty exact set of conditions | 17:42.32 |
| | chrisl that could be it. | 17:42.40 |
| | Do you remember the bug/commit hash ? | 17:42.51 |
| chrisl | give me a minute, I'll try to find the commit | 17:42.52 |
| kens | is still updating the laptop.... | 17:43.09 |
| ray_laptop | chrisl: I looked in the log and couldn't find it, but I also (vaguely) recalled something with palettes | 17:43.57 |
| chrisl | kens: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=0bd3e960b37258e0dd1a99f5110783a37d479e70 | 17:43.58 |
| kens | chrisl, thanks I 'll try that. | 17:44.20 |
| ray_laptop | chrisl: thanks -- I bet that's it. | 17:46.21 |
| kens | Just rebuilding now | 17:46.29 |
| | No GC errors | 17:47.20 |
| | And output is OK. Looks like that was it | 17:47.38 |
| chrisl | Yay! | 17:47.43 |
| kens | Thanks chrisl | 17:47.49 |
| | marcosw_ you can send that patch to the customer too. | 17:48.00 |
| chrisl | I can't remember how big that patch was | 17:48.06 |
| kens | Though you might like to try it first as well | 17:48.09 |
| | Its only a few lines | 17:48.16 |
| | add about 12, take 1 away | 17:48.28 |
| chrisl | Excellent! | 17:48.33 |
| | So, how come I could remember that, but I can't remember today's date....? ;-) | 17:49.37 |
| kens | Specialised memory | 17:49.46 |
| | Anyway, thanks for that, I can go back to Henrys raster pattersn tomorrow and on the plane now. | 17:50.03 |
| | Dinner time, goodnight all | 17:50.12 |
| henrys | nice chrisl | 17:50.18 |
| marcosw_ | kens: I was working on my paper to "Predict drug function via cytological profiling" (one of the aims of my dissertation), so have no idea what patch I need to send to which customer. | 17:50.19 |
| chrisl | marcosw_: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=0bd3e960b37258e0dd1a99f5110783a37d479e70 | 17:50.42 |
| kens | The customer iwht the corrup[ted images | 17:50.52 |
| | #692868 | 17:51.03 |
| | THe patch above fixes it. | 17:51.10 |
| marcosw_ | kens: I thought we had given up on that? | 17:51.13 |
| kens | marcsw_ | 17:51.21 |
| | chrisl remembered fixing the actual problem | 17:51.28 |
| marcosw_ | that darn chrisl :-) | 17:51.40 |
| kens | I have no idea whay this does not show up with bisect, except that being memory, it shifts around when you change the code. | 17:51.54 |
| | I still say the customer should use -dUseCIEColor though | 17:52.13 |
| | Because of the other parameters they have set | 17:52.24 |
| marcosw_ | Making me look foolish, I just emailed the customer saying that a fix would take weeks and now I need to mail them, never mind, here it is? | 17:52.27 |
| kens | But its good to give them a real fix for the memory problem too. | 17:52.39 |
| | You can say that we were lucky and had already fixed it, it just took time to find the fix. | 17:52.57 |
| | Anyway, sorry ;-) | 17:53.04 |
| | And again, night all. | 17:53.30 |
| chrisl | marcosw_: to be fair, it took me several days to track down the problem originally, so you weren't entirely wrong in saying it could take some time to fix! | 17:53.46 |
| ray_laptop | marcosw_: just tell them that you were estimating as if you had to fix it instead of the engineer that handled it ;-) | 17:53.58 |
| marcosw_ | ray_laptop: I would be more insulted if you weren't correct ;-) | 17:54.35 |
| chrisl | marcosw_: your other option is to wait a couple of weeks before sending them the patch :-) | 17:55.13 |
| marcosw_ | Or I could take a page from Adobe Acrobat support and make them reinstall Ghostscript after wiping their drive and reinstalling windows. | 17:55.54 |
| chrisl | If you really want to follow Adobe's policy, tell the customer 8.71 is working as intended, and change the documentation to describe what 8.71 is doing..... | 17:57.07 |
| mvrhel_laptop | hehe | 17:57.40 |
| | I like the uninstall reinstall suggestiong | 17:58.04 |
| | suggestion | 17:58.10 |
| marcosw_ | or tell them to upgrade to 9.05, since Adobe only appears to support the latest version of anything (which is doubly annoying since they charge for upgrades). | 17:58.29 |
| mvrhel_laptop | alexcher: so do you have any idea when you are going to be able to get to the output intent | 18:01.53 |
| | we can talk about it some at the meeting if you don't understand what needs to be done | 18:02.20 |
| tor8 | marcosw_: munich | 18:02.29 |
| alexcher | mvrhel_laptop: I'll try to finish before the meeting. | 18:03.23 |
| mvrhel_laptop | alexcher: ok great! | 18:03.50 |
| alexcher | Currently I'm puzzled by the bug 692852. The workaround introduced by 690786 covers almost everything, but 1bpc indexed color space is handled by AR9 differently. Should I add a special case? | 18:04.24 |
| marcosw_ | Lufthansa MUC -> SFO? That should be a pretty nice flight, I took SFO->MUC 10 days ago and it was the emptiest flight I had been on in years. The flight attendant said that SFO<->MUC is usually only half full this time of year (Lufthansa used to only fly this route 3 days a week in the winter, I don't know why the changed to daily since the demand clearly isn't there). | 18:05.34 |
| henrys | alexcher:we assigned that to Robin_Watts, why are you working on it? | 18:07.33 |
| alexcher | henrys: because my previous patch attempts to fix a similar problem and I've got some insight into the problem during initial analysis. | 18:10.36 |
| ray_laptop | mvrhel_laptop: I took a look at cust 532's xfer functions. While their input screens have all 256 levels, the TF _really_ compresses things. The 1200 1 bit starts with 0, 5, 10, 15, 20, 25, 30, 35, 37, 38 | 18:11.17 |
| henrys | alexcher:I thought it would be useful to have a second point of view and you are backed up on what is already on your plate. | 18:13.54 |
| | if you insist on working the problem then please change the assignment back. | 18:14.48 |
| alexcher | henrys: I'm posting a comment about AR9 properties. This bug is about reproducing how AR handles broken /Mask. | 18:17.01 |
| mvrhel_laptop | ray_laptop: oh wow. sorry I have not gotten to this yet. | 18:18.38 |
| tor8 | marcosw_: yup, that's the one | 18:18.46 |
| mvrhel_laptop | I will start on it shortly | 18:18.46 |
| henrys | alexcher:all I'm saying is if you are going to work on it assign it to yourself and if not assign it to someone else, everyone is very busy and duplicating work needs to be avoided. | 18:20.17 |
| chrisl | alexcher: it looks like xpdf and poppler drop the Mask completely if the sample values in the mask don't make sense with the rest of the image properties - no idea if that tallies at all with AR behavior. | 18:20.33 |
| Robin_Watts | So, Fujitsu are tightwads. Bug 692860. | 18:24.36 |
| alexcher | chrisl: no AR uses the given number modulo the correct range. | 18:24.57 |
| ray_laptop | mvrhel_laptop: but I don't see how that would cause levels to be mapped to the same ht pattern | 18:24.59 |
| alexcher | chrisl: This is coded now, but 1 bpc indexed space seems to be an exception. | 18:25.38 |
| tor8 | paulgardiner: moving the setBackgroundResource(R.drawable.tiled_background) to the layout rather than the mDocView (the layout that contains both the document view and the buttons view) solved the flickering glitches! | 18:26.16 |
| chrisl | alexcher: okay, that does make some sense I suppose - lord, I do hate Acrobat :-( | 18:26.26 |
| henrys | Robin_Watts:yes rather odd... I suspect he just wants a viewer to view pcl and they aren't using our product in any direct way. | 18:27.12 |
| chrisl | henrys: if that's the case, he could at least be a bit nicer about it! | 18:27.55 |
| Robin_Watts | Is it worth following up with a reply saying "Well, your bug will be dealt with at the free user (low priority) level then. I assume therefore that you are using GhostPCL in a GPL conformant manner." | 18:28.02 |
| alexcher | chrisl: In the latest file AR drops the mask it the first element is invalid. If the 2nd element is invalid, it'd replaced by 1. | 18:28.41 |
| Robin_Watts | tor8: Excellent! | 18:29.19 |
| henrys | Robin_Watts:I'd like to let him sit for a bit... Miles has already read him the riot act. | 18:30.01 |
| Robin_Watts | henrys: fair enough. | 18:30.12 |
| chrisl | alexcher: like I said, hate Acrobat! I find it hard to believe that's "intended behavior"...... Sounds like you've got a good idea how to proceed, though. | 18:31.13 |
| ray_laptop | mvrhel_laptop: the 1200 dpi screen is really screwy. Even though it is 24x24 they have LOTS of missing values (58 out of 256) pretty crappy screen if you ask me | 18:31.23 |
| henrys | Robin_Watts:I do think of sending an email to corporate headquarters - this yahoo is waving your company name around and asking for free support, I would assume somebody at the company would frown upon that. | 18:31.35 |
| | or maybe they'd just think him enterprising. | 18:32.05 |
| ray_laptop | marcosw_: BTW, there is a utility too scan a FONTPATH once and generate a Fontmap that directly maps the fonts found. This is recommended on machines with lots of fonts (like I have) when you want to use -sFONTPATH. See toolbin/genfontmap.ps | 18:56.31 |
| marcosw_ | ray_laptop: thx. I recalled something like that, but I wanted to see if this was problem before looking around. I'll tell the customer. | 18:57.33 |
| ray_laptop | marcosw_: if you use that fontmap, you can still run with -sFONTPATH and it will only go there when it can't find a font in the Fontmap, but if the font is not found at all, then it will still scan, fail and substitute. I recommend leaving it off once the fontmap is generated. | 18:58.28 |
| | marcosw_: if they run without the -q then the stdout will have something like "Scanning ..." | 18:59.39 |
| marcosw_ | they aren't using -q. | 19:00.43 |
| ray_laptop | did they send their stdout log ? | 19:01.16 |
| | marcosw_: also -Z: would be interesting since it shows which page is causing the delay (if any) | 19:02.10 |
| marcosw_ | no. | 19:02.10 |
| ray_laptop | hmm... debugbin/gswin32c -r10 -dJOBSERVER - < comparefiles/Bug688308.ps gives a BUNCH of GPL Ghostscript GIT PRERELEASE 9.06: .\psi\igcstr.c(153): String pointer 0x2595e42[243] outside [0x2595e52..0x2596028) messages | 19:07.19 |
| mvrhel_laptop | I am surprised bug 692865 was not caught by the regression testing | 19:09.17 |
| ray_laptop | mvrhel_laptop: there isn't a command line -- does it fail when generating ppmraw or just to the 'display' device ? | 19:11.42 |
| mvrhel_laptop | I am just running to tiff24nc. it fails then. I have found the issue and should have a fix in a bit | 19:12.13 |
| | it has to do with some confusion on the color spaces that the xps interpreter sets up for defaults | 19:12.30 |
| ray_laptop | mvrhel_laptop: I guess we have a new file for the regression testing :-) | 19:12.39 |
| mvrhel_laptop | icc vs. devicegray etc | 19:12.41 |
| Robin_Watts | Hey scott-san | 19:23.52 |
| scott-san | Hi Robin. Was going to check with Tor or one of you guys to get the latest release number for MuPDF. | 19:24.26 |
| Robin_Watts | 0.9 | 19:24.32 |
| | 1.0 is due within a month. | 19:24.38 |
| scott-san | Great just what I need. I'm sending out an OEM Agreement and neede the proper info. Thanks, see you Friday! | 19:25.07 |
| Robin_Watts | cu! | 19:25.21 |
| ray_laptop | mvrhel_laptop: I was reading the transfer function backwards -- the transfer functions they have are DEFINITELY compressing levels in the lighter shades. The 600 dpi 1-bit at input level 182 and above it maps tonly 38 values -- roughly every other value | 19:27.02 |
| mvrhel_laptop | ray_laptop: ok. hopefully our screens can address this. I am getting ready to clusterpush the fix for this xps bug then I will get to work generating a screen. may grab some lunch first though | 19:28.02 |
| ray_laptop | mvrhel_laptop: no problem. I'm going to send Len an update with what I see from my static analysis. | 19:29.08 |
| mvrhel_laptop | ray_laptop: so which transfer function should I use of the ones that Len sent | 19:49.11 |
| | TF_600_02LV.ps | 19:50.29 |
| | that one goes with the 16x16 screen | 19:52.36 |
| | ok I see | 19:53.19 |
| | nevermind. | 19:53.35 |
| henrys | ray_laptop:forgot to ask at the meeting should 692602 be reopened for a doc fix? | 20:03.01 |
| | I guess chrisl_away is managing the man pages. | 20:03.16 |
| | no pun intended. | 20:03.28 |
| ray_laptop | henrys: sorry -- I was on the phone. Let me look at that one | 20:06.41 |
| mvrhel_laptop | bbiab | 20:08.49 |
| ray_laptop | henrys: it looks like the man pages just never got updated from the doc/Use.htm | 20:09.26 |
| | henrys: so, if you want to re-open for chrisl to manually manage the man pages, that seems reasonable | 20:10.10 |
| henrys | ;-) will do | 20:10.27 |
| ray_laptop | IMHO we should just do away with the man pages and just have one that says "Use your browser and open doc/Readme.htm" | 20:11.17 |
| | there's probably quite a bit of stuff in the man pages that is out of date | 20:11.55 |
| henrys | I certainly don't like the duplication I imagine there would be a backlash to deal with though. Some people get all serious about man pages. | 20:12.35 |
| ray_laptop | another "hot" issue from cust 532 :-( | 20:44.58 |
| rhce7320 | Has anybody know of a print shop producing press plate bitmaps with ghostscript? | 23:29.25 |
| sebras | Robin_Watts: hm.., concerning fz_bitmap_s is it ever the case that we have more than one component per bit? | 23:45.19 |
| | Forward 1 day (to 2012/02/22)>>> | |
IRC Logs