| | <<<Back 1 day (to 2019/09/09) | Fwd 1 day (to 2019/09/11)>>> | 20190910 |
| Shah | Hi | 05:57.15 |
| mubot | Welcome to #mupdf, the channel for 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. | 05:57.15 |
| Shah | I want to store the annotations separately i.e. in server side. Is it possible in MuPDF? | 05:58.20 |
| | Hi | 07:01.30 |
| mubot | Welcome to #mupdf, the channel for 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. | 07:01.30 |
| Shah | I want to store the annotations separately i.e. in server side. Is it possible in MuPDF? | 07:01.33 |
| Robin_Watts | shah: Anything is possible with suitable programming. | 08:00.47 |
| | There is no inbuilt support in MuPDF for it, but you can annotate a PDF by drawing on top of it. | 08:01.20 |
| | All you need is to make suitable device calls and you can draw anything that a standard PDF could draw. | 08:01.55 |
| Shah | Will I get Android SDK's API documentation support for Commercial license? | 09:28.31 |
| | ? | 10:29.24 |
| sebras | Shah: there is no API documentation that we only give to commercial customers. depending on the commercial agreement it may include support though. | 10:35.39 |
| Shah | ok thank you | 10:48.06 |
| | I will discuss with my business team | 10:48.19 |
| sebras | ator: LGTM "Update scripts to python3 with "2to3"." | 14:21.00 |
| | ator: Re: +pdf_version(fz_context *ctx, pdf_document *doc)" | 14:22.01 |
| | argh! | 14:22.03 |
| | ator: Re: "Bug 701559 (1/2): Load Root/Version on the fly." | 14:22.11 |
| | I'm confused. is doc->version supposed to be the version we read from the %%PDF-%d.%d header and the return value from pdf_version() might be the same, unless it is overridden by /Root/Version ? | 14:24.46 |
| | we had a numerical comparison before, so we took the latest version we found. | 14:25.29 |
| ator | sebras: doc->version holds the one loaded from the file header (%PDF-1.7 or whatnot) | 14:35.52 |
| | and Root/Version may override that. I don't do a numeric check, but changed all accesses of doc->version to pdf_version() | 14:36.10 |
| sebras | ator: I was rather suprised when I ran ./build/debug/mutool show -p password ./issue1144.pdf Root/PageLabels/Nums/2/P and it showed () | 22:28.59 |
| | I debugged the code and realized that AES has some 16 byte iv-vector followed by 16 byte of encrypted data. after initializing our AES decoder with the iv vector we throw it away and decrypt the remaining 16 bytes. | 22:30.37 |
| | those 16 bytes end up stating that there are no less than 16 bytes of padding, which means that we also throw away all the 16 decrypted bytes. | 22:31.05 |
| | therefore we end up with an empty string. | 22:31.12 |
| | table 8.10 on page 595 of pdfref17.pdf at the last paragraph describing the /S key states that /P may be empty of missing (not explicitly mentioned for /P itself) | 22:32.41 |
| | so now we can decode this properly. | 22:32.50 |
| | what tamir would need besides this is probably some kind of function char *pdf_get_page_label(fz_context *ctx, pdf_document *doc, int page) where page is the page index 0 - N-1 and the returned string is the formatted page label that needs to be freed with fz_free()...? | 22:34.29 |
| | I wonder how page labels handle RTL languages?! | 22:35.05 |
| | <<<Back 1 day (to 2019/09/09) | Forward 1 day (to 2019/09/11)>>> | |
Log of #mupdf at irc.freenode.net.