| | <<<Back 1 day (to 2015/01/11) | 20150112 |
| kens | http://www.bbc.co.uk/news/30743866 | 14:10.34 |
| | Maybe we should recode SOT in Minecraft..... | 14:12.24 |
| chrisl | Some people have *way* too much time...... | 14:12.57 |
| kens | Oddly that's *exactly* what Ian said.... | 14:13.08 |
| chrisl | Took two years complete - jeez! | 14:13.22 |
| ralph1 | Hi, looking for PDF digital signing, including timestamps from (multiple) TSAs, and/or verifying signatures. Does mupdf support signatures? | 16:00.49 |
| Robin_Watts | ralph1: MuPDF does do some digitial signing stuff, yes. | 16:23.44 |
| | paulgardiner may be able to give you more information. | 16:23.53 |
| ralph1 | Thanks Robin_Watts. (Not the Acorn/RISC OS Robin Watts? :) | 16:26.25 |
| paulgardiner | ralph1: only adding and checking of signature fields in forms at the moment. It's difficult to judge how much that gives towards your needs. | 16:26.54 |
| ralph1 | paulgardiner: Ah, thanks. I'm doing research for a friend. AIUI he's after signing the whole PDF, a la Acrobat on Windows. But I'll pass on mupdf does form signing. | 16:28.19 |
| paulgardiner | Well the addition of a signature in a form does sign the whole document. | 16:29.16 |
| rayjj | chrisl: good fix for the NumRenderingThreads icc_table premature free | 16:29.34 |
| ralph1 | paulgardiner: Hmm, OK. But there's also a separate means of signing a whole PDF without involving a form? Or maybe a form is used behind the scenes and he just doesn't realise. | 16:30.16 |
| chrisl | rayjj: thanks - I must admit, I'm not too happy about it being used that way without reference counting, but for now, at least...... | 16:30.51 |
| rayjj | chrisl: I am going to see if that fixes the timing sensitive issue with Bug 695771 since that didn't fail with BGPrint and failed differently depending on NRT setting (race triggered) | 16:30.52 |
| paulgardiner | Yes, there are several other types of signing. What I'm saying is possibly much of the needed code exists for all the different types, but it is difficult to be sure | 16:31.19 |
| rayjj | chrisl: ref counting amongst threads would require a mutex for the ref count | 16:31.32 |
| ralph1 | paulgardiner: Got it. Thanks. | 16:31.50 |
| chrisl | rayjj: yes, but it wouldn't really be a performance problem - it would only countup on thread creation and count down on thread destruction | 16:32.21 |
| rayjj | but it is pretty infrequent, so it wouldn't hurt performance. On Windoze we really have to watch mutex ops | 16:32.24 |
| Robin_Watts | ralph1: I did a bit of RISC OS in my youth, yes. But I could quit any time. | 16:32.36 |
| chrisl | The other question is: do we actually gain from having it shared between threads? | 16:33.05 |
| rayjj | Robin_Watts: you too ? I'm in recovery from doing OS's and real time executives for about 20 years now :-) | 16:34.01 |
| ralph1 | Robin_Watts: Well, thanks for the Pink docs site. I used to refer to it a lot whenever a question about old stuff came up. | 16:35.30 |
| rayjj | chrisl: probably, yes. Forming a link is a rather expensive operation, which is why we cache it. So constructing the link only once for N threads does save us. | 16:35.32 |
| Robin_Watts | ralph1: Ah, right. That stuff has been sat there for years untouched :) | 16:36.03 |
| rayjj | chrisl: but AFAIK mvrhel never benchmarked it, and I know I didn't | 16:36.47 |
| chrisl | rayjj: I just don't like the fact that we "just have to know" that the parent device owns the icc_table | 16:37.52 |
| rayjj | chrisl: and the othe aspect is that link profiles can be rather large, and if there are separate caches per thread, we would have separate links for each thread for evey colorspace pair link | 16:38.23 |
| | chrisl: if it bothers you a lot, ref counting wouldn't be objectionable | 16:39.04 |
| chrisl | rayjj: it's just that kind of hidden assumption that seems to end up biting us eventually | 16:39.52 |
| | bbiaw.... | 16:43.01 |
| rayjj | strange. Got dropped and it took forever to reconnect | 16:44.17 |
| | chrisl: true, but not as often as not checking if a malloc fails ;-) | 16:44.42 |
| kens | Hmm, so my latest optimisation makes pdfwrite 8x faster for a specific (dumb) file. I guess that's good.... | 16:57.36 |
| Robin_Watts | rayjj, chrisl: Sorry, picking up bits of this conversation here... | 16:58.52 |
| | I agree that it's bad to just magically know whether a given device owns the link cache or not. | 16:59.17 |
| | Could we just have a flag in the device header next to the link cache pointer that's 1 if we own it, or 2 if we don't ? | 16:59.36 |
| | s/2/0/ | 16:59.56 |
| | presumably we have to have some sort of mutex on link cache update operations though? | 17:00.23 |
| chrisl | Robin_Watts: personally, I'd prefer reference counting it - we have a mechanism for dealing with this situation, why not use it? Instead of implementing another one | 17:01.19 |
| Robin_Watts | Our ref counting is NOT threadsafe though, right? | 17:02.11 |
| chrisl | Not inherently, no | 17:02.26 |
| Robin_Watts | So, we don't have a mechanism for dealing with it. | 17:02.38 |
| | but I take your point. | 17:03.00 |
| chrisl | Using a flag really just moves the place where we have to "just know", IMO | 17:03.55 |
| Robin_Watts | chrisl: Every device will clean up if the flag is set. It's the device creation, where 'sub devices' are created that just have to know not to set the flag when it copies the link. | 17:06.21 |
| | It seems fairly clean to me. But given we still have to lock something everytime we access the cache, we might as well be ref counting, and that can be seen as being even cleaner. | 17:07.04 |
| kens | I'd prefer ref counting, adding more flags is likely to make what I'm currently doing still harder | 17:07.34 |
| chrisl | I don't actually think we need to lock at all, since the sub-devices are both created and destroyed in the main thread. | 17:07.50 |
| Robin_Watts | chrisl: We need to lock *something* in the icc link cache whenever we access it, right? | 17:08.22 |
| | cos otherwise while one thread is walking it, another might be updating it. | 17:08.36 |
| chrisl | Robin_Watts: yes, I was only meaning for the reference counting | 17:09.18 |
| Robin_Watts | chrisl: Right. | 17:09.34 |
| | I kinda feel that you're now saying "we can just *know* that we don't need to lock for the ref counting". | 17:10.07 |
| | and if we're in that position, it'd be cleaner to not bother ref counting and "just know" that we need to free the cache when the parent device is cleared. | 17:10.45 |
| | i.e I don't see how ref counting helps simplify the situation here. | 17:11.08 |
| chrisl | I feel it would be clearer where and how ownership goes with reference counting. | 17:12.00 |
| | I would *prefer* to have a lock on the reference count, but if there was any worry about performance, then it could be left out | 17:12.49 |
| Robin_Watts | chrisl: Using reference counting implies that the ownership *can* be anywhere other than the parent device. | 17:13.28 |
| | bah. Angels. Pin. I'll shut up. | 17:13.54 |
| chrisl | Robin_Watts: that would be clearer, I think.... | 17:14.05 |
| | Anyway, it's not *that* important, as I know understand the assumption, and have fixed my fix that missed the assumption | 17:17.01 |
| henrys | finally back from the coldest days of my life in chicago. wow never been that cold. | 17:22.55 |
| kens | Oh yeah I saw the forecast from Austria, they were talking -15 C | 17:23.18 |
| henrys | this was -34 with wind chill but around the same without. | 17:25.15 |
| kens | OK that'ds the latest stupid use of glyphshow looked at, I'll finish it omorrow. Night all | 17:27.32 |
| rayjj | The problem with a mutex for the ref count for link cache is that it can't be *in* the link cache since that gets deleted when the ref cont goes to 0 (which is while the mutex is "locked", so we can't unlock it) | 17:41.15 |
| | henrys: really? Surely it gets just as cold in CO ? | 17:41.50 |
| henrys | rayjj: the humid winds off the lake I think make a difference. I had to walk outside a lot with my son on the naval base and I just couldn't get warm. Maybe lost too much weight last triathlon season. | 17:43.33 |
| rayjj | henrys: that's a good reason to stay fat :-) My sister, who also runs marathons, has really low body fat and gets cold easily. I'm happy with my normal range BMI now and don't feel the need to shed further | 17:45.18 |
| mvrhel_laptop | ok. finally I have the xpswrite device working with image and icc profiles without the temp file issues I was running into early | 20:29.11 |
| | the device still is going to need a bit of work to deal with docs that have a large number of pages but that can be done later | 20:30.04 |
| | rayjj: need to clean up a couple things, then I will *finally* have something for you to review | 20:36.00 |
| | heading off to eat lunch now | 20:36.06 |
| | Forward 1 day (to 2015/01/13)>>> | |
IRC Logs