| | <<<Back 1 day (to 2018/04/02) | 20180403 |
| kens | chrisl is that a partial fix for the FT [roblem ? | 09:48.50 |
| chrisl | kens: that's the current Freetype code from their git | 09:49.15 |
| kens | Oh! | 09:49.21 |
| | I'm struggling to see how some of those problems are FreeType, but I haven't looked at the files | 09:49.38 |
| chrisl | Freetype is throwing an error on some glyphs | 09:49.55 |
| kens | Ah, I guess that would do it. Presumably taht is also behind hte mis-rendereing of the PDF files | 09:50.16 |
| | It seems 'better' unless I'm mistaken | 09:50.40 |
| chrisl | Yeh, the outline corruption is fixed | 09:51.13 |
| kens | The rendering of the MM in Tekton in test 32 looks like a progression too | 09:51.30 |
| chrisl | Ugh, no it isn't :-( | 09:51.36 |
| kens | Hmm, maybe not | 09:51.45 |
| chrisl | test 18 | 09:51.55 |
| kens | I had candidate and reference sswapped | 09:52.00 |
| | Yeah 18 was the one I was having trouble blaming FT for | 09:52.29 |
| | The corruption doesn't appear to be on a glyph | 09:52.47 |
| | Well, I suppose it could be at the extreme edge | 09:53.17 |
| chrisl | Well, the only change is freetype, so...... | 09:53.31 |
| kens | I assumed that, hence my puzzlement | 09:53.41 |
| | Actually looking at it, I think it *must* be the extremes of the capital letters | 09:54.01 |
| | page 14 you can see its clipped to the top of the glyph Y | 09:54.19 |
| | and X though that's nto quite so clear | 09:54.30 |
| chrisl | eh, page 14? | 09:54.54 |
| kens | Test 18 page 14 ? | 09:55.07 |
| chrisl | Oh, I was looking at 20+ | 09:55.34 |
| kens | Yeah been there already | 09:55.41 |
| | The missing PDF content is undoubtedly due to throwing an error | 09:56.37 |
| | We just abor thte stream in that case | 09:56.43 |
| chrisl | That's what I'm looking at now | 09:57.08 |
| kens | I'll stop bothering you, just curious | 09:57.24 |
| chrisl | TBH, I'm rather baffled - I can't see where the numbers are coming from that trigger the error | 09:58.04 |
| kens | If you want a cardboard programmer, you can shout | 09:58.21 |
| chrisl | At the moment, I genuinely don't know where to start | 09:58.45 |
| kens | Hmm, not good..... | 09:58.56 |
| chrisl | And the debugger just crashed :-( | 09:59.24 |
| kens | My only sense of urgency on this is that Werner is talking about doing a release, and given that 2.9 didn't work for us, it would be ideal if we could make sure the next one does.... | 09:59.44 |
| | Which file are you working on ? | 10:00.34 |
| chrisl | Bug692850.pdf | 10:00.49 |
| kens | Hmm, I think I'd have been inclined to look for a simpler file :-) | 10:01.17 |
| | Actually I'd have to pull the latest FT to look at this, so there's probably no point. If you do want me to try anything, give me a shout. | 10:02.57 |
| chrisl | Once I work out what actually fills in the values, it should help at lot! | 10:03.49 |
| | Test 57 is, umm, weird.... | 10:07.40 |
| kens | hmm, 1 sec | 10:07.47 |
| | I assumed that was a PDF error | 10:08.20 |
| | So its only partly filling the area ? | 10:08.32 |
| | It does seem odd that its even partial though | 10:08.41 |
| chrisl | Oh, no, it's a Postscript error - QL files have their own error handler - doh | 10:08.42 |
| kens | But its a PDF file | 10:09.08 |
| | Unless you think the error was caught during conversion ? | 10:09.18 |
| chrisl | running it to pdfwrite throws an error, but not to ppmraw, I think | 10:09.49 |
| kens | That *is* weird | 10:09.59 |
| | It does seem like its only the PDF file throwing the error | 10:10.23 |
| chrisl | The Postscript error is caught by the QL error handler | 10:10.54 |
| | "TEST FAILEDunknownerror: .FAPIBuildChar" on the backchannel | 10:11.08 |
| kens | But surely that should still result in a diff ? | 10:11.09 |
| | Maybe I missed the file | 10:11.39 |
| chrisl | The *Postscript* file is throwing the error | 10:11.54 |
| kens | Oh I see | 10:12.00 |
| | Odd that its only with pdfwrite | 10:12.28 |
| chrisl | Actually the error is caught by stopped, but the Postscript continues after the error happens. | 10:13.05 |
| kens | Yeah the QL files do that a lot | 10:13.21 |
| chrisl | Oh, might be related to outline glyphs | 10:21.37 |
| | Yep.... I wonder if the glyph bounding box isn't being set correctly for outline glyphs - that might explain why I can't see the numbers being set! | 10:24.15 |
| kens | Sounds like a possibility | 10:24.27 |
| chrisl | Doesn't explain why this error only happens with pdfwrite, though :-( | 10:24.42 |
| kens | Maybe it uses outline glyphs more ? | 10:24.53 |
| | Remember iot runs at 720 dpi | 10:25.13 |
| chrisl | I tried ppmraw at 720dpi, 1200dpi and 1440dpi | 10:25.41 |
| kens | Hmm, not that then I guess | 10:25.55 |
| | OMG did you see the latest email on bug #698731 ? | 10:26.24 |
| chrisl | Jesus :-( | 10:27.40 |
| Robin_Watts | Can anyone give me a reason why we keep penum->clip_inner ? | 10:48.42 |
| kens | Checking if an object is compeltely within the inner cllip ? | 10:49.07 |
| | That is, its not clipped so we cna optimise it, I'm assuming | 10:49.59 |
| Robin_Watts | kens breaks cover... | 10:50.13 |
| | OK, so what is the actually difference between the inner and outer clip ? | 10:50.24 |
| kens | Well the inner clip might be notihing | 10:50.41 |
| | If you consider two concenttric circles | 10:50.57 |
| Robin_Watts | kens: Yeah, the best definition I've been able to come up with is "the inner clip is unhelpful" :) | 10:51.06 |
| | go on. | 10:51.11 |
| kens | Actually circles may not be a good example | 10:51.36 |
| chrisl | Um, is the inner clip actually used anywhere ? | 10:51.38 |
| kens | Ah now *that* I don't know | 10:51.48 |
| chrisl | 'Cause I can only see it being set | 10:52.00 |
| kens | I was thinking that if you had a circle, then teh outer clip is the circle, while the inner clip is empty | 10:52.09 |
| | But if your clip was two concentric circles, the inner clip could be the inner circle | 10:52.24 |
| | So any object completely within the inner clip would nto be clipped at all | 10:52.34 |
| Robin_Watts | chrisl: Indeed, penum->inner_clip is set but not used as far as I can see. | 10:52.45 |
| kens | This is, of course, compelte speculation | 10:52.48 |
| | Remove ti and see what happensd ? | 10:53.05 |
| Robin_Watts | kens: Ah, so the inner clip box is "if it's in here, it's trivially unclipped" | 10:53.36 |
| kens | Well, possibly | 10:53.43 |
| Robin_Watts | and the outer clip box is "if it's in here, it needs testing". | 10:53.47 |
| | That at least makes some sort of sense. | 10:53.54 |
| kens | Well, its what it would mean if I wrote it :-) | 10:54.04 |
| | But in honesty I don't knwo that's the case | 10:54.12 |
| Robin_Watts | Gah. | 11:04.40 |
| kens | I assume that's something bad | 11:04.50 |
| Robin_Watts | GS makes the device that I need to use in each callback after the init call to my code has been made. | 11:05.04 |
| | so I can't pass in the device at init time. | 11:05.10 |
| | Means I need to change the API to my new code a bit. | 11:05.21 |
| kens | Ah.... | 11:05.33 |
| Robin_Watts | Currently my output is not being clipped, cos I'm getting the wrong device. | 11:05.40 |
| kens | Robin_Watts : what I was going to ask yesterday, can you make that change in fitz/system.h ? SO that importing the solution to VS 2008 doesn't throw lots of errors on __restrict | 11:06.18 |
| Robin_Watts | Sure. | 11:06.31 |
| kens | Thanks | 11:06.34 |
| | FWIW 1600 worked fine for me | 11:06.42 |
| | I suspect I must have run into this before, because my desktop version already had it set to 1900.... | 11:07.20 |
| Robin_Watts | where are the errors given again? | 11:08.12 |
| kens | Everhere that stdint is cinluded | 11:08.22 |
| | <sigh> typos... | 11:08.30 |
| | Everywhere that stdint is included | 11:08.44 |
| Robin_Watts | OK, ta. | 11:09.09 |
| deekej | hello chrisl, I was trying the patch from http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=282560f5ae3 | 12:07.02 |
| | unfortunately the build fails for me | 12:07.17 |
| | make[2]: *** No rule to make target 'psi/dxmain.c.c', needed by 'sobin/gsx'. Stop. | 12:07.41 |
| | make[1]: *** [base/unix-dll.mak:296: so-subtarget] Error 2 | 12:08.04 |
| | make: *** [base/unix-dll.mak:245: so] Error 2 | 12:08.04 |
| chrisl | Did you remake configure? | 12:08.08 |
| deekej | ah, that's it, probably | 12:08.25 |
| | I forgot there was a change to configure | 12:08.34 |
| | give me minute :) | 12:08.43 |
| | ok, sorry for the noise, the build has passed now | 12:17.58 |
| | I'm trying it in Koji as well right now, but it looks good | 12:18.13 |
| chrisl | deekej: Assuming it all runs through okay, can you put that in the bug please? Hopefully, the homebrew guys will chip in, too | 12:18.56 |
| deekej | sure :) | 12:19.10 |
| chrisl | Thanks | 12:19.17 |
| | kens: got a sec? | 13:45.45 |
| kens | Yes sure | 13:45.50 |
| chrisl | Can you take a look at https://ghostscript.com/~regression/chrisl/compare2.html test 15 | 13:46.02 |
| kens | Hmm yes that one again | 13:46.24 |
| chrisl | Well, the font is broken | 13:46.42 |
| kens | Ah.... | 13:46.54 |
| chrisl | To the extent that Acrobat throws an error on it | 13:46.59 |
| kens | Oh that's really quite broken then | 13:47.10 |
| chrisl | The corruption is actually a / glyph, which *is* referenced in the stream | 13:47.47 |
| kens | Huh, that claims to be a Smart Office bug..... | 13:47.54 |
| chrisl | No.... https://bugs.ghostscript.com/show_bug.cgi?id=693711 | 13:48.10 |
| kens | Oh, so it was wrong before, and wrong in a more visible fashion now | 13:48.12 |
| | Oh I can't type again, transposed 3 & 7 | 13:48.29 |
| chrisl | I suspect this is actually freetype doing a *better* job of coping with a broken charstring | 13:48.48 |
| kens | Could be, yes. I see form the bug report that I said way back then that the font was broken | 13:49.13 |
| | So it seems to me this isn't a problem, we cna accept the changed rendering | 13:49.29 |
| chrisl | That's my feeling | 13:49.39 |
| kens | Well, if the font is broken, all bets are off. If Acrobat won't render it then I think we're good to say that | 13:50.15 |
| chrisl | Acrobat has a go.... but throws up a "can't extract...." dialogue | 13:50.48 |
| kens | I think tha'ts not unreasonable | 13:51.00 |
| | We could do that too, but I'm happy enough with the rendering being changed | 13:51.17 |
| chrisl | It would be problematic to warn (or error) since freetype now doesn't give up. I could look at why, and if we could work around it, but I'm not feeling it's worth the effort | 13:52.12 |
| kens | I really don't think its wirth the effort, broken fonts are broken.... | 13:52.29 |
| | If that's the only remaining problem, then I htink its good | 13:53.04 |
| chrisl | So, a small tweak in our code can work around the feetype error, and the current freetype code is fine | 13:53.11 |
| kens | Excellent | 13:53.19 |
| | Shall I tell Werner or would you rather ? | 13:53.35 |
| chrisl | I'm just replying now | 13:53.43 |
| kens | :-D | 13:53.47 |
| | I guess when he does the next FT release we should upgrade to that, and just skip 2.9 altogether | 13:54.58 |
| chrisl | That is my intent - I can't be bothered using a patched 2.9 right now | 13:55.22 |
| kens | There seems little point, since Werner is talkign about an imminent release | 13:55.41 |
| tor8 | kens: chrisl: what is the problem with 2.9? I know there were several bugs in 2.8 that prevented mupdf from updating, but I reported those and they were fixed. | 13:57.05 |
| kens | tor8 there was corruption of the glyphs, I'm not sure if chrisl diagnosed it or just found that upgrading to HEAD of FT fixed them | 13:57.32 |
| chrisl | tor8: There was some weird outline corruption with Type 1 fonts in 2.9 | 13:57.33 |
| kens | tor8 maybe you hsould check the next release when it comes out. | 13:58.08 |
| tor8 | chrisl: hm, not related to the CFF advance widths that were missing in 2.8? | 13:58.52 |
| kens | The glyphs were rendering incorrectly, which doesn't *sound* like advance widths | 13:59.24 |
| chrisl | tor8: No, this was genuine outline corruption - like there was a closepath in the wrong place | 13:59.31 |
| tor8 | that doesn't sound like what I found | 13:59.44 |
| | and I haven't mustered the energy to go through the clusterpush bmpcmp diffs that updating to 2.9 creates... | 14:00.21 |
| kens | Really ? Chris's bmpcmp was only 5 pages | 14:00.45 |
| | That's to HEAD of FT though, 2.9 had more changes | 14:01.03 |
| chrisl | 2.9 had a few more - like 10-12, I think | 14:01.16 |
| tor8 | kens: I saw hundreds of pages last I checked... | 14:01.53 |
| kens | Oh, it really wasn't anything like that when Chris tested 2.9 | 14:02.11 |
| tor8 | I guess I should test it again then :) | 14:02.26 |
| kens | Though in fariness, I don;t know what previous version we were using | 14:02.28 |
| chrisl | We're using 2.7 | 14:04.01 |
| | I ignored 2.8 as I remembered tor8 finding problems | 14:04.26 |
| kens | Ah! | 14:04.36 |
| | So MuPDF shouldn't really be much worse than us then in going forward I'd have thought | 14:04.54 |
| tor8 | mupdf is still on 2.6.3 and that may be what's causing more diffs than gs | 14:05.28 |
| kens | Oh that is a little further back, I guess it could be | 14:05.40 |
| chrisl | Oh, I think there were *lots* when I upped to 2.7 | 14:05.58 |
| tor8 | the CFF code in freetype has had a lot of work since then | 14:06.00 |
| kens | Chris normally keeps us up to date | 14:06.06 |
| tor8 | but I guess since you use 2.7 I could safely go to that first :) | 14:06.17 |
| kens | Our requirements might differ..... | 14:06.32 |
| tor8 | mupdf's requirements are usually more modest. | 14:06.56 |
| kens | But it does seem a reasonable position yes | 14:06.57 |
| chrisl | We drive feetype *very* differently, and also don't rely on it for (all) metrics..... | 14:07.09 |
| tor8 | the most unusual requirement is for us to need support for naked CFF fonts | 14:07.17 |
| | but I think gs does that too, to cope with embedded CFF fonts in PDF | 14:07.27 |
| kens | defers to chrisl | 14:07.42 |
| chrisl | To all intents and purposes, yes | 14:08.08 |
| | In gs they are wrapped up as Type 2 PS fonts, but they end up being passed to freetype as a "bare" cff | 14:09.10 |
| | FWIW, I don't think bare cff is *that* rare in freetype's world | 14:09.34 |
| | tor8: the first test shows the (main) issue I was seeing with 2.8: https://ghostscript.com/~regression/chrisl/ | 14:16.26 |
| kens | Hey Michael ? Just a reminder, Ron asked us to direct people to https://artifex.com/contact-us, rather than sales@artifex.com. Apparently they're trying to phase out the sales@ address. | 19:27.39 |
| HenryStiles | sebras: I've got about 15K attachments and they compress down to 12G, seems like it should be more but maybe not. You and ken should be able to just download these no? | 20:33.44 |
| | sebras: they're in picas.ghostscript.com:attachments.tar.gz | 20:37.44 |
| | sebras: they're in picas.ghostscript.com:/home/henrys/attachments.tar.gz | 20:38.00 |
| | enough python and sql for one day for me. | 20:39.24 |
| | sebras, kens (logs) after looking at bandwidth costs (cheap) and not wanting to add more accounts to picas I decided to push the attachment data to casper, I'll let you know when it finishes | 23:25.43 |
| | Forward 1 day (to 2018/04/04)>>> | |
Log of #ghostscript at irc.freenode.net.