| | <<<Back 1 day (to 2015/04/15) | 20150416 |
| mvrhel_laptop | ok text selection goof up fixed. now on to landscape printing issues... | 04:11.45 |
| | and sure enough it is wrong. I had this working at one time... | 04:23.12 |
| | ah. I see. the issue is occurring when the printer is setup to print in landscape | 04:44.24 |
| | ok. looks like some fooling with the print ticket will solve this | 05:02.39 |
| | done for the night. will finish up this landscape stuff tomorrow. between the print ticket, the source document and how I setup gs to create the xps content, I should be able to make all of this work | 05:17.56 |
| Robin_Watts | tor8: 1 fix on robin/master. | 08:48.59 |
| | Then we can release? | 08:49.04 |
| | actually, fred pointed out another tiny possible thing last night. | 08:50.26 |
| tor8 | okay? | 08:51.18 |
| | rc2 or actual release? | 08:51.23 |
| Robin_Watts | actual release. | 08:51.55 |
| | Ok, 2 fixes on robin/master | 08:53.22 |
| | Ordinarily I'd dislike bending our code for the sake of C++, but this is such a small bend, and it helps fred. | 08:53.47 |
| | (and presumably mvrhel) | 08:54.04 |
| tor8 | oh. you're serious? c++ can't handle typedef enum properly? | 08:55.01 |
| Robin_Watts | tor8: apparently. | 08:55.49 |
| | trivially tweaked version online now. | 08:56.13 |
| kens | Robin_Watts : tor8 can you add encryption to a previously unencrypted PDF file using MuPDF ? | 08:56.35 |
| Robin_Watts | kens: Nope. | 08:57.03 |
| kens | That explains the SO queston then :-) | 08:57.13 |
| Robin_Watts | MuPDF cannot encrypt anything. We can remove encryption, but not add it. | 08:57.21 |
| kens | I'll asnwer the quesiotn, thanks | 08:57.34 |
| tor8 | ridiculous. but okay, LGTM. | 08:57.37 |
| Robin_Watts | tor8: Both commits? | 08:57.46 |
| | kens: I wonder if it's the same bloke that mailed me last night. | 08:58.02 |
| tor8 | both commits. I already pushed the first one 15 minutes ago. | 08:58.05 |
| Robin_Watts | Ta. | 08:58.10 |
| kens | Juzer Dhuliawala | 08:58.13 |
| Robin_Watts | Yeah, that's the bloke. | 08:58.21 |
| kens | He didn't like your answer I guess. He looked like rather a muppet from the question | 08:58.41 |
| Robin_Watts | I just wrote an answer back to him, but his email address was invalid and it lost my mail. | 08:58.48 |
| kens | OK well I can answer ths SO queston, or you cna if you prefer ? I haven't hit the 'go' button on my reply yet. | 08:59.14 |
| Robin_Watts | kens: You go for it. | 09:00.05 |
| kens | OK will do | 09:00.09 |
| Robin_Watts | Got a URL for the question? | 09:00.21 |
| kens | Oh actually he's asking about decryption, but he's phrasing it badly | 09:00.33 |
| Robin_Watts | Most of my answer was "have you read the license?" | 09:00.34 |
| kens | http://stackoverflow.com/questions/29669522/mupdf-encryption-decryption-issue | 09:00.39 |
| tor8 | kens: Robin_Watts: looks to me from that question as if he just wants his own layer of DRM on top | 09:00.53 |
| Robin_Watts | Cos if he's using the AGPL version then he has to give away his encryption key... | 09:00.58 |
| kens | :-D | 09:01.04 |
| Robin_Watts | tor8: exactly. | 09:01.10 |
| tor8 | the easy answer is, decrypt it yourself into a char* buffer and open the pdf from there | 09:01.16 |
| kens | I'll let you answer it since you have a canned answer already | 09:01.25 |
| tor8 | but what robin said is better :) | 09:01.30 |
| Robin_Watts | kens: i will. | 09:01.33 |
| tor8 | Robin_Watts: what was the thing fred pointed out yesterday? | 09:34.00 |
| | or was that the C++ enum thing | 09:34.07 |
| Robin_Watts | tor8: the enum thing, yes. | 09:50.32 |
| tor8 | Robin_Watts: okay. so are we ready to tag and release? | 09:55.28 |
| Robin_Watts | tor8: I think so. | 10:10.49 |
| | Juzer is the guy from SO. Hi Juzer. | 10:12.08 |
| Juzer | Hi | 10:12.36 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 10:12.36 |
| tor8 | Robin_Watts: tag pushed, source tarball uploaded | 10:13.01 |
| Juzer | I wanted some information about the ways we can use to encrypt files and decrypt the same using mupdf | 10:13.27 |
| Robin_Watts | Juzer: First off, can we talk about licensing? | 10:14.18 |
| Juzer | i have read the information regarding the GNU AGPL licence and i feel its fits the purpose | 10:14.20 |
| Robin_Watts | So, are you going to be distributing your app ? | 10:14.36 |
| Juzer | it is a closed App which will be used by limited number of people | 10:15.06 |
| Robin_Watts | ok. | 10:15.23 |
| | Those people all being within your company? | 10:16.00 |
| Juzer | and providing them the sources or exposing the DRM features is Ok | 10:16.25 |
| Robin_Watts | ok. The question then occurs to me... why bother with DRM then? | 10:16.41 |
| Juzer | it can happen that pdf files can get released to anyone...hence my main concern is that no one else expect those people who the file is intended for shld see it | 10:17.27 |
| Robin_Watts | ok. | 10:18.10 |
| | So, the easiest way to proceed would be to generate those PDF files with a password. | 10:18.29 |
| | and then have your app know the password. | 10:18.48 |
| Juzer | But passwords can be broken in pdf right ? | 10:19.02 |
| Robin_Watts | Not easily, no. | 10:19.21 |
| Juzer | i mean there are tonns of ways to unlock and password locked pdf right ? | 10:19.26 |
| Robin_Watts | If you know the password, then you can decrypt the PDF to an unpassworded form. | 10:19.48 |
| Juzer | unlock a password locked pdf | 10:19.53 |
| Robin_Watts | It's not easy to take a passworded pdf and make an unpassworded one without the password. | 10:20.15 |
| kens | There are brute force attack tools | 10:21.15 |
| Juzer | can i get an insight as to what happens if you lock a pdf with password ? | 10:21.16 |
| | does the file get encrypted or something ? | 10:21.25 |
| kens | Yes | 10:21.29 |
| Robin_Watts | Juzer: Absolutely. | 10:21.31 |
| | There are different filters, but (for example) the data within the file might be AES encrypted. | 10:22.02 |
| Juzer | are you sure that its 99.9% impossible to break it ? | 10:22.13 |
| kens | You defintely want to use a more recent encryption filter the old ones can be broken in a matter of days with a brute force attack, sometimes even in minutes | 10:22.33 |
| Robin_Watts | If you pick a suitably long and convoluted password, and a modern encryption filter, you're golden. | 10:22.47 |
| kens | Its never iimpossible to break encryption, because you can always try every possible password | 10:22.56 |
| | But you can make in unreasonably difficult | 10:23.12 |
| Juzer | True... | 10:23.40 |
| | Sorry, i have a few questions more, but i have to leave for some work...i will be back in an hour or so... | 10:24.12 |
| kens | As Robin said (and me too) use one of the more recent fiklters (AES 256 should be fine), use a decent password of a good length, and it will be years of work to break | 10:24.13 |
| Juzer | Can i get some guidance as to how can i set passwords with AES filter and then decrypt it in an Android App...i have been using the Android library for mupdf for my other open work...but none with respect to passwords | 10:25.55 |
| Robin_Watts | Juzer: MuPDF cannot encypt files, only decrypt them. | 10:30.22 |
| | You'd need to use a different piece of software to encrypt things. | 10:30.35 |
| pipitas | tor8: I saw in the log that 2 days ago you had asked me about the EPUB3 I was testing (18:40.18h): "pipitas: what does the content.opf xml tag <package ... version=""> list for version number?" â Sorry, didn't see it at the time, just found it in the logs. | 10:40.11 |
| | tor8: The answer is "3.0" | 10:40.22 |
| Robin_Watts | tor8: I'll do windows and android builds then. | 10:41.26 |
| | pipitas: I thought it was 42 ? | 10:41.43 |
| | or July 16th ? | 10:42.04 |
| tor8 | pipitas: right, that explains why the CSS is using CSS3 syntax | 10:48.40 |
| | pipitas: I've added a fz_warn that shows a warning if the version is not "2.0" and we made the CSS parser try to ignore errors and recover | 10:49.46 |
| | which should help a bit | 10:49.52 |
| Robin_Watts | tor8: windows zips uploading now. I'll do android builds after a run. | 10:57.55 |
| pipitas | Robin_Watts: maybe after some more years of computation answer will change to "42". | 11:15.39 |
| tor8 | Robin_Watts: oh! we already have a -a option to mutool clean | 11:17.54 |
| Juzer | Hi | 12:15.23 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 12:15.23 |
| Juzer | Robin: I am aware of that a external encrypting program has to be created to encrypt the pdf.... | 12:16.04 |
| | I already have a .NET based pdf encryption application which can encrypt the entire file using AES with a key... | 12:16.42 |
| | Can you tell me whether, encrypting the entire file is same as using password protection for pdf ? | 12:17.09 |
| | also, if i encrypt the entire file, will mupdf decrypt it using the intent.putExtra("password", "PDF document password"); in Android | 12:18.19 |
| | ?? | 12:18.22 |
| Robin_Watts | Juzer: Encrypting the entire file using AES is not the same, no. | 12:36.10 |
| | PDF encryption encrypts objects within the file. The file structure itself remains unencrypted. | 12:36.34 |
| | If you want to pursue a solution where the entire file is encrypted, then you can do that, yes. | 12:37.02 |
| | You'd just need to decrypt the file into a buffer before passing it to MuPDF. | 12:37.20 |
| | i.e. MuPDF would see it unencrypted. | 12:37.27 |
| | That does require you to hold the entire file in memory of course. | 12:37.44 |
| | To avoid that, you can encrypt the file block by block, and then decrypt blocks on the fly (via a cache to allow for random access). | 12:38.14 |
| Juzer | Can you guide me as to how can i achieve that using the pdf_crypt.c file ? | 12:39.59 |
| | or is there any other referencing file which i have to look into.... ? | 12:40.21 |
| Robin_Watts | You cannot achieve that using the pdf_crypt.c file. | 12:41.10 |
| | First off, which of the solutions I have outlined are you interested in pursuing? | 12:41.53 |
| Juzer | i guess the one with my encryption application i can use to encrypt the file...i require that how can mupdf decrypt the bytes on the fly...? | 12:45.37 |
| tor8 | Robin_Watts: maybe we should add a fz_reusable_stream type, though I guess in essence that just boils down to a fz_read_all and fz_open_buffer... so nevermind | 12:46.58 |
| Robin_Watts | Juzer: So, you want to encode the entire file somehow to get the version to ship. Then you want to write a wrapper that will load that entire file into memory, decrypt it, and then pass it to mupdf. | 12:49.20 |
| | MuPDF will not be involved in the encryption/decryption at all. | 12:49.38 |
| Juzer | ok, i will make things more simple.....suppose if i want to decrypt only the 1st 100 bytes of the file on the fly and rest remain as it is......? | 12:50.21 |
| | my simple question is that, does Mupdf read the file byte wise or it reads the entire file together....? | 12:51.36 |
| tor8 | Juzer: mupdf reads the file using a fz_stream object, which has both read and seek functions | 12:52.37 |
| kens | PDF file require random access to the entire file contents. You can decrypt the file a bit at a time, but that would require altering MuPDF stream interface I think | 12:52.42 |
| Juzer | yes i guess +kens is right.. | 12:54.37 |
| kens | You can't decrypt the first 1024, pass that to MuPDF, then wait for the next read request, decrypt the next 1024 bytes and so on. Just for starters PDF files store the pointer to the xref at the end of the file, whcih is the first thng you need to get out. | 12:54.42 |
| | The problem with decrypting 'a bit at a time' is that you usually can#t just jump to a portion of the encrypted stream and begin decrypting, you normally have to decrypt from the beginning to the point you want. Since MuPDF will be jumping around the file, ths would be very slow | 12:55.40 |
| Juzer | hmmm | 12:56.44 |
| kens | So for example, to find the 'startxref' key you start by going to the end of the file and searching backwards. | 12:57.21 |
| | If your file is encrypted, then in order to get the last 1024 bytes you would have to decrypt the whole file. | 12:57.39 |
| Juzer | i am seeing the fitz/stream-read.c file..... | 12:57.45 |
| | in that there is a fz_read function which i guess read the file byte wise | 12:58.03 |
| Robin_Watts | Juzer: This is why I said you would either have to decode the whole file to a buffer and pass that in to MuPDF (so it could seek within the file) or you'd have to encrypt it in blocks. | 12:58.23 |
| kens | If the startxref then points to a location in the file previous to the block we currently have available, then we would need to start at the beginning, and decrypt the stream unti we reached the poitn we want. | 12:58.25 |
| | Block encryption would be an improvement of course. | 12:58.46 |
| Juzer | does the fz_read read function start the reading from start of file ? | 13:00.00 |
| | i mean the stream..... | 13:00.34 |
| Robin_Watts | fz_read reads from an fz_stream. | 13:00.35 |
| tor8 | Juzer: stream-open.c is a better file to look at | 13:00.49 |
| Robin_Watts | You need to read and understand the fz_stream interface. | 13:00.49 |
| Juzer | i guess stream-open.c and stream-read.c are the files to look at | 13:04.59 |
| | let me perform some R&D on it.... | 13:05.31 |
| | +kens has also pointed out beautifully about decryption from start always.. | 13:07.37 |
| | Also Robin...about encrypting blocks...but that would ideally slow down the entire process a lot... | 13:08.55 |
| Robin_Watts | Juzer: Not necessarily. | 13:09.17 |
| | If you decode 1024 bytes (say) at a time and keep the last few blocks you have decoded in a cache, then you can generally avoid decoding the same block multiple times. | 13:10.21 |
| | It's a tradeoff of course. | 13:10.30 |
| | We have customers who have done exactly this. | 13:10.43 |
| Juzer | but that does not help you when you are seeking the file or in other words moving to another part of the pdf... | 13:12.04 |
| tor8 | Robin_Watts: how did you generate resources/pdf/names.txt? | 13:12.22 |
| kens | Sure it does, encrypt eaxch 1k block separately | 13:12.23 |
| tor8 | there seem to be some dud entries in there | 13:12.27 |
| | like "FlateDecod" | 13:12.31 |
| Robin_Watts | tor8: grep and then hand edit. | 13:12.49 |
| | tor8: Crap. | 13:13.00 |
| tor8 | and a few other "*Decod" entries as well | 13:13.19 |
| chrisl | FlateDecod? Remove expected fish from your flate compressed stream? | 13:13.35 |
| Robin_Watts | tor8: OK. Extra entries won't hurt us. | 13:14.10 |
| | Do you want to redo the release for that ? | 13:14.16 |
| tor8 | Robin_Watts: no. | 13:15.03 |
| Robin_Watts | Ok. I will push on with the android builds then. | 13:15.13 |
| tor8 | but we should write a script to automatically generate it from source | 13:15.24 |
| | I can do that once I've fixed up this -z option to pdfclean | 13:15.42 |
| Robin_Watts | seems a bit incestuous :) | 13:18.58 |
| tor8 | start using a new PDF_NAME_Foo, run the script and go :) | 13:19.50 |
| Robin_Watts | The source only uses PDF_NAMEs that are defined in the thing that that file generates. And you want to generate that file from the PDF_NAMEs that are used? :) | 13:19.52 |
| | tor8: Or just add the name to the file and 'make' ? | 13:20.09 |
| tor8 | I'm not sure we want to regenerate the names.txt every time we edit the source | 13:20.35 |
| Robin_Watts | tor8: We don't. | 13:22.01 |
| | but my point is that adding a new name is just a matter of adding a new line to that file. | 13:22.18 |
| | I don't necessarily see the point of autogenerating it. | 13:22.32 |
| tor8 | yes, but names come and go, and it would be nice to have some way to make sure it covers the exact set needed | 13:22.42 |
| Robin_Watts | tor8: I'm inclined to say we shouldn't remove names from the file. | 13:23.04 |
| tor8 | my point is if you start using a non-existant PDF_NAME_, running "make names" should be able to add it automatically (and remove unused ones) | 13:23.07 |
| Robin_Watts | cos third party code might use the name. | 13:23.24 |
| tor8 | or at least generate a new file we can diff against | 13:23.31 |
| Robin_Watts | Changing the list of names changes the value used for each name. | 13:24.18 |
| tor8 | but I'm not hugely invested in the idea. just thought it would be handy given the typos I spotted. | 13:24.28 |
| Robin_Watts | which means libraries and sources have to agree on the name list they used. | 13:24.32 |
| | hence frequent changes would be bad. | 13:24.46 |
| tor8 | ... ABI compatibility is a bitch | 13:24.52 |
| | if they wanted to be safer, should be using the string interface instead like our old code did | 13:25.19 |
| | aren't the names sorted alphabetically so dictionary lookups on sorted entries are fast? | 13:26.05 |
| Robin_Watts | The names are sorted alphabetically. | 13:26.20 |
| tor8 | oh wait, they'd be sorted on the string value anyway | 13:26.23 |
| | because they'd have to be able to mix with non-standard names | 13:26.36 |
| Robin_Watts | but, indeed, comparisons are always done stringwise. | 13:26.52 |
| | (well, equality is done first using pointer if possible, then stringwise) | 13:27.23 |
| | tor8: Android builds done, just uploading them now. | 13:32.45 |
| | Should we delete the 1.6 symlinks from the mupdf.com/download dir ? | 13:34.24 |
| tor8 | Robin_Watts: yeah. | 13:34.55 |
| Robin_Watts | Done. | 13:36.45 |
| | And the news is updated. | 13:36.52 |
| | I'll upload the apks to google play after lunch. | 13:37.03 |
| tor8 | Robin_Watts: fab, thanks. though I'd prefer it if you renamed the apk's to be lower case (so they sort properly in the web view) | 13:46.21 |
| | Robin_Watts: two commits on tor/master (for post-release) to handle -a during sanitization, and -z for pdfclean | 13:53.54 |
| Robin_Watts | D'Oh. | 14:12.44 |
| | tor8: done. | 14:14.29 |
| | paulgardiner: Can you do an ios release of MuPDF 1.7 please? | 14:20.11 |
| paulgardiner | Yeah. Should be able to | 14:20.42 |
| Robin_Watts | OK. apk published to google play, and text updated. | 14:34.51 |
| paulgardiner | Somebody will need to give me the "What's new in this version" text | 14:35.03 |
| Robin_Watts | paulgardiner: mupdf.com/news.html :) | 14:35.18 |
| | On Google Play, I used: | 14:36.22 |
| paulgardiner | So we want all that, or just what is noticeable from the app? | 14:36.30 |
| Robin_Watts | New MuPDF 1.7 release. | 14:36.33 |
| | Uses less memory, runs even faster, and now handles epub (v2, no-DRM) files too! | 14:36.35 |
| paulgardiner | s/So/Do/ | 14:36.39 |
| Robin_Watts | I also updated the Full description a bit. Instead of saying "It also reads XPS/OpenXPS documents." it now says: | 14:37.25 |
| | It also reads XPS/OpenXPS documents, and v2 EPUB files with no DRM. | 14:37.34 |
| | henrys: MuPDF release is out. | 14:38.38 |
| paulgardiner | XPS is already mentioned. Is OpenXPS something new? | 14:39.27 |
| Robin_Watts | No. | 14:39.36 |
| | OpenXPS is XPS with a trivial change to something in the file. | 14:40.05 |
| henrys | ah you guys are early I thought it would be another week. Great! | 14:42.48 |
| | nice spring snow today! we need the moisture | 15:08.03 |
| Robin_Watts | henrys: Do you need anything from us for the newsletter? | 15:57.12 |
| kens | G'night folks | 16:12.30 |
| henrys | Robin_Watts: I usually just expand upon the mupdf news stuff. | 16:21.40 |
| | Robin_Watts: He also wants some sot stuff and I fear I'm going to find empty logs but we'll see. | 16:22.48 |
| Robin_Watts | There should be stuff in the <log></log> sections. | 16:26.53 |
| | Possibly not as much groundbreaking stuff as we all might like, but... | 16:27.31 |
| henrys | ugh big customer regression for michael | 16:47.47 |
| rayjj | mvrhel: (for the logs). I'm not trying to dump on you by opening these Altona Technical bugs, but it is quite involved and I need some help on explaining what is going on (w.r.t. color profile effects) and determining if we actually have a bug. These _don't_ seem to be related to Overprint | 17:59.12 |
| mvrhel | so I am having the strangest issue ever with my laptop. the mouse cursor has gone away after windows did one of its auto updates. what a bunch of crap | 18:14.38 |
| Robin_Watts | mvrhel: urgh, | 18:20.26 |
| mvrhel | good lord | 18:21.30 |
| | I restarted multiple times no help | 18:21.37 |
| | finally did a hard shut down at the switch and now it is back | 18:21.54 |
| | wtf | 18:22.00 |
| | ugh a fast thresholding bug | 18:42.59 |
| | why did marcosw say this would be easy | 18:43.11 |
| | that plus two altona file bugs. I hit the jackpot today | 18:46.33 |
| | lunch time | 18:46.51 |
| mvrhel_laptop | landscape issues fixed. now on to the issues that fred just showed me then I will start slogging on fast thresholding... | 20:58.05 |
| | ok new gsview in ~mvrhel/gsview | 23:00.27 |
| | for windows | 23:00.33 |
| | damn it I see that the window resizing is not always adjusting the document size grrrr | 23:35.12 |
| | Forward 1 day (to 2015/04/17)>>> | |
IRC Logs