| | <<<Back 1 day (to 2011/09/03) | 2011/09/04 |
| kens | chrisl did you see Robin's comments in the irc log yesterday ? | 08:50.43 |
| chrisl | kens: yes, I'm looking now. I think he's right, we should be checking the glyph type, rather than the requested glyph type | 08:51.22 |
| kens | I thougth so too, but its been so long.... | 08:51.37 |
| | Anyway, you've seen ti which is what matters. | 08:51.48 |
| chrisl | Originally, I didn't think we could get to that code with the glyph not matching the requested type, but this is an error condition I haven't seen before "syntax error"..... | 08:52.27 |
| kens | Interesting! | 08:52.44 |
| chrisl | So the ps2write output seems to have a problem. | 08:53.13 |
| kens | OK, well if you can tell me what it is (especially if its a regresion) then I can look at that. | 08:53.41 |
| chrisl | I'll need to dig down into freetype a bit more - I'll let you know. | 08:54.22 |
| kens | No rush ;-) | 08:54.29 |
| chrisl | BTW, the AFS barfs on it, too, so it does really seem to be a problem, not a fluke of freetype | 08:54.47 |
| kens | Fair enough, but it shouldn't cause a seg fault. | 08:55.08 |
| chrisl | No, but then, it doesn't for me. I've clusterpushed the fix, so we'll see...... | 08:55.54 |
| kens | OK, wil be interesting. Its also interesting that it didn't seg fault until after Robin's JPEG fix, which is entirely unrealted. So it must be something to do with the way memory is laid out | 08:56.43 |
| chrisl | Yes, but it's confusing that it still doesn't seg fault for me - I mean, I'm running an almost identical environment to the cluster nodes. | 08:57.50 |
| kens | the cluster node that seg faulted was macpro | 08:58.21 |
| | no idea what Robin used | 08:58.39 |
| chrisl | Robin's command line was for Windows. | 08:59.24 |
| kens | fair enough then | 08:59.34 |
| chrisl | Well, macpro can be (usefully) weird, at times | 08:59.55 |
| kens | Indeed, which is why I mentioned it :-) | 09:00.09 |
| chrisl | My PPC Mac isn't proving terribly useful for mac problems, these days, I may try to pick up a cheap x86 Mac Mini at some point | 09:01.19 |
| | kens: it seems that the charstring contains a multiple master related op code in a non-MM font - some bled op-code | 09:07.19 |
| kens | Sounds like a problem in the original file then. | 09:07.47 |
| | ps2write won't do that | 09:08.05 |
| chrisl | Yes, but I can't imagine we'd keep a file known to fail in the regression tests? | 09:08.59 |
| kens | It might catch the error normally | 09:09.38 |
| chrisl | I'll check with Robin what the original file was - he gave me the ps2write output to save me making it. | 09:10.43 |
| kens | tpc2.ps I think | 09:10.59 |
| chrisl | The only other possibility is that it's actually a corrupted charstring from ps2write, and it *happens* to have that op-code in the corrupted data. | 09:12.20 |
| kens | I think that's unlikely too, unless hte font has changed format we don't re-interpret, we just copy teh CharStrings | 09:13.32 |
| chrisl | That job contains: AdobeSerifMM | 09:14.58 |
| kens | Hmm, not sure about MM fonts | 09:15.15 |
| chrisl | My guess would be it treats an MM font *instance* as just a Type 1 font, and copies the charstring. | 09:16.15 |
| kens | Yes, probably, but I would have to check | 09:16.39 |
| chrisl | I don't think it's worth losing much sleep over - they are deprecated, after all..... unless we put MM substitution in place! | 09:17.33 |
| kens | Well, if I can fix it I should. | 09:18.29 |
| chrisl | Do you want me to raise a bug? | 09:19.22 |
| kens | May as well, I'll foret it otherwise | 09:20.04 |
| chrisl | Okay, I'll do it shortly | 09:20.17 |
| Robin_Watts | chrisl, kens: Morning | 09:20.55 |
| kens | Hi Robin_Watts | 09:21.01 |
| chrisl | good Robin_Watts | 09:21.04 |
| | s/good/good morning | 09:21.14 |
| | I'm having typing trouble already :-( | 09:21.29 |
| Robin_Watts | It was tpc2.ps, yes. | 09:21.46 |
| chrisl | Cool. And using the Freetype glyph type does work, so good call! | 09:22.38 |
| Robin_Watts | Excellent. | 09:22.49 |
| chrisl | Robin_Watts: it's committed now | 09:29.53 |
| Robin_Watts | I wonder if that will fix some indeterminisms... | 12:08.18 |
| henrys | chrisl_away:thanks for the agenda items, I was going to ask you to go ahead and remove the old installer stuff and forgot. | 16:05.52 |
| | robin_watts:I got verification you have the fedex. | 16:11.23 |
| Robin_Watts | henrys: yes, sorry, thought I'd said. I spent sometime this afternoon making an enclosure for it. | 20:49.15 |
| henrys | the situation is weird, you'd think they'd just send us something that works out of the box | 20:55.10 |
| Robin_Watts | henrys: yes. | 23:34.14 |
| sebras | Robin_Watts: in fz_paint_affine_N_near() would it be correct to have dp and sp have the same dimensions while hp is smaller? | 23:54.33 |
| Robin_Watts | sebras: That sounds odd at first glance, but I wouldn't rule it out instantly. | 23:55.29 |
| sebras | Robin_Watts: I have hit a out of boundary bug (on hp) for a PDF, so I'm struggling to understand it. | 23:55.42 |
| Robin_Watts | sebras: Update mupdf and you should find that knockout/isolated are disabled by default, and the problem should go away. | 23:56.18 |
| | Then open me a bug :) | 23:56.28 |
| sebras | Robin_Watts: sp and dp both are 359x507 while hp is 475x21... | 23:56.34 |
| | Robin_Watts: oh, right. I wasn't aware that you have disabled the knockout/isolated stuff. | 23:57.16 |
| Robin_Watts | yes. It's not giving the right blending results in some cases, so pending having the bottomless pit of time that may be required to fix that, and to ensure the impending release goes out without regressions, we've disabled it. | 23:59.57 |
| | Forward 1 day (to 2011/09/05)>>> | |
IRC Logs