| | <<<Back 1 day (to 2011/10/25) | 2011/10/26 |
| Robin_Watts | chatzillas auto reconnect thing is misbehaving for me. | 11:05.34 |
| | reinstalling xulrunner. bbiab. | 11:28.37 |
| kens | Robin_Watts : ping | 12:09.52 |
| Robin_Watts | pong | 12:14.50 |
| kens | Robin did you say you had pxldisams.py working in Windows ? | 12:15.09 |
| Robin_Watts | I do. | 12:15.15 |
| kens | Using what for a python interpreter ? | 12:15.23 |
| Robin_Watts | Python for windows. | 12:15.34 |
| | Let me find you a link. | 12:15.37 |
| kens | I have it | 12:15.42 |
| | Which version though ? | 12:15.47 |
| Robin_Watts | 3.2.2 | 12:15.56 |
| kens | AH, 3.1 is what I have (just downloading 3.2.2) and it gives a syntax error | 12:16.12 |
| Robin_Watts | At least, that's what I have installed on windows 7... | 12:16.23 |
| kens | I'll assume that 3.2.2 will work | 12:16.28 |
| | Will tell you in a moment | 12:16.40 |
| | Hmm, well can't instlal 'just for me' on Vista ;-) | 12:17.09 |
| Robin_Watts | No, doesn't work for me. | 12:17.27 |
| | I had this working under windows XP. | 12:17.35 |
| | let me try and see what I have installed there. | 12:17.43 |
| kens | Oh :-( | 12:17.46 |
| Robin_Watts | I have Python 2.4 on windows xp, I think. | 12:18.49 |
| kens | Wow, that's old.... | 12:18.59 |
| Robin_Watts | It was new when I installed it :) | 12:19.11 |
| kens | I'm not sure about the sytax error, maybe its real. | 12:19.11 |
| Robin_Watts | yeah. | 12:19.15 |
| kens | My Python isn't up to debugging it | 12:19.25 |
| Robin_Watts | print has changed from a command to a function. | 12:23.48 |
| | so instead of print "blah" | 12:23.55 |
| kens | THat's what I see in the docs yes | 12:23.59 |
| Robin_Watts | we need print("blah") | 12:24.00 |
| kens | Some of the others seem to be OK, was about to try the function version. | 12:24.15 |
| | "Inconsistemt use of tabs and spaces in indentation" | 12:24.50 |
| | OK, I can't fix this, going to give up | 12:30.27 |
| kens | goes to get python 2.7 | 12:31.14 |
| Robin_Watts | TypeError: expected an object with the buffer interface | 12:34.46 |
| kens | RIght, that seems to work | 12:34.49 |
| Robin_Watts | I have it compiling, but then I hit that... | 12:34.53 |
| kens | Python 2 or 3 ? | 12:35.06 |
| Robin_Watts | 3. | 12:35.09 |
| | I think 2.7 might be a smart move ;) | 12:35.16 |
| kens | You did better than me then ;-) | 12:35.18 |
| | Using 2.7.2 seems to work | 12:35.27 |
| Robin_Watts | lunches. | 12:36.24 |
| kens | Hmm, I think this file uses rops.... | 12:36.42 |
| Robin_Watts | So plank looks like it's working OK. I've broken pamcmyk4 though :( | 13:25.31 |
| kens | tor8 are teh bounding box values for each glyph you emit accurate ? I don't think I have that information at the glyph level, just the widths | 13:42.16 |
| tor8 | my bbox values are based on the width, ascender and descender values | 13:45.20 |
| kens | ascneder and decender ? Where do you get those ? | 13:45.37 |
| | Oh, from teh FontDescriptor ? | 13:45.45 |
| tor8 | kens: from freetype actually :) | 13:46.17 |
| | ascender = (float)face->ascender / face->units_per_EM; | 13:46.27 |
| kens | Hmm, well I don;t have teh FT interface, but I guess I can find the ifno | 13:47.01 |
| tor8 | and I think I default to 1.0 and 0.0 for type 3 fonts | 13:47.08 |
| | 0.8 and -0.2 are probably better default values though | 13:47.23 |
| kens | So you get those for each glyph ? Or for the font ? | 13:47.28 |
| tor8 | for the font, then transform them for each glyph | 13:47.41 |
| kens | Hmm, puzzled as to how you do that on a per glyph basis | 13:48.07 |
| tor8 | I create a bbox [0 descender width ascender] and transform into device space | 13:48.59 |
| | so it gets the position and scaling from the TRM*CTM | 13:49.23 |
| kens | Hmm, but rpesumably the height is then teh Font BBox, not the glyph bbox ? | 13:49.42 |
| tor8 | kens: yes. the height is consistent for each glyph of the font | 13:50.13 |
| kens | Ah, OK *that* I can do ;-) | 13:50.26 |
| tor8 | note that I use this bbox for highlighting selected text, so that's the bbox I want | 13:50.29 |
| kens | I was concerned it was accurate for the glyph. | 13:50.34 |
| tor8 | and also what you want for hit testing | 13:50.48 |
| | not so much for optimizing rendering the glyph :) | 13:50.56 |
| kens | Yes, that's fine I undertand now, thanks | 13:51.11 |
| arthurf | tor8: Just wanted to check in and see if tonight (Pacific time) would be a good point to begin testing MuPDF on an iPad. | 14:12.34 |
| | tor8: Gotta head off to work. I'll review the logs during the day to see when it's a good time to begin some of the iOS testing. No rush if this week isn't good - I'd just like to play when ready. | 14:50.16 |
| kens | Still no new posts from Marcos, does anyone know how they are doing ? | 15:11.51 |
| Robin_Watts | They are still being listed in the results for each day. | 15:13.11 |
| | (or were yesterday when I last checked) | 15:13.18 |
| kens | Hmm, hadn't found the daily lists... | 15:13.36 |
| Robin_Watts | http://lacarrerapanamericana.com.mx/resultados | 15:14.04 |
| kens | Aha, thanks, I was using the US site | 15:14.18 |
| ray_laptop | there's a guy interested in multi-level screening ! (he wants stochastic) | 16:10.07 |
| | I guess I have to finish that :-) | 16:10.25 |
| kens | real customer ? | 16:10.37 |
| ray_laptop | kens: well, real in that they really need it, and (apparently) haven't been able to find it from anybody else. They'll be real if the like what I come up with. | 16:11.30 |
| kens | well, not a free user was what I meant ;-) | 16:12.51 |
| ray_laptop | kens: they want to use it in house, but they will also be selling it to outside customers | 16:13.43 |
| | off to get coffee... | 16:22.08 |
| kens | time fo rme to go. Goodnight all | 16:22.12 |
| Robin_Watts | tor8: There is a commit in my mupdf.git that would be good to get onto the trunk. | 16:56.55 |
| | It's a documentation change for android. | 16:57.07 |
| ray_laptop | Robin_Watts: I just did a bmpcmp -w 1 run and I still see all of the single pixel differences. Is it -w1 or -w 1 ??? | 17:21.15 |
| Robin_Watts | Either | 17:22.15 |
| | It's supposed to be exactly the same as fuzzy. | 17:22.25 |
| | Let me check the code. | 17:22.31 |
| ray_laptop | Robin_Watts: for fuzzy it is -w 3 for single pixel tolerance. it is -w1 for my cmpi | 17:23.39 |
| | Robin_Watts: nm. I just looked at it. the 'usage' says: bmpcmp in.pam out.pam out\\diff -w 3 | 17:26.56 |
| Robin_Watts | yeah. | 17:27.10 |
| | I was clearly on drugs when I wrote that. | 17:27.20 |
| ray_laptop | I didn't realize the code was in toolbin. My bad | 17:27.31 |
| Robin_Watts | params->window>>1. Bonkers. | 17:27.42 |
| | Sorry. | 17:27.49 |
| ray_laptop | Robin_Watts: actually, you must have been on the same drugs as Raph when he wrote 'fuzzy' | 17:27.56 |
| Robin_Watts | I think following fuzzy was a deliberate decision. | 17:28.22 |
| | But that doesn't excuse the lack of comments explaining it in the source. | 17:28.38 |
| ray_laptop | Robin_Watts: well you do have the comment in the fprintf example :-) | 17:29.27 |
| | trying my bmpcmp again. | 17:30.09 |
| | most of my differences probably stem from changing the band height | 17:31.57 |
| | does anyone have an objection to me changing the default MaxBitmap and BufferSpace up to 32M ? | 17:33.28 |
| | hmm... have to ask Henry why he disabled the -Z. debug option (back in 1998). It's still in the docs, but disabled in the code. I wonder if he'll remember ;-) | 17:45.01 |
| | Werner's comment on the FT Type 1 parser provides some concern: "there are examples like Adobe's `optima' family where this fails..." | 17:47.44 |
| | "only" 18 pages of bmpcmp output now :-( | 18:03.05 |
| Robin_Watts | ray_laptop: Welcome to my world. | 18:03.20 |
| ray_laptop | Robin_Watts: the first one (tests_private/comparefiles/Bug690534.pdf.pdf.pkmraw.300.0) on page 2 is interesting. A little blue 'bug' crept in :-) http://www.ghostscript.com/~regression/ray/compare1.html | 18:04.40 |
| Robin_Watts | That's moved from just peeking over the edge of one band to just peeking over the edge of the next. | 18:06.49 |
| | Oh wait, ignore that. | 18:07.01 |
| | It's actually gone away. | 18:07.28 |
| | candidate, reference, diff (CRD) | 18:07.36 |
| chrisl | ray_laptop: Werner's comment holds for most Type 1 interpreters independent of a PS interpreter - if we find a font where something vital is missing, I can always fix Freetype. But it is why I think we should only use this proposed route as a fallback if the PS interpreter throws an error. | 18:08.57 |
| ray_laptop | chrisl: that sounds like a reasonable plan | 18:09.56 |
| | Robin_Watts: thanks. I was looking at the bmpcmp backwards | 18:10.53 |
| chrisl | ray_laptop: actually, do it that way, we probably don't actually *need* to build a real Type 1 dict - the only hiccup I see (at the moment) with using a "dummy" dict might be the encoding. | 18:11.40 |
| ray_laptop | but there _are_ other places in that file where little blue bits do show up in the candidate that aren't there in the ref. My change shows a problem in the clist path logic I think | 18:11.56 |
| Robin_Watts | ray_laptop: Yes, I reckon so. | 18:12.26 |
| | The other images show it "jumping about" | 18:12.51 |
| ray_laptop | henrys: do you recall why you disabled the -Z. with a #if 0 in gdevprn.h ??? | 18:13.06 |
| | memory test ;-) | 18:13.25 |
| henrys | didn't know I did | 18:13.30 |
| ray_laptop | henrys: yeah, on Aug 8, 1998 | 18:13.49 |
| henrys | did I write something in that log thing we use? | 18:14.47 |
| ray_laptop | henrys: since it's still in the docs, I was going to put it back in. Any objections ? | 18:15.08 |
| henrys | quite a mess today - heavy snow before the trees had time to shed their leaves - broken limbs and power lines down all over the place. | 18:15.30 |
| ray_laptop | henrys: sounds like a mess, alright | 18:15.51 |
| henrys | ray_laptop:no objections | 18:16.15 |
| ray_laptop | henrys: a bit early for a heavy snow isn't it ? | 18:16.30 |
| | I bet the ski resorts are happy, though | 18:17.02 |
| henrys | yes a bit early. | 18:17.03 |
| | the higer elevation places opened a while ago A-basin and loveland | 18:17.33 |
| Robin_Watts | ray_laptop: I can only see one #if 0 in gdevprn.h | 18:18.18 |
| | and that's *immediately* followed by a #endif | 18:18.28 |
| ray_laptop | Robin_Watts: line 60 | 18:19.09 |
| Robin_Watts | right. Why is that greyed out for me? I'm sure my machine can't count as arch_small_memory :) | 18:19.51 |
| | fair enough. | 18:20.21 |
| ray_laptop | Robin_Watts: that other (strange) one was from Henry's same commit. | 18:20.53 |
| Robin_Watts | ray_laptop: That was a HUGE commit. | 18:23.45 |
| | Possibly all the changes between 5.14 and 5.27 of gs went in there :( | 18:24.33 |
| ray_laptop | Robin_Watts: yeah, Henry likes those. Check out the one with the comment "DeviceN." (commit 01c26a7) | 18:25.58 |
| Robin_Watts | I fear this isn't henrys fault - it's because of moving from RCS to CVS maybe? | 18:26.31 |
| henrys | unfortunately all that work was done in a separate repository but I do recall we kept the history somewhere. | 18:26.54 |
| ray_laptop | Robin_Watts: right. and the 01c26a7 commit was folding in code from Jan S. that was done "elsewhere" (before we used branches) | 18:27.09 |
| henrys | I think you are far enough back that the history is of marginal interest what exactly is the issue at hand? | 18:27.24 |
| ray_laptop | I was just yanking Henry's change about the 01c26a7 one. | 18:27.32 |
| | henrys: just teasing you. | 18:27.52 |
| henrys | no big deal. It does suck we don't have that work history. | 18:28.33 |
| ray_laptop | not that this instance in gdevprn.h does, but it sort of bothers me when I see code with #if 0 ... #endif and no explanation. Sort of like the comments here and there /* WRONG */ and no explanation | 18:31.25 |
| | back to goiing thru bmpcmp output (and stop bothering henry) | 18:34.45 |
| Robin_Watts | ray_laptop, henrys: I had a quick look at my idea for spotting unused parameters today, but got confused... | 18:40.16 |
| ray_laptop | Robin_Watts: spotting unused parameters ??? | 18:40.44 |
| Robin_Watts | The problem is that if people do -dFOO or -sBAR on the command line, and they don't get used by the device, we have no way of reporting an error. | 18:41.01 |
| | or a warning. | 18:41.13 |
| | it would be nice to be able to say "-dFOO was not recognised" | 18:41.34 |
| ray_laptop | Robin_Watts: right. Because some of the options are NOT device params -- they are for the PS interp or PDF interp | 18:41.54 |
| Robin_Watts | because you can spend ages trying to see why your -dBandheight isn't working :) | 18:41.59 |
| ray_laptop | it would have been nice to have different option syntax for device params vs. other options, I agree | 18:42.55 |
| Robin_Watts | The idea I had was to set a flag in every such parameter when supplied on the command line. And then clear that flag when it's read internally. | 18:43.13 |
| | and then print a warning about any params with the flag still set. | 18:43.28 |
| | but then I spotted that they go into the system dict, and that scared me off. | 18:43.42 |
| henrys | you have to change nearly all devices right? | 18:43.42 |
| Robin_Watts | henrys: No. The params are proffered to the devices via the gs_params_list stuff. | 18:44.08 |
| ray_laptop | henrys: not if you do it in the param list processing | 18:44.09 |
| | Robin_Watts typed faster. | 18:44.24 |
| Robin_Watts | The params list processing is all done via a standard interface, so like ray says, do it there, and we should be sorted. | 18:44.29 |
| | but I'm officially scared of it now, so if anyone who feels more comfortable with that stuff wants to have a go, have at it! | 18:45.04 |
| ray_laptop | but the problem is what to do about non-param list options e.g. -dPDFDEBUG | 18:45.06 |
| Robin_Watts | Being called for food... sorry. | 18:45.10 |
| | Must... obey... boss.... | 18:45.21 |
| ray_laptop | Robin_Watts. enjoy. lunch time for me, too | 18:45.38 |
| | The QA guy would be really spooky that can visually spot a problem with the output from tests_private/pcl/pcl5cats/Subset/AC6Z9SCC.BIN ;-) (maybe Rainman ???) | 18:49.03 |
| Robin_Watts | ray_laptop: If the sole problem is with options like PDFDEBUG (i.e. a known set of options that we define), we can clear the flags on them automatically, right? | 19:08.57 |
| ray_laptop | Robin_Watts: I suppose. But finding all of them won't be easy | 19:09.53 |
| | but I guess we can get most of the commonly used ones | 19:10.25 |
| mvrhel2 | ray_laptop: just tracked down another issue that came up in my attempts to fix XPS transparency patterns | 19:12.40 |
| | it took a bit to find it | 19:12.45 |
| | the issue was that the main pdf14 device had a lingering softmask due to the way that we tied the softmask to the q Q operations in the PDF interpreter | 19:13.19 |
| | so I had to make sure that in the xps interpreter that we pop the softmask when we are all done | 19:13.39 |
| | the xps interpreter was written before we had made softmasks as part of the graphic state | 19:14.15 |
| kens | And not had much attentionsince.... | 19:15.00 |
| mvrhel2 | if the soft mask remained there, we ended up drawing through it when we did the pattern tiling | 19:15.11 |
| | no it has not | 19:15.20 |
| | lunch time | 19:16.19 |
| | you are up late kens | 19:16.27 |
| kens | back online in front of the TV | 19:17.29 |
| | Stella is watching a program that doesn't interest me ;-) | 19:17.48 |
| ray_laptop | the sensitivity of our clist code to band height is horrible. | 19:20.33 |
| Robin_Watts | ray_laptop: Yes. | 19:22.26 |
| | Most (but sadly only most) of the plank vs pamcmyk4 diffs are due to that. | 19:22.43 |
| ray_laptop | I need to back out the part of the changes that affected bandheight and re-run the cluster just to make sure that's all it is :-( | 19:23.25 |
| mvrhel2 | bbiaw. | 20:17.53 |
| Robin_Watts | Damn. I haev a plank clist 64bit linux only problem still. | 20:18.10 |
| | Forward 1 day (to 2011/10/27)>>> | |
IRC Logs