| | <<<Back 1 day (to 2018/07/15) | 20180716 |
| kens | paulgardiner : ping | 09:15.26 |
| | tor8 I think what paulgardiner is asking for in his bug report isn't possible | 09:18.35 |
| | Actually, maybe it is | 09:20.30 |
| tor8 | kens: incremental saving and encryption? | 09:20.50 |
| kens | If there's no user password then I guess we must be suing the default, so I guess it shuld be possible to encrypt the incremental update with that as well. | 09:21.02 |
| | Yeah incremental updating an encrypted file | 09:21.14 |
| tor8 | Hm, yeah, I haven't thought through the two password things | 09:21.41 |
| paulgardiner | I don't really know enough about it, but if it weren't possible, I'm pretty sure neither would it be possible to add a second signature to an already signed document | 09:27.11 |
| | ... and I have an encrypted file that has multiple signature fields. | 09:27.50 |
| kens | Nah you can ignore me, it should be possible, because the encryption must be using the default | 09:27.51 |
| | If it wasn't, you couldn't decrypt it without a password. And of course, if you do need a user password, then you can re-encrypt with tat. Of xcourse, you have to make certain you are using the same encryption handler | 09:28.37 |
| paulgardiner | I have a more serious problem than that one: I have several files that when signed with mupdf create resulting files that AR reports having incorrect byte ranges in the signature field, although the byte range seems fine. These same files (whether signed by mupdf or taken in their original form) are completely reorganised if altered by AR. | 09:31.18 |
| | They all have hybrid xrefs. I'm considering implementing hybrid incremental updating, in case the lack of that in mupdf is the cause. | 09:32.02 |
| kens | Acrobat does that when it repairs files, yes. Alteration (adding stuff or deleting it) does the same. | 09:32.10 |
| | Well hybrid files were a rare thing really | 09:32.34 |
| | I guess Acrobat doesn't emit them as hybrids any more | 09:33.07 |
| paulgardiner | Strangely I have something like 3 in my collection of 25 example forms. | 09:33.13 |
| kens | :-D I was oging by the number in our test suite, its a small percentage | 09:33.50 |
| | Hmm looks like the cluster just restarted my tests :-( | 09:34.24 |
| paulgardiner | That would be great if this is a rare case we can ignore. | 09:34.40 |
| | Maybe it makes sense to wait to see if a customer runs into it and not worry for now. | 09:35.04 |
| kens | Well, it was a way of writing 1.5 files that could also be opened by PDF 1.4 and below readers | 09:35.05 |
| | I'm not sure we cna ignore it though | 09:35.44 |
| tor8 | paulgardiner: oh! is it because we mix old (<1.5) and new (1.5) style xrefs when we save incrementally? | 09:36.23 |
| | because IIRC our saving code never saves new style xrefs, we always save the old style | 09:36.39 |
| paulgardiner | One strange thing is that one of the files at least already has a hidden signature. The reorganisation will definitely invalidate that. I suppose it could be signed by Adobe in which case it could be reapplied. | 09:37.03 |
| tor8 | we should be able to add new style xrefs (even if we don't do compressed object streams) | 09:37.10 |
| kens | Presumably that would confuse anything which could read teh new xref streams, because they won't have been uipdated ? | 09:37.11 |
| paulgardiner | tor8: we handle both | 09:37.17 |
| tor8 | paulgardiner: we can read both, but can we *write* both? | 09:37.26 |
| paulgardiner | We write both. I added that at some stage | 09:37.36 |
| | But we don't write hybrid ones | 09:37.50 |
| | For a hybrid starting file, mupdf writes the new style of xref | 09:38.20 |
| tor8 | paulgardiner: ah yes, writexrefstream | 09:38.22 |
| kens | I'm not certain you need to for an incremental update | 09:38.26 |
| tor8 | the spec works if you mix old and new style, I believe | 09:38.37 |
| kens | Yes I think so | 09:38.44 |
| | I have some files like that | 09:38.49 |
| tor8 | providing both, though, I don't see how that would work | 09:39.10 |
| | you still need one offset for the startxref | 09:39.10 |
| kens | For incremental updates I don't think you can add both | 09:39.32 |
| | Just one or the other | 09:39.39 |
| paulgardiner | I haven't found anything in the spec that says incremental update have to maintain hybrid xrefs, but I was just considering implementing it as something that by chance could solve the AR reorg problem | 09:39.47 |
| tor8 | kens: huh. I don't think I've ever seen that before :) | 09:39.52 |
| kens | Of course, if you add new xrefs, then that will render it no longer a true hybrid | 09:39.54 |
| paulgardiner | kens: I think all hybrid files are created with a dummy incremental update | 09:40.16 |
| tor8 | why on earth would you do a hybrid xref, there's no benefit to writing both formats? | 09:40.28 |
| kens | Its been a few months since I looked at hybrid files, I can't recall exactly how they work I'm afraid. | 09:40.41 |
| | tor8 when PDF 1.5 was new | 09:40.53 |
| | It meant you could write a PDF 1.5 file that a PDF 1.4 reader could still handle | 09:41.16 |
| tor8 | the main reason for new style xrefs is saving space when compressing it, but it's *required* if you have compressed object streams because that info can't be expressed in the old style xref | 09:41.19 |
| paulgardiner | tor8: do you mean why would "one", or why would "I"? | 09:41.25 |
| tor8 | why would "one" | 09:41.31 |
| paulgardiner | yeah, they don't seem of much use. | 09:41.49 |
| kens | Like I sadi its a backward-compatibility thing | 09:42.00 |
| | I'm not saying I think it was sensible.... | 09:42.11 |
| tor8 | yeah, I guess so, I see now in the spec where they are defined | 09:42.30 |
| paulgardiner | I very much doubt that implementing it would stop AR reorganising the file. Just grasping at straws really. | 09:42.35 |
| tor8 | and there it says a 1.4 viewer won't see the 'new' object at all | 09:43.19 |
| kens | Ah, well there you go then | 09:43.30 |
| | So an incremental update of a hybrid file really makes no sense at all | 09:43.43 |
| paulgardiner | One way I considered solving this was to save incrementally only if the file had already contained a signature, but that wont help because at least some of these file do already contain signatures. | 09:44.05 |
| | s/had// | 09:44.55 |
| kens | My guess would be that reader sees its a hybrid file with an incremental update, says 'that makes no sense' and rewrites it as a PDF 1.5 file | 09:45.11 |
| | SO it looks like you should save inrementally only if its not a hybrid file | 09:45.36 |
| paulgardiner | Yeah, but it already has a signature so I'm stuck | 09:46.00 |
| kens | Can't you just rewrite the entire file, like Acrobat, as a PDF 1.5 ? | 09:46.17 |
| | I guess that breaks the signature | 09:46.39 |
| tor8 | paulgardiner: what happens if you in the new incremental update also include the Prev entry to make it a hybrid with the old part pointing to the original old part? | 09:47.06 |
| | I guess that's mean making the incremental update have a full new style xref section with all the object offsets in the whole file in it | 09:47.58 |
| paulgardiner | I did that to one file by hand but I still had complaints about the byte range (although possibly for good reason because the byte range then didn't include what I'd added by hand | 09:48.29 |
| | Well, to be precise, by hand I added an empty old-style xref with /Prev and /StmRef set up correctly | 09:49.51 |
| | Is it StmRef? something like that | 09:50.04 |
| tor8 | XRefStm | 09:51.10 |
| paulgardiner | That's the one | 09:51.15 |
| | I may have been confusing myself. Some at least of these problem files don't already contain signatures, and saving non-incrementally when signing looks to work | 09:59.23 |
| | That works with all three files. So Ken's suggestion would work: recognise hybrid xrefs and make that another case where incremental updates are disallowed. Or I could always save non-incrementally if a file has no existing signature. Either way would solve this problem. I'm favouring the former. | 10:07.03 |
| tor8 | fredross-perry (for the logs): could you give the commit on tor/android a try, and see if that works around the binary data size issues with the newer ndk toolchain? | 14:26.15 |
| fredross-perry | tor8 - that commit is close. But in addition to the "_cff_size" item, you need to add the "_cff" item pointing to the top of the array, and also remove the "urw_" and "sil_" strings from the filename. I'll check something in later showing what I mean. | 16:56.02 |
| | for example, the two things you add to the end of the font code should look like this: | 16:59.23 |
| | unsigned int _binary_resources_fonts_NimbusRoman_Bold_cff_size = 57291; | 16:59.24 |
| | unsigned int _binary_resources_fonts_NimbusRoman_Bold_cff = _binary_resources_fonts_urw_NimbusRoman_Bold_cff_start; | 16:59.25 |
| moolc | fredross-perry: ISO/IEC 9899:201x 7.1.3 reserves identifiers that begin with an underscore in a file scope, so i'd have used some other prefix | 17:07.00 |
| fredross-perry | tor8 - look at the commit in my forms2 branch. | 19:07.31 |
| | tor8 - This is my guess: the "end-start" approach to calculating the size relies on the compiler putting one thing immediately after the other, and character-aligned, which the android tools may not do. That's why having hexdump add the size and using that in noto.c works. | 21:58.25 |
| | Forward 1 day (to 2018/07/17)>>> | |
Log of #mupdf at irc.freenode.net.