| | <<<Back 1 day (to 2011/09/02) | 2011/09/03 |
| marcosw_ | Robin_Watts: at 600 dpi the pcl plank/pamcmyk4 testing was taking a very long time and eventually timed out. I'm trying at at 300 dpi. | 07:35.35 |
| kens | has just read the irc logs and will leave the seg fault to Robin. Assuming robin reads the logs too. | 08:07.10 |
| | Mornign marcosw_ | 08:07.14 |
| marcosw_ | morning to you as well. | 08:07.29 |
| kens | Did you reply to Tom's question ? I haven't seen an answer | 08:07.31 |
| | And didn't want to send one myself. | 08:07.43 |
| marcosw_ | not yet, I'll do it today. | 08:09.42 |
| kens | OK thanks :-) | 08:09.50 |
| chrisl_away | kens: I'm doing a cluster test on the latest freetype, in case the problem Robin stumbled over is one of the buffer overflow bugs fixed in the last couple of releases. | 08:26.50 |
| | if you can mention that to him when he appears..... | 08:28.37 |
| | off to squash now...... | 08:29.22 |
| kens | wonders if Robin_Watts is here now ? | 08:35.13 |
| Robin_Watts | I am | 09:35.17 |
| kens | Chrisl wanted me to point you at the log, he's done a FT change | 09:36.00 |
| Robin_Watts | I saw a note that he was testing the latest freetype, but I can't see a commit. | 09:36.43 |
| kens | maybe that was all tehn | 09:37.24 |
| Robin_Watts | Lots of differences with chrisl's last test, but not SEGV reported | 09:46.57 |
| kens | Hmm, might be a fix then, or just acover up | 09:47.32 |
| | That really is a lot of diffs.... | 09:51.51 |
| Robin_Watts | kens: Are you at all familiar with 29-07B.PS ? | 09:59.28 |
| kens | Not specifically, what's the problem ? | 09:59.39 |
| Robin_Watts | plank and pamcmyk4 display the content with a large different in position. | 10:01.29 |
| | s/different/difference/ | 10:01.46 |
| | Actually, I think plank is getting it right and pamcmyk4 wrong, so I'm happier :) | 10:02.31 |
| kens | Should be the same though | 10:02.47 |
| Robin_Watts | Do devices have a set of margins ? | 10:03.22 |
| kens | Yes, but not usually for bitmap devices | 10:03.45 |
| Robin_Watts | I think the file reads the margins and positions stuff accordingly. | 10:06.08 |
| kens | Entirly possible, likely even. | 10:06.27 |
| | For a QL test | 10:06.32 |
| Robin_Watts | Everything else is close enough for government work. | 10:06.41 |
| kens | But I'm surprsied the devices would be different | 10:06.41 |
| marcosw_ | Robin_Watts: plank/pamcmyk4 testing of pcl didn't go well, the disk filled up. I'm rerunning it now. | 10:13.27 |
| Robin_Watts | marcosw_: ok, thanks. | 10:13.41 |
| | Did you find any differences so far ? | 10:13.48 |
| marcosw_ | the plank files are all generated first and than the pamcmyk4 files and the disk filled up during the plank file generation, so it didn't get far enough to tell if there were differences | 10:15.12 |
| Robin_Watts | marcosw_: Ah. | 10:40.24 |
| marcosw_ | ah? | 10:40.30 |
| Robin_Watts | Just read your explaination above. | 10:40.43 |
| | Why do it that way? | 10:41.14 |
| | "because that's how the code I have works", I guess. | 10:41.26 |
| | When I run local tests, I generate plank then pamcmyk4 for a file, then compare, then do the next. | 10:41.51 |
| | so the disc space is minimised. | 10:41.55 |
| | and I get results as I go, rather than all at the end. | 10:42.39 |
| | Oddly, when I run back to back tests, I find lots of your differences appear as identical to me. | 10:43.27 |
| marcosw_ | I run N jobs in parallel, so it would b a bit tricky to do it your way using the tools that I have (they are based on the cluster code). I could rewrite it, but to be honest other than running out of disk space this one time it's never mattered. | 10:45.00 |
| Robin_Watts | Fair enough. | 10:45.21 |
| chrisl_away | Hmmm, I hadn't expected that many differences from a freetype update :-( | 11:09.47 |
| Robin_Watts | tor8: There is a patch on casper for you, btw. | 14:09.04 |
| tor8 | Robin_Watts: just did a fetch, can't see anything new | 14:10.00 |
| Robin_Watts | sorry, just double checked myself and I forgot to push it. | 14:10.15 |
| | try now. | 14:10.30 |
| | I looked into how GS was working yesterday, and I think I see what gs is doing differently. | 14:11.13 |
| tor8 | Robin_Watts: right. do you think that patch is what we should do for the 0.9 release? | 14:11.35 |
| Robin_Watts | tor8: yes. | 14:11.53 |
| | Otherwise people will complain of regressions. | 14:12.01 |
| | I haven't run that through sane - got sidetracked with other stuff. | 14:12.38 |
| tor8 | right. doing a sane run now. | 14:12.40 |
| Robin_Watts | thanks. | 14:12.45 |
| tor8 | I spent the last few days knocking down the remaining easy and critical bugs, so I think we're good to go for a release. | 14:13.46 |
| | I'm holding off on the text device until after release, though. It's not stable and/or fast enough yet. | 14:14.14 |
| | the fast version doesn't give good results, and the good version is ridiculously slow. | 14:14.48 |
| | Robin_Watts: yeah, the sane results show a lot more cases with the "dark aa edges" problem. | 14:16.47 |
| Robin_Watts | With my patch, and it disabled ? | 14:17.13 |
| | Sorry, I mean, with the knockout and isolated stuff disabled you're still seeing problems ? | 14:17.33 |
| tor8 | no, I'm saying the diffs show that the knockout/isolated stuff still has issues :) | 14:17.55 |
| Robin_Watts | Ah, right. I am more than aware of that :) | 14:18.06 |
| | gs copies the background on every group push, where I only copy it on isolated ones. | 14:18.49 |
| tor8 | there's only one page that has serious problems with the knockout/isolated stuff being disabled, one with magic marker-style highlighted text. | 14:18.50 |
| Robin_Watts | gs doesn't hold 'shape', it holds 'group alpha', which is what I ended up doing in mupdf effectively. | 14:19.34 |
| | The only thing that worries me about copying what gs does is that gs doesn't support non-isolated knockout groups. | 14:20.05 |
| | so I worry about inadvertantly painting ourselves into the same corner that gs has. | 14:20.24 |
| | chrisl: You here ? | 14:25.20 |
| kens | He says he's away ;-) | 14:25.33 |
| | But then. so do I | 14:25.41 |
| Robin_Watts | yeah, I'm aware of the way irc statuses lie :) | 14:27.28 |
| | I think the problem is in fapi_ft.c - that's our code, not freetypes, right? | 14:40.03 |
| | We get an outline glyph, and then free it as if it was a bitmap glyph. | 14:41.13 |
| kens | Yes that's our code, its the interface | 14:41.53 |
| | chrisl did some changes in there, its probably related | 14:42.07 |
| Robin_Watts | kens: Do you understand it? Have you got 5 mins? | 14:42.09 |
| kens | Hmm, I understood it once.... | 14:42.19 |
| | Let meget a VS open | 14:42.26 |
| Robin_Watts | Line 563 of fapi_ft.c - we call FT_Get_Glyph(ft_face->glyph, &bmg); | 14:43.00 |
| kens | yes, I see that | 14:43.19 |
| | Where is the corresponding free ? | 14:43.46 |
| Robin_Watts | FT_Get_Glyph looks at the ->format field to see what type of glyph we should get - in this case it's 'outl'. | 14:43.48 |
| | The next line :) | 14:43.51 |
| | Well, line 565. | 14:44.13 |
| kens | Hmm, sounds like the format should not be outline | 14:44.33 |
| Robin_Watts | It looks like our code is deciding between outline or bitmap glyph based on a_bitmap. | 14:44.44 |
| kens | Indeed. | 14:44.51 |
| Robin_Watts | but the underlying freetype code is deciding based on ft_face->glyph->format. | 14:45.05 |
| kens | Well, thatr certainly looks like a bad thing, I'm surprised it hasn't bitten before | 14:45.42 |
| | I thin kyou'll need to take this up with chrisl, I'm not sure how to resolve that, but it certainly looks wrong. | 14:47.05 |
| Robin_Watts | I have to walk the dogs. I shall do that now. If chrisl checks in he might see the logs and comment. I suspect this is best left to him to solve. | 14:47.37 |
| kens | I thin kso yes, if he pops back I'll point him at it. | 14:47.54 |
| chrisl_away | Robin_Watts: can you give me a test file to try out this FAPI problem, and I'll look at it tomorrow morning? (I don't have time right now) | 18:20.47 |
| Robin_Watts | chrisl_away: gswin32c.exe -sDEVICE=pkmraw -o out.pkm -r300 -dMaxBitmap=100000000 out.ps | 19:08.42 |
| | where out.ps is in my casper home dir. | 19:09.03 |
| | (or will be when it finishes uploading) | 19:09.18 |
| | Forward 1 day (to 2011/09/04)>>> | |
IRC Logs