| | <<<Back 1 day (to 2012/08/30) | 2012/08/31 |
| docuport | hi. ny1 from MuPDF team? | 00:19.10 |
| | Anyone here from Artifex's MuPDF team? | 00:32.36 |
| kens | Oh good grief..... | 09:42.57 |
| | Robin_Watts : would you like to know what heinous structural error was causing Acrobat to throw up its hands in horror ? | 09:43.22 |
| sebras | kens: do tell! | 09:49.40 |
| kens | You'll lik ehits... | 09:49.48 |
| | After the trailer dict I had '%EOF' instead of '%%EOF' | 09:50.08 |
| | THat should be "%%EOF" | 09:50.22 |
| | Damn miranda chat | 09:50.31 |
| | %%%%EOF | 09:50.35 |
| | Two percents not one | 09:50.44 |
| | Acrobat 9 and X insist that it should be %%%%EOF, earlier versions appear to be happy with %%EOF | 09:51.18 |
| Robin_Watts | Ah. | 09:51.44 |
| kens | Of course Acrobat still refuses to acknowledge that my file is linearised. | 09:51.56 |
| tor8 | Robin_Watts: kens: how about adding a linearisation hint table parser/pretty printer to pdfshow? | 10:08.46 |
| kens | Sounds good to me | 10:09.03 |
| tor8 | *touches nose* | 10:09.12 |
| Robin_Watts | tor8: Nice idea - if only Acrobat actually ever looked at the hint table. | 10:09.13 |
| kens | I have half of one at the moment, written to do my hint dumping | 10:09.14 |
| | Robin_Watts : still worth us decoding it | 10:09.31 |
| tor8 | Robin_Watts: they don't? | 10:09.35 |
| kens | tor8 nope | 10:09.40 |
| Robin_Watts | Yes, but it won't help ken get past his current problem. | 10:09.45 |
| tor8 | *sigh* | 10:09.48 |
| kens | Proved it by trashing the hint table | 10:09.48 |
| | Acrobat still say 'optimised' | 10:10.01 |
| | Robin_Watts : just keeping plodding on | 10:10.25 |
| Robin_Watts | is bitten by the oldest macro gotcha in the book. | 10:16.49 |
| | It's gonna be one of those days... | 10:17.03 |
| paulgardiner | That's strange. I thought I used up all the stupid mistakes yesterday. | 10:31.35 |
| kens | No, I only fixed my one today | 10:31.48 |
| | Must also have at least one left | 10:31.59 |
| paulgardiner | Robin_Watts: is there a way I can alter the commit against which mujstest compares HEAD? | 10:52.19 |
| Robin_Watts | paulgardiner: Not really. | 10:52.45 |
| | But you can be sneaky. | 10:52.49 |
| | clusterpush the commit you want to test against. | 10:53.04 |
| | Then clusterpush HEAD. | 10:53.07 |
| paulgardiner | to get difference from last | 10:53.33 |
| Robin_Watts | Then in that second report you will see first the comparison between HEAD and forms, and then second the comparison between HEAD and the difference from the last. | 10:53.39 |
| | which should be what you want, yes. | 10:53.44 |
| paulgardiner | Can't get bmpcmps though, I guess. | 10:54.00 |
| Robin_Watts | indeed. | 10:56.15 |
| | If you have specific files you want to test, you can run bmpcmp on your local machine. | 10:57.06 |
| tor8 | paulgardiner: Robin_Watts: I went through the diffs to non-forms code on the forms branch and all looks good to me so if you want we can merge forms to master and work on a single track from now. the makefile makes it easy enough to ignore the forms if you don't want it. haven't looked at the win32 project though, did you add a separate v8-target there too? | 11:16.33 |
| Robin_Watts | tor8: Yes, separate targets. | 11:16.55 |
| paulgardiner | tor8: Great. I'm pleased you didn't find anything objectional. | 11:18.59 |
| tor8 | paulgardiner: I still haven't looked at the forms bits ;) | 11:19.35 |
| paulgardiner | Ah right. | 11:19.52 |
| | That explains it. | 11:20.09 |
| tor8 | but I have checked everything else and I'm happy enough to merge it all with master and work from there | 11:20.13 |
| paulgardiner | :-) | 11:20.13 |
| | How about the odd bits of forms code that the non-forms code would then call? | 11:20.57 |
| | I can think of only one case at the moment: when enumerating annotations, we synthesize any missing ones. | 11:22.03 |
| | Might be others. | 11:22.13 |
| tor8 | paulgardiner: I take it the pdf_field_camelCaseFunctions are used by the JS bindings? | 11:28.51 |
| Robin_Watts | http://www.smallwondertoys.com/ - I WANT ONE | 11:29.23 |
| paulgardiner | tor8: not entirely. Some of those are from early on before I realised they didn't fit with the general style elsewhere. I imagined we might want do some renaming. | 11:31.09 |
| Robin_Watts | (For those wondering about the link I just posted, nudge the velocipede gently from either side by your mouse pointer) | 11:33.29 |
| sebras | tor8: I take that as a no to implement the pretty printer..? | 11:52.43 |
| tor8 | sebras: huh? you mean hint streams? | 11:53.10 |
| kens | I can tackle dumping the hint streams, but not yet :-) | 12:02.56 |
| sebras | tor8: yes. | 12:29.13 |
| Robin_Watts | tor8, paulgardiner: Just looking at paulgardiners latest commits now. | 14:58.42 |
| | So, should we do a commit that changes all the pdf_blah_fooBarBaz to pdf_blah_foo_bar_baz before we merge down to trunk ? | 14:59.19 |
| paulgardiner | We may want to permute the fields too: I have pdf_field_set_text where more in style might be pdf_set_field_text | 15:00.55 |
| Robin_Watts | paulgardiner: This sounds like a job for a sed file. | 15:01.15 |
| | lookat scripts/rename.sed | 15:01.29 |
| | We should construct such a file, agreed it between us, then run it. | 15:02.17 |
| paulgardiner | I'm happy to do the editing, but not sure I trust myself to choose the right names. | 15:02.23 |
| Robin_Watts | Part of the point of using a sed script is that we can agree names in advance to avoid having to repeatedly iterate. | 15:02.58 |
| | http://git.ghostscript.com/?p=user/paulg/mupdf.git;a=commitdiff;h=0dfdec8b758c7b51880c36d0c4cdad5a6583fad4 | 15:04.21 |
| paulgardiner | I did something similar on one of my own projects recently. Think I used ed | 15:04.28 |
| Robin_Watts | paulgardiner: ^ | 15:04.33 |
| | very last chunk... | 15:04.39 |
| | Why is that an Array? | 15:05.17 |
| | display.blah means that display is an Object, right? | 15:05.46 |
| | If it was an array, I'd expect to see usage like display[0] etc. | 15:06.04 |
| paulgardiner | I think it's all the same in javascript - associative arrays/objects | 15:06.16 |
| Robin_Watts | I thought that Arrays were special cases of Objects. | 15:06.38 |
| | So you could do blah[1] etc on an Array, but not on an Object ? | 15:07.01 |
| paulgardiner | Actually, I really don't know why that isn't new Objects() | 15:07.32 |
| Robin_Watts | Or can you do blah[s] to mean blah.s ? That rings a bell. | 15:07.38 |
| | yeah, I was expecting new Object there. | 15:07.48 |
| paulgardiner | Yes blah[s] is blah.s | 15:07.54 |
| Robin_Watts | but border is set up the same... | 15:08.03 |
| paulgardiner | I'll try making new Object sometime. Certainly would make more sense. I think I copied it from somewhere, but it may have been from some of my own code, written when I knew even less about javascript. :-) | 15:09.34 |
| Robin_Watts | Most of my Javascript knowledge is actually Actionscript knowledge, so it's not to be trusted :( | 15:10.28 |
| paulgardiner | I think making them arrays is harmless, but it'll be worth trying Object. No point in altering the current commit as there are other uses | 15:11.13 |
| Robin_Watts | Is there a good reason why update_text_field_value doesn't handle the marking of the field as dirty? | 15:11.34 |
| | At the moment you seem to call update_text_field_dirty, then pdf_field_mark_dirty. | 15:11.54 |
| paulgardiner | I'll have a look | 15:14.39 |
| Robin_Watts | And if it *is* possible to have update_text_field_dirty do the pdf_field_mark_dirty, then is it possible to make it smart enough to only set it dirty if it's really changed? | 15:16.45 |
| paulgardiner | I could make update call mark. I don't have a wild preference for either way | 15:16.46 |
| Robin_Watts | paulgardiner: Surely it's better to have update call mark? Are we ever going to want to do an update and NOT call mark? | 15:17.16 |
| paulgardiner | Yeah, probably better. I just have a niggling feeling there was a reason, but I cannot think of it now. I think you are right: the only cases where we might not want to mark are ones better determined from within update | 15:21.55 |
| Robin_Watts | The only reason I can think of off the top of my head, is that we might want to change lots of things, and then do the dirty marking just once. | 15:22.32 |
| | (if the dirty marking takes lots of time etc) | 15:22.45 |
| | but I don't see how that can apply here. | 15:22.51 |
| paulgardiner | No dirty marking is quick, and is there so that we can do many changes and regenerate the apearance stream only once | 15:23.15 |
| Robin_Watts | Back on naming, I think the convention in mupdf is pdf_set_text_color, rather than pdf_text_color_set | 15:26.12 |
| paulgardiner | Yeah. That's why I mentioned that we might need to reorder as well as change case | 15:26.50 |
| | I can go through monday and make a list of suggested changes | 15:27.17 |
| Robin_Watts | The stuff I'm seeing in these patches is set_text_color. | 15:27.20 |
| | oh, pdf_field_reset, right... | 15:27.35 |
| | but we have pdf_dict_get etc, so we're not entirely consistent. | 15:28.23 |
| paulgardiner | I've been torn between sentence order and pdf_<module>_<method> | 15:28.28 |
| | Oh yeah pdf_dict_get | 15:29.03 |
| Robin_Watts | Personally, I prefer the latter, but tor8 considers that too OO for his taste I think. | 15:29.07 |
| paulgardiner | Anything else for the commits? I can make update call mark quickly enough | 15:30.40 |
| Robin_Watts | Still got a couple to go. | 15:31.10 |
| | Does the thing returned by pdf_jsimp_toString need freeing ? | 15:33.19 |
| paulgardiner | No | 15:33.30 |
| Robin_Watts | ok. | 15:33.33 |
| | You can simplify reset_field very slightly by pulling the name=utf8_to_pdf out of the try, but that's probably not important. | 15:34.25 |
| | no need to set name to NULL or fz_var it. | 15:34.57 |
| paulgardiner | Yeah, I do that here and there. | 15:35.14 |
| | I always feel I'm using insider knowledge when I do that, but as you say it's completely safe | 15:38.16 |
| Robin_Watts | in find_field, return field might be nicer than break and then voodoo on the return statement. | 15:38.34 |
| | And !strncmp(part, name len) && part[len] == 0 would be more efficient. | 15:40.41 |
| | but harder to read. | 15:41.44 |
| | OK, they all look great. | 15:43.09 |
| paulgardiner | I think we've thought through that one before. Didn't we decide that strncmp doesn't work? | 15:43.18 |
| | I'll do that return though. I usually do that vood on the return to avoid using break, but seeing as I have the break anyway. | 15:43.51 |
| Robin_Watts | You strncmp to test that the first len chars of both strings agree. | 15:45.11 |
| | If that matches, the only case where it can not be a real match is if the uncounted string is longer. | 15:45.48 |
| | and that's what part[len] == 0 tests for. | 15:45.55 |
| paulgardiner | yes seems fine at the moment, but do you remember when we talked about this before? Maybe it was a different function. | 15:46.21 |
| Robin_Watts | It rings a bell, but if it was more than 20 minutes ago you can't expect me to remember with any accuracy | 15:47.00 |
| paulgardiner | and part[len] is safe to test because part is at least that long otherwise strncmp would fail, given that name has no 0's within the first len chars. | 15:52.32 |
| Robin_Watts | yes. | 15:52.43 |
| paulgardiner | Sounds right. I'll do the other two changes for now, and think about that some more. I'm sure we saw a problem before. Maybe it was a slightly different trick we discussed | 15:53.52 |
| Robin_Watts | I could imagine that the other 2 changes might be a pain to apply retrospectively? | 15:55.17 |
| | might just be easier as a tweak? | 15:55.39 |
| | I mean a separate commit at the end. | 15:55.45 |
| paulgardiner | Yeah, I was going to git hack | 15:55.51 |
| Robin_Watts | whatever is easier for you. | 15:56.24 |
| paulgardiner | Robin_Watts: ok. Updated. | 16:10.13 |
| henrys | Robin_Watts:well I'm finally going to experience skeet, my son has been doing it and he's going to take me. I am concerned I won't hit one. It just seems unlikely that anyone would hit one, but folks manage. | 16:21.51 |
| Robin_Watts | henrys: You have to remember that shotguns were invented by Edwardians. | 16:22.19 |
| | Edwardians were chinless, inbred morons. | 16:22.31 |
| | If they could do it, anyone can. | 16:22.37 |
| henrys | reassuring | 16:22.56 |
| Robin_Watts | Having said that proper skeet is harder than Clay Pigeon shooting. | 16:22.57 |
| | skeet are smaller than normal clays, and are fired faster. | 16:23.19 |
| | I'm sure you'll be fine. I'm famously bad at any form of sport and I can hit a few. | 16:33.45 |
| henrys | A lot of inbred idiots in the states can shoot wings off flys so I don't know about your theory. | 16:49.13 |
| Robin_Watts | When are you going? | 16:51.32 |
| henrys | Tuesday, I'll let you know what happens | 16:52.07 |
| Robin_Watts | Most important thing is to make sure that you have the gun seated in your shoulder properly. | 16:52.34 |
| | If it's sat right, then when it kicks, it doesn't hurt. If you leave a gap between the butt and your shoulder when you pull the trigger, it'll kick back, and that will hurt. | 16:53.19 |
| henrys | thanks, actually I've fired all sort of weapons but never a shotgun | 16:54.07 |
| | it will have more kick than I'm used to. | 16:54.36 |
| kens | Night all | 17:04.53 |
| henrys | for the logs - Monday is a US holiday | 17:40.07 |
| Robin_Watts | have fun. | 17:40.25 |
| sebras | kanru_: you do know that mupdf 1.1 has been released, right? you might want to update the package for debian. ;) | 23:42.47 |
| | Forward 1 day (to 2012/09/01)>>> | |
IRC Logs