| | <<<Back 1 day (to 2013/08/06) | 2013/08/07 |
| raven | Yet who can tell me how to clear the cache mupdf on android? | 00:36.13 |
| robin_watts_fone | interesting story about xerox printers getting numbers wrong cos of jbig2 on BBC news website. can't paste url. | 04:37.41 |
| | raven: mupdf should not leak, but it will gradually fill the cache up to the predefined limit. | 04:46.11 |
| | the limit is given in the fz_new_context call. | 04:46.54 |
| | there may also be a call to empty the store somewhere, but we don't call that on android. | 04:47.45 |
| paulgardiner | tor7: ping | 11:23.58 |
| tor7 | paulgardiner: yes? | 11:35.08 |
| paulgardiner | As far as I can see, signing has to be done in two stages. | 11:37.52 |
| | You can create the appearance stream and the initial form-field value, but some parts of the value can't be calculated until saving. | 11:39.38 |
| | There's a contents field which takes the signature itself. That's calculated by hashing everything but the contents field, so you need to have serialized everything to disc before you can perform the hashing | 11:41.24 |
| | Also there's a byte-range fields which records what parts of the document make up "everything but the contents" | 11:42.12 |
| | Both stages require access to the signing certificate, the latter also requiring the private key. I could leave it up to the app to ensure that these are passed in at both stages, but there are two undesirable implications. | 11:43.47 |
| tor7 | does the hashing work on the objects or on the actual bytes on disk? | 11:44.27 |
| | oh right, the bytes, based on the byte-range fields | 11:44.47 |
| paulgardiner | I'd have to add extra parameters to the saving routines, and the use of multiple signatures would be problematic (i.e., making sure the correct cert was used for each signature | 11:45.05 |
| | tor7: on the bytes | 11:45.16 |
| | There is an object based technique too, but they are moving away from using it because it is very error prone | 11:45.53 |
| tor7 | would it be easy to save the document while filling the hash with fluff bytes, and then seek and write back the right hash in the correct place in the file afterwards? | 11:46.01 |
| paulgardiner | tor7: Yeah, that was my plan | 11:46.16 |
| | But both stages need access to the cert file | 11:46.40 |
| | I was wondering about temporarily adding a reference to the cert file path in the form object so we'd know to use it at saving time | 11:47.42 |
| tor7 | okay. | 11:47.42 |
| paulgardiner | But that's a bit yukky... not that similar hasn't been done elsewhere. | 11:48.16 |
| tor7 | is the cert file path and signature a "global" object in the pdf, that's just referenced by the signature annotation? | 11:48.21 |
| | or can you have multiple signature annotations with separate certs? | 11:48.43 |
| paulgardiner | The path wouldn't usually be referenced at all | 11:48.45 |
| | tor7: a document can certainly have multiple with separate certs because several people may sign. Whether such should be supported within a single editing session is another question | 11:50.14 |
| | Hmmm. Maybe I could allow only one per session, and then store it in the doc struct | 11:50.51 |
| tor7 | I don't see why it should be impossible, if we split the saving and signing into two passes | 11:50.52 |
| | but how it would work, would one hash be a part of the signed contents of the other? | 11:51.23 |
| paulgardiner | Not the possibility of it that was worrying me, just how most neatly to do it | 11:51.24 |
| tor7 | and which order | 11:51.26 |
| paulgardiner | Sorry, didn't understand that last question | 11:51.56 |
| tor7 | consider a file with two signatures: A and B | 11:52.27 |
| | would signing B use a hash that contains signature A's hash bytes? | 11:52.43 |
| paulgardiner | Each signature of a set added in a single session would hash all but their own "Contents" field | 11:53.48 |
| tor7 | so to sign A you need B's hash, and B's hash needs A's hash. circular dependency. I.E. can't be done. | 11:54.24 |
| paulgardiner | Oh I see. Hmmm | 11:54.36 |
| tor7 | so just one signature at a time then, makes it easier :) | 11:54.46 |
| paulgardiner | Yeah, I think so. :-) | 11:54.55 |
| tor7 | in that scenario, A would sign a previous "increment" of the file, and B would sign the old file + new stuff | 11:55.46 |
| | that's the only way I see it could work | 11:55.58 |
| paulgardiner | Yeah. | 11:55.59 |
| tor7 | where the new stuff could be just the data for one more signature | 11:56.26 |
| paulgardiner | the byte ranges can be anything we like, so potentially one could solve the multiple signature in one step by having each hash miss out all the Contents fields | 11:57.09 |
| tor7 | yeah, but getting the UI for that right would be madness :) | 11:57.25 |
| | what was your original question again? | 11:57.27 |
| paulgardiner | ... actually perhaps the fact that byte range is an arbitrary number of ranges, rather than just two, is to support that. | 11:57.43 |
| tor7 | well, you need the range before the hash, and the range after it, at least | 11:58.09 |
| | but yes, it may well be | 11:58.30 |
| paulgardiner | In any case it would simplify things if we avoided multiple signings between saves for now. | 11:59.59 |
| | But then how to do deal with that in the UI? | 12:00.11 |
| | Force a save on each signing? | 12:00.18 |
| | Disallow second signing until doc saved? | 12:00.38 |
| | Proably the latter for now. | 12:01.03 |
| | That's moved away from the original problem which was ensuring that the same cert is used in the post-save hashing as in the field signing stage. | 12:02.56 |
| tor7 | we could stow away the byte ranges and certs that need signing in a list in the pdf_document | 12:03.01 |
| | and then after saving, work through the list | 12:03.09 |
| paulgardiner | tor7: oh. That sounds nice, and then add in the cert reference there too if needs be | 12:03.30 |
| tor7 | and record which pdf_obj's and numbers need to be updated with the field ranges | 12:03.59 |
| paulgardiner | Well, we can't stow away the byte range because we don't know it until later | 12:04.02 |
| tor7 | or something like that | 12:04.05 |
| paulgardiner | Yeah the obj exactly | 12:04.17 |
| | Okay. That sounds good. | 12:04.24 |
| tor7 | I think that's better than saving it in the pdf_obj's directly | 12:04.35 |
| paulgardiner | Yes. definitely. | 12:04.44 |
| tor7 | and it does let us tackle the case where we sign multiple times in one session, should we desire it | 12:04.57 |
| paulgardiner | Yes. Perfect. | 12:05.08 |
| | Thanks. I'll go with that. | 12:05.17 |
| tor7 | and since it's used when saving, it feels like it should be more robust there than in the pdf_annot | 12:05.25 |
| paulgardiner | Yeah. You can't trust page and annot objects to stick around | 12:06.06 |
| tor7 | henrys: there are 14 gxps segfault bugs. should we put a bounty on each of them, or do you want to deal with them as a group? | 12:06.29 |
| | henrys: I've tested the same files on muxps in valgrind and there are no errors there so it *should* be fairly easy to backport the bug fixes from muxps into gxps, unless there are errors that trigger in the gs graphics library | 12:07.16 |
| paulgardiner | tor7: reping | 12:11.49 |
| tor7 | paulgardiner: still here | 12:11.59 |
| paulgardiner | When a user attempts to sign, they will need to specify the certificate (probably initially by selecting a file), and a password. I'd like to store those in this new list we just discussed so that the same info doesn't have to be requested at saving time | 12:14.01 |
| | But then I'd be storing a password in memory. What do you reckon? | 12:14.25 |
| tor7 | when do you need to use the password? | 12:14.55 |
| paulgardiner | I believe at both stages. | 12:15.12 |
| tor7 | I'd read and store the certificate in memory rather than the file path, if possible. | 12:15.23 |
| paulgardiner | Yeah, was thinking that | 12:15.34 |
| | But was worried about the password | 12:15.49 |
| tor7 | is the password used to decode the private key? | 12:15.53 |
| paulgardiner | yep | 12:16.01 |
| tor7 | I don't think storing the private key in memory is any worse than the password. both are not very good. | 12:16.21 |
| paulgardiner | In fact the certificate too it seems (for the files I get from Adobe Reader) | 12:16.21 |
| tor7 | I'm no security expert, so don't take my opinion seriously though | 12:16.43 |
| | but yes, I'd worry about keeping sensitive information in RAM for a long time | 12:16.59 |
| paulgardiner | Really, I'm just asking do you think we can get away with it for now? | 12:17.15 |
| tor7 | I think we can. software has to be trusted at some point. we should make a point of overwriting the password and private key buffers with garbage when we're done with them though. | 12:17.50 |
| paulgardiner | Okay good. | 12:18.04 |
| tor7 | so we don't get the same memory back uninitialized from malloc at a later stage | 12:18.10 |
| paulgardiner | tor7: Could you check over the commits on paul/master when you have a moment? | 13:01.12 |
| tor7 | paulgardiner: fontheight -> lineheight perhaps? | 13:04.33 |
| paulgardiner | Yeah better. Okay | 13:05.02 |
| tor7 | I'd also try it with 1.2 * (ascent - descent). I suspect the line spacing is very tight as written. | 13:06.01 |
| | you set y_orig = bbox_top + fontheight, shouldn't that be bbox_top + ascent? | 13:07.32 |
| | paulgardiner: the first 4 look good, up to the ascender/descender patch | 13:08.05 |
| paulgardiner | Could I try 1.2 as a follow on later because then for multiple lines I think I should be using 1 .2 1 .2 1 | 13:08.32 |
| tor7 | paulgardiner: I don't follow you there | 13:09.20 |
| | robin_watts_mac: hiya! | 13:09.25 |
| paulgardiner | tor7: It complicates the calculation of how many lines will fit in a certain height because you have n lines and n-1 gaps. | 13:10.15 |
| | tor7: Not rocket science but would take a while to work through all the places that matters | 13:11.15 |
| tor7 | paulgardiner: not so. you have n lines, the "gap" is part of the line (i.e. you should have a gap at the bottom as well, before you hit the bottom boundary) | 13:11.23 |
| paulgardiner | Okay. They n lines and n+1 gaps :-) Or do you not need one at the top? | 13:11.53 |
| tor7 | the top line starts at bbox-top + baseline-offset | 13:12.19 |
| | the bottom line has baseline-offset + gap until the bbox-bottom | 13:12.45 |
| | with lineheight = ascent + descent, baseline-offset == ascent, and gap == descent | 13:13.09 |
| | I think what you think is an arrangement like: bbox-top / ascent / baseline / descent / gap / ascent / baseline / descent / bbox-bottom | 13:14.07 |
| | in that case, yes, it'd be n - 1 gaps | 13:14.39 |
| paulgardiner | Okay. So ascent gives sufficient gap at the top on its own, but you need descent plus 1.2(ascent+descent) at the bottom? | 13:14.42 |
| tor7 | baseline-offset could be ascent + leading/2, gap = descent + leading/2 | 13:15.06 |
| | and leading = 0.2 * (ascent+descent) | 13:15.14 |
| | I'm not sure how html+css does with its layout here, I suspect we should follow that example | 13:15.59 |
| | paulgardiner: FT_Face has a "height" field, along with ascent and descent | 13:17.01 |
| paulgardiner | I didn't really want to get into it at the moment. Was hoping to just take the improvement I got from that commit. | 13:17.08 |
| tor7 | paulgardiner: okay, skip the 1.2 for the moment | 13:17.25 |
| paulgardiner | It's definitely worth doing and getting right, it's just that these things are coming up as subtasks of signature support. | 13:17.56 |
| tor7 | but I think using ascent as the baseline offset from top is still an improvement over using the height (which means the descenders of glyphs could get clipped since they'd extend past the bbox bottom) | 13:18.39 |
| paulgardiner | I'd better sprt out what's going on with y_orig though. | 13:18.40 |
| robin_watts_mac | hi all. | 13:21.34 |
| paulgardiner | tor7: ah right. The y_orig bit isn't really a layout change. That's just where I've changed whether somthing is multiplied by a factor outside a function to inside. That's just the inner workings of the text splitter. Not sure why that y_orig value is used, but it seems to work. | 13:23.21 |
| | robin_watts_mac: Hi. What's the animal sighting count now? | 13:23.58 |
| robin_watts_mac | saw black rhino this morning. | 13:24.23 |
| paulgardiner | Coo. Not too closely I hope! | 13:24.40 |
| robin_watts_mac | seconds later, 3 hours drive from nearest flushing toilet, I got hit by food poisoning, | 13:24.42 |
| | robin.dignity *= 0.0001; | 13:25.02 |
| paulgardiner | Yikes. I know that one all too well. | 13:25.41 |
| tor7 | robin_watts_mac: ouch. | 13:26.25 |
| | robin_watts_mac: but hey, rhinos! :) | 13:26.33 |
| paulgardiner | The symptoms of food poisoning and a close encounter with a rhino can be very similar. | 13:27.54 |
| | tor7: I changed fontheight to lineheight. Okay if I push those to golden? | 13:29.48 |
| robin_watts_mac | Helen here: it was quite a sight (and I don't mean the rhino). Poor Robin, he looks terrible now. | 13:30.21 |
| tor7 | paulgardiner: go ahead! | 13:30.36 |
| | robin_watts_mac: I have flashbacks to my food poisoning episode in india, the day before taking the overnight train from chennai to kerala | 13:31.21 |
| paulgardiner | robin_watts_mac: I'll tell you something even more scary that may take your mind of it: Linda and I are viewing a house on Fri about 800m from yours. | 13:31.47 |
| tor7 | robin_watts_mac: So do take good care of Robin for us! | 13:31.49 |
| robin_watts_mac | I will! He's feeling too ill to look at his laptop, so I know it's bad... | 13:32.27 |
| | Paul: Wow! That's so exciting!!! Where? | 13:32.54 |
| | Robin says he will laugh when your ADSL speed drops. | 13:33.20 |
| paulgardiner | http://www.chancellors.co.uk/properties/chipping-norton-property/detached-4-bedroom-house-for-sale/1352952/east-end-hook-norton?filter%5BpriceHigh%5D=560000&filter%5BpriceLow%5D=70000&filter%5BminNumberOfBeds%5D=0+Bedroom%28s%29&filter%5B0%5D=Property+Type%3ACottage&filter%5B1%5D=Property+style%3ADouble+Plot&grid=&area=&longitude=%3E&latitude=&branchName=Chipping+Norton+Property&saleType=Sale | 13:33.25 |
| | There's zero chance of it actually panning out, but still. | 13:34.01 |
| | robin_watts_mac: You probably run past it on occasion | 13:34.51 |
| robin_watts_mac | Very nice! I know where it is and it's a very nice location, quiet. Do let us know how you get on! | 13:36.22 |
| paulgardiner | robin_watts_mac: We've only just started taking the idea at all seriously, and so haven't even got our places on the market, so I can't see it happening with that place, but still - interesting. | 13:38.56 |
| | The advantages!! You might actually get your card reader back!! :-) | 13:39.50 |
| sebras | robin_watts_mac: ouch, doesn't sound too fun. I remember doing the same in reykjavÃk, on a bus tour. luckily only 4hours long... | 13:57.31 |
| henrys | robin_watts_mac: just getting in to work and reading about what happened, hope you recover quickly, | 14:15.08 |
| tor7 | henrys: shailesh mentioned he wants to look at the gxps segfaults. I asked before about the bounties (see the logs). | 15:09.59 |
| mvrhel_laptop | robin_watts_mac: sorry to hear about your illness. I can only imagine | 15:10.32 |
| kens | Hmm, I wonder if robin has seen this: | 15:11.06 |
| | http://www.firebox.com/product/3892/Marmite-Chocolate?via=whatsnew | 15:11.06 |
| paulgardiner | mvrhel_laptop: Your very lucky to only be able to imagine. I can "remember" :-( | 15:11.25 |
| mvrhel_laptop | I have had food poisoning before but never in a 3rd world country. | 15:12.40 |
| henrys | tor7:just tell him we'll do it like openjpeg negotiating bounties as we go along. | 15:13.07 |
| tor7 | henrys: alright. | 15:13.27 |
| henrys | so don't make the bugs bountiable, just tell him, I assume he drops in on your watch I don't see him here often. | 15:14.08 |
| tor7 | henrys: sounds good. I assume he's under NDA so I can send him the test files? | 15:14.59 |
| | does he have access to tests_private svn? | 15:15.07 |
| henrys | he does | 15:15.13 |
| paulgardiner | mvrhel_laptop: Nor me come to think of it. A significant distinction, now you mention it. | 15:15.31 |
| mvrhel_laptop | Hopefully he stays away from the Ceviche (recalling Scott in Miami) | 15:18.06 |
| ray_laptop | I hope Robin or Helen knows to keep him hydrated -- by IV if nothing else, since dehydration makes it MUCH worse and can make it take longer to get over | 16:15.04 |
| mvrhel_laptop | hi ray_laptop: got your message. will call in a minute | 20:06.04 |
| | ray_laptop: answer your skype call.... | 20:57.17 |
| | Forward 1 day (to 2013/08/08)>>> | |
IRC Logs