| | <<<Back 1 day (to 2011/11/13) | 2011/11/14 |
| kens | marcosw_ : is up late | 08:59.54 |
| marcosw_ | I'm in Germany, so not particularly late :-) | 09:00.19 |
| kens | Or possibly in Germany ? | 09:00.20 |
| | Aha. | 09:00.24 |
| marcosw_ | bloody cold here... | 09:00.41 |
| kens | marcosw_ : The DeviceN EPS file is 'properly' handled. | 09:00.47 |
| marcosw_ | how is it in the UK? | 09:00.48 |
| kens | gray | 09:00.56 |
| | PostScript should not interrogate h device and send different code depending what it gets. | 09:01.21 |
| | Howver, since its an Adobe output.... | 09:01.33 |
| marcosw_ | so it's a badly constructed file... | 09:01.34 |
| kens | Its not a decent way to do the job. | 09:01.44 |
| | But like I said, its from InDesign. Recent Adobe PostScript output is cr*p | 09:02.01 |
| | I'll see if I can come up with an Idiom to 'fix' it | 09:02.12 |
| | After I finish Til''s files. | 09:02.37 |
| marcosw_ | okay, btw, I'm testing the XMP issue now. will let you know what I find,. | 09:04.28 |
| kens | OK thanks. | 09:07.13 |
| | tkamppeter hi | 09:09.46 |
| tkamppeter | kens, hi | 09:09.57 |
| kens | My fix over the weekend introduced *many* problems, so I was forced to rework it. | 09:10.05 |
| | I'm testing a new fix now. | 09:10.10 |
| tkamppeter | kens, great. | 09:10.28 |
| kens | Your new bug #692679 appears to be fixed in the current HEAD | 09:10.30 |
| | tkamppeter, woudl it be possible to add some context when creating bug reports, with repsect to your likely release dates ? With #692626 I didn't assign the problem any urgency, because I assumed that it didn't need to be fixed until the next scheduled Ubuntu release, I didn't realise you were planning an interim patch. | 09:12.08 |
| | As a result I worked on some other problems that hsould have had a lesser priority instead :-( | 09:12.38 |
| tkamppeter | OK, will do. | 09:16.56 |
| kens | THat's great! Many thanks Till | 09:17.31 |
| | Juts got the test resutls back, much better, but three files show differences, I'm looking into why now, tehy could be improvements | 09:17.55 |
| tkamppeter | If you can extract a simple patch to fix 692679 I will join it to the Oneiric update which fixes 692626. | 09:18.02 |
| kens | Yes, I knew you were going to ask that ;-) | 09:18.12 |
| | I'll see if I cna work out how to use Git bisect to find the patch | 09:18.23 |
| kens | goes off to read the Git boook of words | 09:19.24 |
| | chrisl do you know the Git SHA1 for the 9.04 release ? | 09:24.05 |
| chrisl | kens: you can start a git bisect with the tag - "git bisect good ghostpdl-9.04" | 09:26.33 |
| kens | That'll do fine, thanks chrisl | 09:26.51 |
| chrisl | kens: note that I *think* your logic for this will be reversed - I think bisect expects the "good" commit to be earlier than the "bad" commit, not totally sure, though | 09:27.46 |
| kens | I believe this is true, yes | 09:27.58 |
| | Certainly the example works that way | 09:28.06 |
| | It seems to be constructed to look for regressions | 09:28.18 |
| chrisl | Yes, exactly. | 09:28.27 |
| Robin_Watts | kens: git log ghostscript-9.04 -1 | 09:32.30 |
| kens | THanks | 09:32.48 |
| Robin_Watts | (No idea if you got the answer - the logs aren't quite complete yet :) ) | 09:32.55 |
| kens | FWIW my tests so far show one regression and one progression :-( | 09:33.04 |
| | And one which was wrong before, wrong now, but different | 09:33.52 |
| Robin_Watts | http://www.ioccc.org/ : Can we submit ghostscript ? :) | 09:46.06 |
| kens | Oh god, I thought that competition had died.... | 09:47.41 |
| chrisl | marcosw_: the patched Windows builds are up in my user area on casper called gs904w??-20111114.exe - it would be good if you could test the 32 bit one to make sure I didn't screw up the patches. | 10:20.14 |
| marcosw_ | thx. I'll test the 32 bit one to see if it works with the customer's file. | 10:20.45 |
| tkamppeter | kens, thanks for the quick fix, I will try it now. | 10:53.06 |
| kens | OK tkamppeter, working on git bisect now | 10:55.13 |
| | marcosw the fix for UUID was git commit f369ae5a30143cdfc27df96de9b1b5bab1c72c6f | 11:05.33 |
| marcosw_ | that makes more sense, the commit that I was looking at was 31c64dd9fc97863367c719e34ac1ddcb0f2b7025, which did make it into 9.04 | 11:11.43 |
| | the thing is that f369ae5a30143cdfc27df96de9b1b5bab1c72c6f is dated August 23rd and 31c64dd9fc97863367c719e34ac1ddcb0f2b7025 is dated August 15th. | 11:13.22 |
| kens | Yes, the sfirst one was hte UUID 'fix' the second was the one that corrected the buffer overrun for that fix | 11:14.14 |
| tkamppeter | kens, your patch for 692626 works perfectly applied on 9.04. I will apply it. | 11:19.14 |
| kens | OK I'm still tracking down the other fix | 11:19.29 |
| | OK anyone any suggestions on what to do when git bisect comes up with a revision that won't build ? | 11:24.10 |
| chrisl | I've always been able to fix the build fairly easily, test it, and then revert the file(s) so bisect can continue | 11:25.11 |
| Robin_Watts | kens: git bisect skip | 11:25.41 |
| kens | Well its griping that it can't make 'cups/gdevcups.c' | 11:25.50 |
| Robin_Watts | it picks another one close by. | 11:25.50 |
| kens | right, thanks Robin_Watts | 11:25.57 |
| chrisl | Or leave out cups...... | 11:26.21 |
| kens | git bisect skip aborts telling me to commit or stash my changes :-( | 11:30.22 |
| | Which would be understandable if I'd made any | 11:31.47 |
| | I think its a white space fudge | 11:32.24 |
| | I seem to remember having this problem before with Git and this file. | 11:33.03 |
| Robin_Watts | git diff should give you what it thinks it's changed. | 11:33.36 |
| kens | Yes its the openjpeg file opj_malloc.h | 11:34.24 |
| | In its entirety | 11:34.42 |
| | So I think its line endings | 11:34.47 |
| | And now I'm, stuck | 11:35.02 |
| Robin_Watts | Can you not git reset that file? | 11:36.12 |
| | or delete it, then git checkout -- filename ? | 11:36.23 |
| chrisl | Can you convert the line-endings and see if git then realises it hadn't changed | 11:36.26 |
| kens | I don't think so. | 11:36.50 |
| | I seem to recall the problem is that it changes them when copying | 11:37.04 |
| | 'reverting' the changes has no effect | 11:37.34 |
| | It just puts them straight back | 11:38.21 |
| | stashing the changes fials. | 11:39.24 |
| Robin_Watts | kens: OK. Record the hash that you're having a problem with. | 11:40.20 |
| kens | Yes, got that | 11:40.32 |
| Robin_Watts | Then git bisect visualize | 11:40.36 |
| kens | OK | 11:41.03 |
| Robin_Watts | Then you can run 2 git bisects: from hash~1 to the 'last known good' one. | 11:41.19 |
| | And from 'first known bad' to whatever the one after hash is. | 11:41.32 |
| kens | Yes, but I can't "git bisect reset" my current checkout | 11:42.02 |
| | Hence 'stuck' | 11:42.30 |
| Robin_Watts | git reset --hard HEAD~1 | 11:42.59 |
| | Then git bisect skip hash | 11:43.29 |
| | That will move you back one, and mark hash as being skipped. | 11:43.50 |
| | Then continue. | 11:43.59 |
| kens | "Please commit your changes or styash them before you can switch branches. Abroting" | 11:44.52 |
| | On the skip | 11:45.01 |
| Robin_Watts | OK, so the same problem occurs. | 11:45.10 |
| | record the hash. do the same thing. | 11:45.21 |
| kens | Current hash ? | 11:45.35 |
| Robin_Watts | OR... | 11:45.36 |
| | better plan. | 11:45.42 |
| | You've now correctly identified 'hash' as being skipped. | 11:46.02 |
| | What is dying is the automatic selection of the next one to test. | 11:46.14 |
| kens | I think so | 11:46.17 |
| | Actually, nt sure | 11:46.25 |
| Robin_Watts | Well, git visualise. | 11:46.35 |
| kens | Its the checkout that it doesn't like | 11:46.37 |
| | If I can go 'back' to the has before OpenJPEG was added it should be OK again | 11:46.58 |
| | Maybe if I go back HEAD~2 | 11:47.33 |
| Robin_Watts | Right. So git visualize, and pick yourself the one before openJPEG was added. | 11:47.34 |
| | Then git reset --hard the_hash_before_openjpeg | 11:47.59 |
| | Then test that, then git bisect good/bad as appropriate. | 11:48.14 |
| kens | OK I have a working checkout again. | 11:48.23 |
| | Need to find out if it works | 11:48.29 |
| | The line endings problem was sorted in 58d195 | 11:50.50 |
| | Damn, its come back again! | 11:54.54 |
| | OK I've managed to abor thte bisect. | 11:57.15 |
| | How do I find out what hash I'm on anyone ? | 11:57.51 |
| Robin_Watts | kens: git log HEAD -1 ? | 11:59.21 |
| kens | Yes, I think that works | 12:00.25 |
| Robin_Watts | If you know the 'range' of broken line endings, then you can: git bisect skip start..stop | 12:00.27 |
| kens | Started a new bisect since then... | 12:00.35 |
| Robin_Watts | and that will automatically ensure that you NEVER get asked to test one of those. | 12:00.52 |
| kens | Hopefully avoiding teh build messes | 12:01.00 |
| vdp | hi everyone! any mupdf developers here? | 12:18.10 |
| Robin_Watts | vdp: Yup. | 12:21.34 |
| vdp | I am playing with mupdf on Kindle. It seems to be significantly faster than poppler, but fails to render some files. e.g. this one: http://www.inference.phy.cam.ac.uk/itprnn/book.pdf | 12:23.50 |
| | most probably the reason is not in mupdf itself because this file is rendered fine in sumatra | 12:24.19 |
| Robin_Watts | vdp: You've ported mupdf to kindle ? | 12:24.26 |
| vdp | you mean the viewer? not for the moment. I am just testing pdfdraw to see how fast it renders the pages | 12:25.05 |
| Robin_Watts | right, but it's actually your own port. | 12:25.49 |
| | rather than using someone elses. | 12:26.00 |
| vdp | well it is hardly a port, just cross-compile | 12:26.17 |
| Robin_Watts | OK, so you're not getting the content, just the blurb about "on screen viewing is OK" ? | 12:28.19 |
| vdp | the pages of the above file are rendered completely blank, both on my desktop and on kindle | 12:28.41 |
| | actually yes | 12:29.14 |
| | I think this text was shown | 12:29.23 |
| | do you have an idea what could be wrong? | 12:33.57 |
| Robin_Watts | yes. just looking now. | 12:34.06 |
| vdp | ok thanks a lot :) | 12:34.14 |
| | Robin_Watts: have to go now. will be back in about an hour. thanks again for looking | 12:38.42 |
| Robin_Watts | np | 12:38.54 |
| tor8 | Robin_Watts: interesting use of 'W' in that file | 12:42.24 |
| Robin_Watts | Not got that far... | 12:42.44 |
| tor8 | pdfshow book.pdf 6 | 12:42.52 |
| | Q q W | 12:43.28 |
| | 283.464 425.197 m | 12:43.28 |
| | 5638.46 425.197 l | 12:43.29 |
| | 5638.46 8003.2 l | 12:43.29 |
| | 283.464 8003.2 l | 12:43.29 |
| | h n q | 12:43.30 |
| Robin_Watts | Producer (GNU Ghostscript 6.53) | 12:43.47 |
| | so be nice :) | 12:43.50 |
| tor8 | odd placement of the W, you think that the handling we changed for it may cause this mess? | 12:45.31 |
| Robin_Watts | yeah. | 12:45.43 |
| tor8 | yeah, if I move the W to after the h, I can see the page contents | 12:46.20 |
| Robin_Watts | Maybe 'W' should just set a flag to say "when we come to do something with the path, also set the clipping path". | 12:46.42 |
| | (so n, or f or b etc) | 12:46.59 |
| tor8 | so basically revert to what we had before we started thinking about what should really happen :) | 12:47.14 |
| Robin_Watts | yeah. | 12:47.20 |
| | neat trick: git cluster filter=WARNINGS_ONLY | 12:49.09 |
| tor8 | Robin_Watts: while still distracted by monday mornings ... the try/catch stuff, why not store the jmp_bufs on the stack? | 13:01.13 |
| Robin_Watts | rather than in the context? good question. | 13:01.56 |
| | Stack usage? | 13:02.16 |
| | I'm sure there must have been a reason. | 13:02.23 |
| tor8 | there's the 'failed' flag, but if we stick it on the stack, it's one less thing to pass around | 13:02.36 |
| | and we could get rid of the unsightly ctx argument to fz_try and fz_catch | 13:02.58 |
| Robin_Watts | hold on. Need to look at source. | 13:03.54 |
| tor8 | fz_try creates its own block anyway, nothing prevents us from adding a local variable for jmp_buf and failed (which would be shadowed if you nest them) | 13:04.12 |
| Robin_Watts | We can't put failed in the try block. | 13:06.01 |
| | because it's read at the start of the catch. | 13:06.13 |
| | and we can't put a block around the whole thing. | 13:09.08 |
| tor8 | not without adding a macro to end it, no | 13:09.28 |
| | I am a bit unclear about the need for the failed flag though | 13:09.53 |
| Robin_Watts | I prefer (ctx) to fz_catch_end | 13:09.56 |
| | yeah, I see what you mean. | 13:11.22 |
| tor8 | it seems to me the only reason for 'failed' is to allow fz_catch | 13:11.33 |
| | as a keyword | 13:11.37 |
| | we could get the equivalent as if (fz_try(ctx)) { ... } else { ... } | 13:12.05 |
| Robin_Watts | Or we #define fz_catch } else | 13:12.30 |
| | well, } while (0); } else | 13:12.49 |
| tor8 | oh, I know why we need the ctx. I blame monday! | 13:14.16 |
| | we still need the ctx, but we don't have to store the jmp_buf in it | 13:14.42 |
| kens2 | OK git bisect finished and worked. | 13:14.48 |
| tor8 | but since we need it anyway, might as well keep it there | 13:14.50 |
| kens2 | tkamppeter I updated the bug report so you should get an email with the relevant revision number. | 13:15.14 |
| Robin_Watts | tor8: It's monday here too... why do we need the ctx ? | 13:15.30 |
| tor8 | for the longjmp! | 13:15.35 |
| Robin_Watts | ? | 13:16.12 |
| | Oh, D'oh! | 13:16.22 |
| | I am tempted to lose the 'failed' flag though. Let me consult with Paul as to why it was done like that. | 13:17.08 |
| tor8 | what's your thought on using if (try) ... else ... instead of macro keywords? | 13:18.12 |
| | hm, probably won't work, we need to pop the jmp_buf stack somewhere | 13:19.46 |
| | Robin_Watts: I found a neat syntax trick for that | 13:26.48 |
| | for (flag=1; flag; pop_jmp_buf(), flag=0) ...try-block... | 13:28.12 |
| | gets rid of the do/while at the same time | 13:28.27 |
| Robin_Watts | Where is flag defined? | 13:40.58 |
| tor8 | #define fz_try(ctx) \ | 13:41.20 |
| | if (!setjmp(fz_push_jmp_buf(ctx)) { int _F; \ | 13:41.20 |
| | for (_F=1; _F; fz_pop_jmp_buf(ctx), _F=0) \ | 13:41.21 |
| | do { // allow break in try/catch | 13:41.21 |
| | #define fz_catch(ctx) \ | 13:41.21 |
| | } while (0); } else | 13:41.21 |
| Robin_Watts | That doesn't work :( | 13:41.50 |
| tor8 | I'm looking into further tweaks to store jmp_buf on the stack | 13:41.57 |
| | why not? | 13:42.02 |
| Robin_Watts | on phone. | 13:42.10 |
| | ok, off phone. | 13:55.04 |
| | In the event that you 'throw', you won't pop in your code. | 13:55.15 |
| | I have a formulation that works though, I think. Just a mo. | 13:55.53 |
| | #define fz_try(ctx) \ | 13:56.52 |
| | if (fz_push_try(ctx->error), \ | 13:56.54 |
| | !setjmp(ctx->error->stack[ctx->error->top].buffer)) \ | 13:56.56 |
| | { do { | 13:56.58 |
| | #define fz_catch(ctx) \ | 13:56.59 |
| | } while(0); \ | 13:57.01 |
| | ctx->error->top--; \ | 13:57.02 |
| | } \ | 13:57.04 |
| | else if (ctx->error->top--, 1) | 13:57.06 |
| tor8 | throw could pop automatically? | 13:57.34 |
| Robin_Watts | Using 'for' probably has a cost in terms of compiled code. | 13:58.22 |
| | Using do { ... } while (0); shouldn't. | 13:58.45 |
| tor8 | Robin_Watts: http://pastebin.com/Eq0w1tvq | 14:03.08 |
| | quick prototype, seems to work | 14:03.21 |
| Robin_Watts | statics ? | 14:03.47 |
| tor8 | you mean lines 4 and 5? | 14:04.09 |
| Robin_Watts | yeah, but I understand that's just prototyping. | 14:04.25 |
| tor8 | old habit, we'd stick 'em in a context | 14:04.26 |
| | just to see if the concept works | 14:04.39 |
| Robin_Watts | I worry that the for() will cost cycles. | 14:04.40 |
| tor8 | yeah. we can probably use the do/while like you posted | 14:05.01 |
| Robin_Watts | The compiler can't be smart enough to see that the for only ever runs once. | 14:05.03 |
| | The do { } while (0); really ought to be simple enough for the compiler to resolve :) | 14:05.29 |
| tor8 | the throw call pops the stack in this prototype | 14:05.32 |
| Robin_Watts | yes, I can see that. | 14:05.39 |
| tor8 | and the for stuff is overkill, like you said | 14:05.44 |
| | just a neat syntax trick I stumbled upon | 14:05.51 |
| Robin_Watts | Yes, by having the throw do the pop, we could save the extra complexity in the else if in the catch in my one too. | 14:07.21 |
| tor8 | #define try \ | 14:07.34 |
| | if (!setjmp(*fz_push_jmp_buf())) { do { | 14:07.34 |
| | #define catch \ | 14:07.34 |
| | } while (0); fz_pop_jmp_buf(); } else | 14:07.34 |
| Robin_Watts | yes, there is a certain nice symmetry about that. | 14:07.57 |
| | but the fz_pop_jmp_buf doesn't need to be a function call. | 14:08.28 |
| | (and indeed it would be nicer if it wasn't) | 14:08.36 |
| tor8 | yeah, we should put all safeguards in the fz_throw function | 14:09.05 |
| Robin_Watts | nor does the push, for that matter. | 14:09.10 |
| tor8 | the push needs to check for overflow | 14:09.18 |
| Robin_Watts | right, yes. | 14:09.31 |
| tor8 | unless we use pointers to stack allocated jmp_bufs | 14:09.42 |
| | so push would be: jmp_buf this_buf, *old_buf; old_buf = ctx->jmp_buf; ctx->jmp_buf = &this_buf; | 14:10.52 |
| Robin_Watts | Put x = struct { jmp_buf, prev } onto the stack, and set x->prev = ctx->except, ctx->except=&x ? | 14:11.06 |
| tor8 | and pop: ctx->jmp_buf = old_buf; | 14:11.09 |
| Robin_Watts | yeah. | 14:11.20 |
| tor8 | exactly | 14:11.26 |
| Robin_Watts | How large is a jmpbuf typically? | 14:11.41 |
| tor8 | 148 bytes on macosx | 14:12.16 |
| | 72 bytes on 32-bit macosx | 14:12.42 |
| Robin_Watts | Do we really want to add 150 bytes per recursion to our stack usuage? | 14:14.25 |
| tor8 | and it's an array type, to mess with &-semantics and pass-by-reference | 14:14.27 |
| Robin_Watts | I think I'm tempted to leave it preallocated. | 14:14.45 |
| | (It also allows us to do 'clever' things in future by tracing exceptions etc if we want to) | 14:15.10 |
| tor8 | I have no strong opinions either way | 14:15.17 |
| | but we should get rid of the failed variable now we've figured out how :) | 14:15.36 |
| | I'm also fine with having fz_push_jmp_buf be a static inline function in the header | 14:16.23 |
| | like we do for fz_read_byte for performance reasons | 14:16.32 |
| Robin_Watts | failed - yes. | 14:16.36 |
| | and inline, yes. | 14:16.56 |
| tor8 | and we can drop fz_pop_jmp_buf altogether (or at least in the catch macro) | 14:17.16 |
| Robin_Watts | yeah. | 14:17.22 |
| tor8 | having written some more muxps code (I added outline/table of contents support) last week, I found myself wanting exceptions! | 14:18.17 |
| Robin_Watts | :) | 14:18.25 |
| tor8 | despite my initial misgivings, I think it's a direction worth going | 14:18.45 |
| | still not happy about ctx though ;) | 14:18.53 |
| | should I undo the 'W' clip operator or do you want to cook up a patch? | 14:19.48 |
| | I should be diving into adding search to the ios app | 14:20.00 |
| Robin_Watts | I'll have a go in a bit, sure. | 14:20.10 |
| | Just bashing at the planar patch for gs. | 14:20.17 |
| | I need lunch. bbs. | 14:32.50 |
| | tor8: What branch would you like the W fix on ? | 15:44.44 |
| | master or ios? | 15:44.49 |
| tkamppeter | kens2, thank you for finding the patch which fixed the bug, I applied it to Oneiric's GS 9.04 and the bug goes away with it. | 15:45.09 |
| Robin_Watts | Can you ensure you've pushed your master up to date please? | 15:45.11 |
| tor8 | Robin_Watts: ios would be easiest. I think I can just push the ios branch to master now. | 15:46.25 |
| kens2 | tkamppeter, that's great news. | 15:46.29 |
| | So you are OK for youir patch release now ? | 15:46.39 |
| Robin_Watts | tor8: Shall I wait for you to do that ? | 15:46.40 |
| tor8 | let's hope I don't spam gs-commits this time | 15:48.31 |
| | odd, I don't get any gs-commit messages | 15:51.51 |
| | Robin_Watts: I've pushed master to casper's main mupdf.git now | 15:52.03 |
| Robin_Watts | fab. | 15:52.09 |
| | Have you pushed your changes to the "context" branch out too? | 15:52.41 |
| | or should I push my changes to remove 'failed' ? | 15:53.09 |
| tor8 | remotes/robin/context is the latest stuff right? | 15:53.39 |
| Robin_Watts | Yes. | 15:54.04 |
| tor8 | my remotes/robin/failing_allocs is the same as remotes/tor/context, both ancestors of remotes/robin/context | 15:54.06 |
| | so you can prune the failing_allocs branch | 15:54.13 |
| Robin_Watts | ok. | 15:54.33 |
| tor8 | and I'll sync tor/context to mirror robin/context | 15:54.34 |
| Robin_Watts | tor8: Have you taken on the gridfitting changes ? | 15:55.36 |
| tor8 | Robin_Watts: no, I'd like to split them out from the arm scaler stuff | 15:55.52 |
| | and I still haven't got round to getting you that object file :/ | 15:56.03 |
| Robin_Watts | Have a look at my 'master' branch on casper now. | 15:56.27 |
| | That has the Android and ARM stuff in one commit, and the simple scale in another. | 15:56.51 |
| tor8 | right, I see you rebased them now :) | 15:56.58 |
| Robin_Watts | I'll put the grid fitting fixes in on top of that. | 15:56.59 |
| tor8 | okay | 15:58.12 |
| kens2 | OMG Tor is at it again.... | 16:13.39 |
| | 36 commits | 16:13.53 |
| tkamppeter | kens2, I think it is all for the patch release now, thanks. | 16:16.47 |
| Robin_Watts | tor8: Have you changed fz_arc4_init recently ? | 16:17.01 |
| | The mupdf projects are broken on windows. will fix. | 16:17.55 |
| tor8 | Robin_Watts: argh! | 16:18.23 |
| | I think I may have fixed a const in fz_arc4 a while ago | 16:18.37 |
| | the prototypes didn't match the definition | 16:18.53 |
| Robin_Watts | const unsigned len | 16:19.48 |
| | fz_free_outline being undefined is my current problem. | 16:20.16 |
| tor8 | hm, did I forget fitz/doc_outline.c in the windows project? | 16:20.51 |
| | or maybe that's where I messed up the xml brackets | 16:21.11 |
| Robin_Watts | You did. | 16:21.17 |
| | Fixed here. | 16:21.28 |
| tor8 | ah yes, forgot the close tag | 16:21.46 |
| Robin_Watts | and xps_load_outline. | 16:21.51 |
| tor8 | that's odd. I have added xps_outline.c and the prototype in muxps.h both. | 16:22.25 |
| Robin_Watts | Hmm. git diff shows stuff missing. | 16:23.04 |
| | Let me fiddle for a bit. | 16:23.09 |
| kens2 | chrisl some hideous kludgy PostScript output from SAP coming your way. Fails with a typecheck on GS. Filas with -dDisableFAPI as well as FreeType, so I'm not sure what's up and haven't debugged the files yet. | 16:23.34 |
| | Work with Distiller though | 16:23.43 |
| chrisl | kens2: is this customer or free user? I could really do without being distracted right now....... | 16:24.15 |
| kens2 | Mostly | 16:24.15 |
| | I would ignore it for now | 16:25.06 |
| | Its a customer (I think!) but they reported it themselves | 16:25.18 |
| | Bug #692681 | 16:25.33 |
| | I'll poke it some more | 16:25.38 |
| chrisl | kens2: it appears to be Type 3 fonts that are at issue there | 16:28.49 |
| kens2 | Yes indeed | 16:33.46 |
| | Not sure why yet | 16:33.53 |
| chrisl | kens2: the Encoding array is all integers, not names | 16:50.50 |
| Robin_Watts | Tor8: OK. I've pushed everything up. | 16:53.06 |
| | How do I delete a local tracking branch? | 16:53.22 |
| | I've got rid of failing_allocs, but how do I get rid of origin/failing_allocs ? | 16:53.43 |
| kens2 | chrisl well that seems odd | 16:53.52 |
| tor8 | git fetch --prune | 16:53.55 |
| Robin_Watts | fab. | 16:54.12 |
| tor8 | to delete a branch on a remote repository | 16:54.13 |
| | git push origin :branch_to_delete | 16:54.22 |
| Robin_Watts | OK. I think that's everything. | 16:54.27 |
| tor8 | a bit arcane, but basically push "nothing" to the branch | 16:54.34 |
| chrisl | kens2: I find it hard to believe it ever worked, given such an invalid encoding. FWIW, if I convert the integers to names, the output *looks* okay | 16:55.16 |
| Robin_Watts | tor8: Yeah, I use something like that a log. | 16:55.24 |
| | I frequently have a 'tip' of commits locally that I don't want to push out. | 16:55.48 |
| | s/log/lot/ | 16:55.55 |
| kens2 | chrisl it works on Distiller | 16:56.13 |
| chrisl | kens2: it's still wrong - the PLRM is quite clear, Encoding array is an array of names | 16:58.01 |
| brutal_chaos | kens2: hello, I was told you were the person to talk to about using pdfwriter. | 16:58.17 |
| kens2 | chrisl OK so put that in the bug report :-) | 16:58.48 |
| | brutal_chaos : FOr some sins I don't remember, yes | 16:59.01 |
| brutal_chaos | ha | 17:00.05 |
| chrisl | kens2: I will. I will also look at what's changed - allowing it to work should be fairly straight forward, I think | 17:00.07 |
| brutal_chaos | kens2: so I am working on converting 10s of thousands of tiff images to pdf and shrinking them as much as possible. | 17:00.53 |
| kens2 | There is code for it in build_gs_font, but it only allows integers if the font tyep is 0 | 17:00.55 |
| | chrisl if I change that to allow integers for type 3 fonts it works. | 17:02.23 |
| brutal_chaos | kens2: GS\bin\gswin32c.exe -sDEVICE=pdfwrite -dCompLevel=1.4 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=%name%.pdf %1.pdf that's essentially what I am doing. Is there a way to keep the size around the same though sharpen the image? DCT seeems to just garble the image at that size. Using flate makes the image look okay, but increases the file size too much. | 17:02.42 |
| chrisl | kens2: Well, I suppose we could do that - does it produce reasonable output? | 17:03.32 |
| kens2 | brutal_chaos : You cna play with teh DCT parameters, but that's about your lot | 17:03.45 |
| | You are using lossy compression, it will 'fuzz' the output | 17:04.03 |
| | The only way to ge less fuzz s to get less compression | 17:04.11 |
| | chrisl I'm just trying that | 17:04.36 |
| | And the answer is no, it crashes later on | 17:04.57 |
| | Probably because I've messed with the font type | 17:05.14 |
| brutal_chaos | kens2: i figured as much. Is there a way to analiyze the image ahead of time and use the 'best' options for DCT? (I am trying to compete with a few thousand dollar 'enterprise' software.) | 17:06.22 |
| kens2 | brutal_chaos : If you know of a good way, then feel free to apply it ;-) | 17:06.55 |
| brutal_chaos | Alright. Thanks. | 17:07.11 |
| kens2 | The DCT options are pretty simple, more aggresive compression = lower quality, less aggresive compression = better quality | 17:07.29 |
| Robin_Watts | kens2: Do we always use DCT on images? | 17:07.31 |
| kens2 | You could also look at the downsampling to see if that can be increased/decreased without using JPEG | 17:08.02 |
| | Robin_Watts : its the default, but you can change it. | 17:08.11 |
| Robin_Watts | Do we support 'use the same type of compression as was on the original image' ? | 17:08.31 |
| kens2 | chrisl the file still fails, but now it fails in widthshow | 17:08.32 |
| | Robin_Watts : No, because we don't know what the original compression was | 17:08.44 |
| Robin_Watts | kens: So an enhancement then :) | 17:08.57 |
| kens2 | And can't legally apply some comrepssions anyway (eg JPEG2000) | 17:09.00 |
| Robin_Watts | Right, but we could usefully spot that we were coming from a PNG compressed image and use PNG out. | 17:09.30 |
| kens2 | Robin_Watts : the only real use is to detect incoming JPEG and either not apply more JPEG or try teh 'recompress with the same parameters' to avoid loss | 17:09.37 |
| | PNG is not a valid PDF input compression | 17:09.55 |
| | or output for that matter... | 17:10.09 |
| Robin_Watts | kens: PDF images with PNG predictors are a valid PDF input compression. | 17:10.13 |
| kens2 | PNG predictor, yes, but not PNG format | 17:10.23 |
| Robin_Watts | Yeah, I was being lax in the usage of my terminology. | 17:10.42 |
| chrisl | kens2: what's the error in widthshow - typecheck again? | 17:11.05 |
| kens2 | Yes I think so | 17:11.13 |
| | I've stopped looking ;-) | 17:11.21 |
| | I figure you can either tell them its an invalid font, or make it work at your leisure. Or both by telling them its invalid and changing it to an enhancement | 17:11.51 |
| chrisl | Yep, I'm just wondering how this ever worked. | 17:12.18 |
| kens2 | I have no idea, I don't remember this changing, but they are comparing with a very old version of Ghostscript | 17:12.39 |
| | (8.15) | 17:12.52 |
| | If it wasn't for the fact that Acrobat accepts it.... | 17:13.12 |
| chrisl | kens2: I will add code to be more liberal for Type 3 fonts, but I would like to know for sure why it stopped working | 17:15.19 |
| kens2 | chrisl they say its OK in 8.15 and not in 8.71 that'a a big gap to look into and the 'working' version is ancient. | 17:17.05 |
| chrisl | Yeh, I'm not going to spend too much time on it! | 17:18.03 |
| kens2 | TIme for me to go, goodnight all | 17:33.35 |
| henrys | off to the coffee shop for a change of venue | 17:57.00 |
| mvrhel | Robin_Watts: were you going to commit the planar stuff soon? | 18:05.21 |
| Robin_Watts | Just looking at the bmpcmp for it now. | 18:05.40 |
| | Why ? | 18:05.42 |
| mvrhel | oh. I had a fix I was going to commit for the bug that I found. I made the mistake of fixing it while your patch was still applied. Trying to figure out how best to untangle it (that is to create the least amount of work) | 18:07.03 |
| | I think if I commit it to my branch then pull that one into my master I should be ok | 18:07.34 |
| Robin_Watts | Gimme 10 minutes or so. | 18:08.04 |
| mvrhel | oh. if you are that close I will wait | 18:08.15 |
| Robin_Watts | OK. committed. | 18:12.52 |
| | So you have a fix on the branch that isn't on the master? | 18:13.13 |
| | Can you just git cherry-pick it onto master ? | 18:13.29 |
| | "git cherry-pick <hash>" takes commit <hash> from whatever branch it's on, and applies it onto the current branch as the tip. | 18:14.42 |
| mvrhel | Robin_Watts: yes that is what I was going to do | 18:14.57 |
| Robin_Watts | tor8: I have locally merged master into context | 18:21.56 |
| tor8 | with the xps_outline and ios files too? | 18:33.20 |
| | Robin_Watts: grammar nit, too many apostrophes in 5c4ff53fb89b5068bc901fd5909be9e5d2d0cb0b commit message | 18:36.20 |
| | it's its | 18:36.48 |
| mvrhel | Robin_Watts: so where are we now then in the planar/color halftone work? | 18:40.20 |
| | what is left to do? | 18:40.26 |
| | I am going to poke at my screen generation stuff that ray_laptop had pointed me to, and start ripping out wts from the code | 18:41.44 |
| | unless there is something pressing for me to do with the planar stuff | 18:42.00 |
| | Robin_Watts: are we ready to do some more performance testing? | 18:42.29 |
| ray_laptop | mv sounds good. BTW, I am digging into 692618 and finding some strange stuff going on. With clist mode the colors out of the transparency are different, but only slightly. | 18:53.52 |
| | mvrhel: but at least I understand why we aren't getting the 'non-encodeable' colors. The colors _are_ being encoded, but the compressed color list is missing the sub-level when we decode | 18:54.56 |
| | when we devn_unpack_row, that is | 18:55.18 |
| mvrhel | oh that is interesting | 18:55.22 |
| ray_laptop | but I also found a hiccup in the compressed encoding (I am pretty sure). If you look at gdevdevn.c line 1305 Dan scanned to find the largest group | 18:57.05 |
| | but he didn't ignore the value 0 which is taken care of by the 'colorants' bitmap | 18:57.37 |
| mvrhel | oh | 18:57.45 |
| ray_laptop | so we weren't taking advantage of a solid_not_100 color if there were more 0 value colorants than the non-zero, non-solid colorants | 18:58.55 |
| mvrhel | that can occur readily for this file | 18:59.54 |
| ray_laptop | yes, particularly since the transparency is coming up with a lot of value 1 and 2 (near zero) for the components | 19:00.32 |
| tor8 | Robin_Watts: more ominously, the clip path bug fix make the dragon age pdf crash | 19:01.42 |
| | fz_bound_pixmap called with null pixmap | 19:01.47 |
| mvrhel | ray_laptop: so I am not seeing the code in the toolbin/hafltone folder | 19:06.07 |
| | oh never mind | 19:06.59 |
| | windows was confused | 19:07.02 |
| | you did not add in the gen pat code yet though? | 19:07.23 |
| Robin_Watts | tor8: D'Oh. Yes. | 19:10.38 |
| | mvrhel: I think we should be all there in terms of functionality. | 19:10.56 |
| mvrhel | great | 19:11.10 |
| Robin_Watts | Probably time to ask marcosw to do performance figures again. | 19:11.20 |
| mvrhel | yes | 19:11.27 |
| Robin_Watts | actually, I think he can do performance and comparisons at the same time. | 19:11.34 |
| tor8 | Robin_Watts: also, the regular build -- I don't understand why the linker doesn't complain about duplicate definitions of fz_scale_pixmap | 19:11.36 |
| Robin_Watts | tor8: Because I only include 1 of the two .c files ? | 19:11.54 |
| tor8 | the makefile builds both draw_scale.c and draw_simple_scale.c | 19:12.04 |
| Robin_Watts | It shouldn't. | 19:12.13 |
| tor8 | by virtue of $(wildcard draw/*.c) | 19:12.25 |
| | the normal makefile, not the android makefile, not the windows project file | 19:12.42 |
| Robin_Watts | oh. Well, I was using the MSVC project and the android one :) | 19:12.47 |
| | ok, we need to fix that :) | 19:12.55 |
| | #ifdef SIMPLE_SCALE and #ifndef SIMPLE_SCALE ? | 19:13.11 |
| tor8 | anyway, if you're happy with draw_simple_scale.c we should replace draw_scale.c | 19:13.19 |
| Robin_Watts | draw_scale.c allows better filters. | 19:13.38 |
| tor8 | the difference is that the simple scaler only does a subset of possible filters | 19:13.40 |
| Robin_Watts | yes. | 19:13.54 |
| tor8 | how much performance did you get out of the simple one compared with the regular? | 19:14.21 |
| Robin_Watts | No difference, but it takes a 1/4 of the memory. | 19:14.48 |
| tor8 | how much memory is that? a scanline worth or a full image worth? | 19:15.27 |
| Robin_Watts | ooh... book.pdf. Do you get a warning when pdfdrawing page 3? | 19:15.44 |
| tor8 | meaning, does it scale with image width or image size | 19:15.46 |
| Robin_Watts | a whole image. | 19:15.47 |
| | image size. | 19:15.52 |
| tor8 | right, so a substantial memory savings | 19:15.59 |
| Robin_Watts | Well... actually... | 19:16.14 |
| | it's the size of the temporary buffer, which is several scaled scanlines. | 19:16.47 |
| | so probably actually nearer the former. | 19:16.56 |
| | so not cripplingly important (unless you're scaling up!) | 19:17.14 |
| tor8 | we're not scaling up :) | 19:17.21 |
| Robin_Watts | I know. | 19:17.27 |
| tor8 | and hopefully we won't on devices where memory matters | 19:17.39 |
| | ouch. I get malloc errors on page 3 of book.pdf | 19:17.56 |
| | mupdf(41214) malloc: *** error for object 0x900ce3: pointer being freed was not allocated | 19:18.02 |
| Robin_Watts | I'm getting a 'bit length overflow' error. | 19:18.04 |
| | Let me try a memento build. | 19:18.31 |
| tor8 | that could be mupdf just crashing in general due to my outline changes | 19:19.01 |
| | hmf. I thought I'd fixed that error before. | 19:19.45 |
| | yeah... bad fix | 19:21.46 |
| | I don't see the bit length overflow error | 19:21.56 |
| Robin_Watts | Crumbs. | 19:26.02 |
| | It's from zlib while WRITING the final png. | 19:26.11 |
| | so nothing for us to worry about. | 19:26.48 |
| | I just tried: | 19:27.47 |
| | $ win32/Memento/xpsdraw.exe -o out.png ../ghostpcl/tests_private/xps/xpsfts-a4/fts_01xx.xps 1 && start out.png | 19:28.01 |
| | | cannot read zip part '/Documents/1/_rels/FixedDocument.fdoc.rels' | 19:28.03 |
| | \ cannot process FixedDocument rels part | 19:28.05 |
| | Is that normal? | 19:28.09 |
| | tor8: Don't know if you saw my burblings about xps ? | 19:32.56 |
| | It's looking for: /Documents/1/_rels/FixedDocument.fdoc.rels | 19:33.33 |
| tor8 | Robin_Watts: yeah. it's looking for (and not finding) the outline. | 19:34.11 |
| Robin_Watts | OK, so it shouldn't be spewing that as (what looks like) an error to the user then? | 19:34.40 |
| tor8 | I should add a function like xps_has_part() to check for a parts existence without having to catch an error | 19:34.48 |
| | yeah. | 19:34.55 |
| Robin_Watts | Well, catching an error sounds reasonable to me. | 19:35.02 |
| | It looks like my merged version works. | 19:35.11 |
| | Should I push it? | 19:35.14 |
| | (master merged to context, so only the context branch will be affected when I push) | 19:35.35 |
| tor8 | sure | 19:35.49 |
| Robin_Watts | Done. | 19:36.22 |
| | This means you should be able to build an iOS version with memory checking :) | 19:36.34 |
| tor8 | yeah. I'll want to finish my search project and get that thing on the app store before switching to the context branch though | 19:37.37 |
| Robin_Watts | yes of course. | 19:37.46 |
| tor8 | there's also the question of what to do with sumatrapdf:s patch list | 19:38.00 |
| | I haven't been keeping on top of the bugs since last meeting, so I'm sure they have a lot of bug fixes we don't have yet | 19:38.18 |
| | I'd like to make a list of the fixes they have which we haven't integrated, and work those into the context branch when switching over | 19:38.53 |
| | also: #define pdf_try(xref) fz_try(xref->ctx) yay or nay? | 19:39.34 |
| Robin_Watts | ew. | 19:39.50 |
| | I tend to do fz_context *ctx = xref->ctx at the top of most functions anyway. | 19:40.07 |
| tor8 | right. | 19:40.15 |
| Robin_Watts | (at least if it's used more than 3 times). | 19:40.16 |
| | saves repeated derefs. | 19:40.21 |
| tor8 | yeah | 19:40.31 |
| Robin_Watts | Cos then you'll get people mixing pdf_try and fz_catch etc. | 19:40.42 |
| | tor8: Want me to run through zenikos bugs? | 19:42.42 |
| tor8 | Robin_Watts: zeniko usually keeps a diff here http://software.zeniko.ch/sumatrapdf/SumatraMuPDF.patch | 19:43.59 |
| | many of those patches are patches we don't want | 19:44.06 |
| | like the gdi+ device (c++) and their windows specific system font searching | 19:44.48 |
| Robin_Watts | yeah. | 19:45.10 |
| | I'll run through all his bugs tomorrow, and take a look at that patch. | 19:45.29 |
| tor8 | and most of the patches need sanity checking | 19:45.34 |
| Robin_Watts | of course - I wasn't going to blindly accept them. | 19:45.50 |
| tor8 | but if you could go through them and integrate the easy ones and make a list of the not-so-easy ones I'd appreciate it (as would zeniko no doubt) | 19:46.27 |
| | ah, they've added locks to protect freetype in a multi-threaded environment | 19:47.28 |
| | fz_synchronize_begin/end | 19:48.03 |
| | which may be worth keeping | 19:48.10 |
| | or, well, adapting to whatever platforms we run on | 19:48.20 |
| Robin_Watts | I'd like to look at generalising fz_store to be a cache. | 19:48.46 |
| | which will require a lock of some description. | 19:48.58 |
| tor8 | yes, that would be a worthwhile project to take on as well | 19:49.21 |
| | I realized we can get rid of the init/free of that without the contortions we do now | 19:49.45 |
| Robin_Watts | My experience of doing memory scavenging on demand suggests that having a single low level lock works well. | 19:49.49 |
| tor8 | ever since I added function pointers for drop to remove the hard coded set of resources you can store, that contortion isn't required | 19:50.05 |
| | so we can create and free the store directly in the pdf_xref init and free function | 19:50.19 |
| Robin_Watts | arguably it should be in fz_context | 19:50.45 |
| | because if we have several pdf documents open in a single fz_context we want to share the cache between them. | 19:51.12 |
| tor8 | Robin_Watts: won't really be possible or useful | 19:51.34 |
| | the resources are indexed by object number | 19:51.44 |
| Robin_Watts | That can be "fixed" if we need to. | 19:52.22 |
| tor8 | if you want to add a pixmap cache for caching scaled and color converted pixmaps, I'd advocate a separate cache. the pdf_store is designed to cache the fonts primarily, and those are highly pdf document specific | 19:52.52 |
| Robin_Watts | (use of quotes intended to indicate that it's not clear to me whether that's a good thing or not) | 19:53.03 |
| tor8 | muxps has a similar cache for its resources | 19:53.32 |
| Robin_Watts | I've written stuff that scavenges memory from multiple caches before. | 19:53.48 |
| tor8 | the xps_font_cache font_table | 19:53.52 |
| Robin_Watts | It would be MUCH easier/nicer/simpler/etc to have a single cache. | 19:54.10 |
| | But all this can be thought about. | 19:55.07 |
| tor8 | Robin_Watts: if you want to take that on, I won't object :) | 19:55.09 |
| | a single cache does reduce the number of different structures we have. the "problem" is the lookup keys. | 19:55.46 |
| | for xps it's a part name, for pdf it's usually an object number. I guess we could decide to punt and never cache objects which have no object number. | 19:56.19 |
| | functions, fonts and big images always do, it's colorspaces that don't need an object number | 19:56.51 |
| | fz_glyph_cache, fz_resource_cache (previously pdf_store) and an eventual fz_render_cache for pixmaps? | 19:57.56 |
| | or a common cache struct for everything? | 19:58.37 |
| ray_laptop | tor8: I thought all except the 'standard' color spaces have object numbers (in pdf) | 20:10.02 |
| tor8 | ray_laptop: you can have 'inline' colorspaces, I've seen it for Indexed and Separation/DeviceN base colorspaces | 20:11.39 |
| | you probably shouldn't and it's probably not common, but with PDF you never know how it'll be abused | 20:11.57 |
| | Forward 1 day (to 2011/11/15)>>> | |
IRC Logs