| <<<Back 1 day (to 2016/07/16) | 20160717 |
sebras | Robin_Watts: fredross-perry: a number of JNI-related commits on sebras/master | 09:19.08 |
| I spoke with tor8 and he wanted to retain Buffer in the JNI-interface, but add convenience InputStream/OutputStream classes to interact with it. so that's what I did. | 09:20.01 |
| I also added convenience functions for being able to input Strings instead of Buffer when adding page contents or streams for pdf objects. | 09:20.36 |
| Finally I implemented the Link and Outline objects after being prompted by tor8. | 09:21.12 |
| the rest is just fallout from the exercises mentioned above. :) | 09:21.40 |
| oh, and of course it passes clusterpush | 09:21.53 |
_abc_ | Hello. I am running into a problem, "new" datasheets from many makers, after a certain date (~2014 or so), apparently depending on the adobe toolchain, cannot be visualized with the older okular kpdf etc viewers at all, requiring a password (?!). These are public ds's, nothing special about them. Opening with gv works, but then the ps is rendered as graphics and cannot be searched. This is important, th | 10:04.15 |
| ese are 250+ page docs. | 10:04.21 |
| I tried to disasseble and reassemble one with pdf2ps followed by ps2pdf, this yields a pdf 2x the size of the original and also only graphics, can't select text in it or search. | 10:05.06 |
| Dumping only text from the pdf with pdf2ascii raises an error, the same one which occurs when using pdf2ps with -dlanguageLevel=3. Iow it's some sort of dumb protection (?!) designed to "prevent" use of free tools imo. | 10:06.17 |
| To check and prove: get http://ww1.microchip.com/downloads/en/DeviceDoc/40001586D.pdf (a pic mcu datasheet linked from http://www.microchip.com/wwwproducts/en/PIC16F1507), and run ps2ascii on it, or run pdf2ps -dlanguageLevel=3 on it | 10:07.03 |
| I'll be around on freenode usually once a day so I'll look in here if anyone has comments or a clue. Note this happens also with ds's from other makers, the only common point is new adobe tools apparently. | 10:07.43 |
| You can leave me a /message on freenode if I can't be found. Tia. | 10:07.59 |
| Googling for this brought up nothing | 10:08.13 |
| Additional note: the common point is not just adobe tools but also possibly Asian charset or rtl vestiges in the pdf/ps in the file | 10:09.42 |
| Not sure. | 10:09.50 |
| ps2ascii 2>&1 $pdf_above.pdf|less dumps the following interesting messages: | 10:11.38 |
| *** Warning: composite font characters dumped without decoding. | 10:11.41 |
| ... | 10:12.15 |
| Analog-to-Digital Converter (ADC) ^A<94> ^A <94> ^A <94>^A<94> ^A<94>Complementary Wave Generator (CWG)Error: /rangecheck in --.showstring1-- | 10:12.22 |
| (note the funny chars in there) | 10:12.29 |
| Operand stack: --nostringval-- --dict:10/19(L)-- 2564 5512 (\001\224) 54 false --nostringval-- 1 | 10:12.57 |
| So it seems to be related to the funny chars used in Asia, I think, which make my version of pdf tools choke | 10:13.20 |
| It also seems to be the same thing which makes the reader (older kpdf) think it needs a password to read it. | 10:13.40 |
Robin_Watts | _abc_: Go to bugs.ghostscript.com and open a bug. | 10:15.28 |
| Attach an example file. | 10:15.33 |
| Give the command lines you are running. | 10:15.41 |
| You are testing with the latest version of gs, right? | 10:15.50 |
_abc_ | Nope, older, this is what's installed in this older distribution | 10:16.12 |
| Just a second I'm not yet there | 10:16.21 |
Robin_Watts | Then our first request is to try it with the latest version. | 10:16.48 |
_abc_ | gs --version is 9.00 | 10:16.49 |
Robin_Watts | If it works in the latest version, then you should complain to your distro, not to us. | 10:17.18 |
_abc_ | Well I can't override the package system on my system to just test this. 9.00 is what's in slackware linux 14.0 . I agree with you but there must be another way to test. | 10:17.34 |
| Is there some known change from 9.00 to current which fixes bugs similar to what I am seeing please? | 10:17.59 |
Robin_Watts | _abc_: Yes you can. | 10:18.01 |
| Just download the sources from our git and build from there. | 10:18.12 |
_abc_ | That will clobber my current install which is in use for many other things. | 10:18.28 |
Robin_Watts | or a snapshot from our pages. | 10:18.29 |
| Yes, there are lots of changes. | 10:18.37 |
| _abc_: No it won't, as long as you don't install it. | 10:18.50 |
_abc_ | Ok, looking. I will also test on a Wheezy Debian 1st to see what version is there and if that works | 10:19.01 |
| Robin_Watts: so I can run it locally in test mode after building? | 10:19.12 |
Robin_Watts | Yes. | 10:19.19 |
_abc_ | Wow okay I had different plans for this Sunday but I'll try that. | 10:19.37 |
| 1st the debian machine. Be back in an hour or less. | 10:19.48 |
Robin_Watts | debian will be out of date too. | 10:20.24 |
| Save your time and just go straight to the latest source. | 10:20.35 |
_abc_ | Imo out of date is not relevant, works is relevant. Give it a few minutes, it is booting. | 10:21.06 |
| It's faster to check this than to get from git and build anyway so it's worth it. | 10:21.19 |
| Robin_Watts: is there a way to source filter pdf documents using a command line to remove or flag non ascii characters in the streams? | 10:23.34 |
| Robin_Watts: gs on Wheezy is 9.05 and yields the exact same error in the exact same location. | 10:26.50 |
| Robin_Watts: Since you seem to have the most recent version, can you get the pdf linked above and run ps2ascii 2>&1|less on it and see if your version handles that "error"? | 10:27.23 |
| http://ww1.microchip.com/downloads/en/DeviceDoc/40001586D.pdf 2.7MB | 10:27.41 |
| And, again, is there a way to filter pdf's to remove non ascii characters from them, i.e. from the streams and chunks inside them? | 10:28.32 |
Robin_Watts | What would you have it do? Just drop non 'ascii' chars? | 10:34.31 |
_abc_ | Apparently yes, so I want to try that. | 10:34.47 |
Robin_Watts | no, we can't do that. | 10:34.58 |
_abc_ | See the charcodes above, they are Chinese. Left over in the file probably when the Chinese version was made for that same ds. | 10:35.17 |
| Dropping meaning filtering once to check if I'm right. What I don't get is, how come the file renders properly graphically, and whether this is an intentional "mistake". | 10:36.02 |
| Looking at the latest version of gs | 10:36.10 |
| So latest is 9.09 | 10:36.32 |
| Nope, that's the outdated sourceforge one | 10:37.19 |
| http://downloads.ghostscript.com/public/old-gs-releases/ has nice releases BUT THE DATES ARE ALL TODAY'S. | 10:37.46 |
| They should reflect the real release date imnsho. | 10:37.56 |
| Well not today's but April 2016 | 10:38.09 |
| Why can't you run the test if you say you are on the latest version please Robin_Watts ? | 10:41.32 |
Robin_Watts | I am trying. | 10:41.51 |
| I am getting no output. | 10:42.13 |
| If I try to use twtwrite device I get garbage and then a SEGV on page23. | 10:43.23 |
| So I'd advise you to raise a bug as I said earlier. | 10:43.35 |
_abc_ | What version did you try please? | 10:43.54 |
Robin_Watts | git head. | 10:44.17 |
_abc_ | I assume that is more recent that 9.18 which I got as tbz2 | 10:44.34 |
| Latest in downloads. | 10:44.39 |
Robin_Watts | it is | 10:44.47 |
_abc_ | git is too bleeding edge for me, I'd prefer it to mostly work. | 10:44.57 |
| Okay, moving on to file a bug | 10:45.10 |
| http://bugs.ghostscript.com/docs/en/html/using.html this does not start well. 404 | 10:45.55 |
LadyElusive | git works rather well if you use it for version control and not all the newfangled features hipsterdevs want out of it | 10:53.12 |
_abc_ | I am really not into building packages I have my hands full with other things, just trying to use the system. | 10:54.39 |
| My compilers etc are not up to date, I will only build from source if that works around a known bug in a known way. | 10:55.11 |
LadyElusive | yeah, git really isn't a software release tool | 10:55.14 |
_abc_ | http://bugs.ghostscript.com/show_bug.cgi?id=692772 this may be related to what I see. | 10:55.31 |
| Filing the bug | 10:55.34 |
LadyElusive | that being said, building from source is usually superior | 10:55.55 |
_abc_ | http://bugs.ghostscript.com/show_bug.cgi?id=690608 another related one. This upgrade pressure is not welcome. I run 10 year old systems, no problems. | 10:56.20 |
LadyElusive | you can't reasonably expect software from 10 years ago to get along with modern software | 10:57.01 |
_abc_ | I don't really bother about it. The 'P' in PDF is for "portable". Been so since 1990s. Should stay that way. | 10:57.27 |
LadyElusive | i thought it was printable | 10:57.44 |
_abc_ | wrt http://bugs.ghostscript.com/show_bug.cgi?id=690608 ; pdf2ps -dlanguageLevel=3 should do the same as '-sDEVICE=ps2write' ? I think? Does it? | 10:58.54 |
| I tried that (-dlanguageLevel=3) | 10:59.05 |
| How do I run ps2ascii in the new built tree? It requires libs and such | 11:03.26 |
LadyElusive | which libs is it complaining about? | 11:05.23 |
_abc_ | It can't find it's ps2ascii.ps | 11:06.08 |
| Does the gs -I option help with this? | 11:06.49 |
| With 9.18 the error for ps2ascii is: "Error: /invalidaccess in --run--" ... "**** Error reading a content stream. The page may be incomplete.\n" ... Last OS error: No such file or directory | 11:10.40 |
| GPL Ghostscript 9.18: Unrecoverable error, exit code 1 | 11:10.45 |
| Filing the bug although I can see how I'll get the same answer as the one above 690608 | 11:11.01 |
| Imnsho artifex/developers should provide if not a filter then some reasonable error reporting mechanism such as "PDF file does not comply with standard: error 12345" explained in some txt file supplied or online. This would be the 3rd or so somewhat related bug filed. | 11:12.02 |
| http://bugs.ghostscript.com/show_bug.cgi?id=690608#c5 2009 posting refers to ps2pdf2 . I see no such thing on my systems. 9.18 certainly has no such thing | 11:18.31 |
Robin_Watts | Feel free to include a letter to that effect with your next licensing cheque. | 11:18.52 |
| I believe we are removing such scripts as they only cause problems. Call gs directly. | 11:19.34 |
_abc_ | Okay, not filing bug report. The posting I linked provided the solution. Confirm working ps2pdf $broken.pdf $working.pdf; size grows by ~10%, insignificant. Indexes work, text search and extraction work. | 11:22.08 |
| So ps2pdf without (2) at the end. | 11:22.18 |
| Imnsho someone should place this in the Howto right at the top "try redistilling pdf if errors like password request or similar appear, using 'ps2pdf $broken $good'" | 11:23.14 |
| I still don't know what the real error is. The fix works with 9.05 and 9.00 so it must work with all recent ones, including 9.18 which is latest tbz ball I got. | 11:23.45 |
| I assume the correct explanation is this http://bugs.ghostscript.com/show_bug.cgi?id=692772#c1 and some of the funny encoding includes may come from the fact that now many ds's are 1st written in Chinese using Asian charsets and then translated to English, possibly leaving funny markup and foreign invisible chars in the file. This is what I think it is, not what it is proven to be. I have no proof. | 11:25.42 |
| Fwiw the commands to test things inside the recently built tree are: | 11:26.49 |
| cd /tmp && wget ... ghostscript*.tbz2 && tar -xjf ghost* && (cd ghost* && ./configure && make) | 11:27.40 |
| then cp ghost*/lib/ps2pdf . ; edit ps2pdf: +IDIR="/tmp/ghostscript-9.18"; +GS_EXECUTABLE="${IDIR}/bin/gs"; +OPTIONS="$OPTIONS -I${IDIR}/lib" | 11:28.37 |
| After this, in /tmp, one can: ./ps2pdf $input $output | 11:28.52 |
| I note that bugzilla knows about 9.19 and master but the highest taball which can gotten from the d/l site seems to be 9.18 not 9.19 | 11:31.28 |
| Ok so 9.19 is in d/l but not in the 'old' d/l dir, but in the top. | 11:35.46 |
| i.e. github | 11:36.06 |
| Okay, done here. Thanks for the support, it was helpful Robin_Watts and LadyElusive | 11:38.13 |
sebras | Robin: you did see my messages in the log? | 13:16.26 |
Robin_Watts | I did not. | 13:17.40 |
sebras | Robin: if you are busy you can look later. | 13:20.26 |
Robin_Watts | sebras: fz_new_buffer_from_data can't take a const pointer. | 13:28.21 |
| cos people might then call buffer functions to extend the data. | 13:28.44 |
| If you want to do that, then we should have fz_new_buffer_from_const_data, and that should set a 'const' flag in the buffer to force any modifications to fail. | 13:29.31 |
sebras | Hm. Let me refresh my mind on why I neede that. | 13:29.58 |
| It was something with Buffer... | 13:30.06 |
Robin_Watts | buffer from a java string, I would guess? | 13:30.17 |
| And that's a bad way to cast away const. It gives lots of warnings. | 13:31.14 |
| The correct way is to use a union. | 13:31.21 |
| Yeah, you 'GetStringUTFChars' then pass that data to fz_new_buffer_from_data. | 13:34.58 |
| Urm... | 13:35.47 |
| fz_new_buffer_from_data takes the ownership of the data. | 13:36.00 |
| which, I think means that fz_drop_buffer will free it. | 13:36.12 |
| but it's not a malloced block. | 13:36.19 |
| so that will corrupt memory. | 13:36.23 |
| so: "JNI: When adding stream/page contents, accept String" will fail? | 13:36.50 |
sebras | Ah. Silly me iow. :/ | 13:37.00 |
| I didn't see it fail. Did I forget to test it..? | 13:37.28 |
Robin_Watts | I am seeing really weird diff displays in gitk that I've never seen before. | 13:38.31 |
| otherwise, looks great. | 13:41.30 |
Robin_Watts | is being called for food. | 13:41.40 |
sebras | Yeah I saw weird diffs in git diff too, but using --patience it worked better | 13:57.45 |
| Robin_Watts ok so the reason for const for shared data would be that the data can never change? | 14:10.54 |
Robin_Watts | sebras: If you're passing in a data buffer that a) is NOT to be freed, and b) is NOT to be extended, then you need some form of 'const' flag. | 14:23.48 |
| That would seem to be the case here. | 14:23.57 |
sebras | Robin_Watts: ok, I updated the patches. | 15:18.03 |
| Robin_Watts: and made sure to test addStreamString this time... d'oh. | 15:18.20 |
Robin_Watts | Testing is overrated. | 15:18.32 |
| sebras: I might be tempted to extend fz_buffer to have const ones. (as a future enhancement) | 15:20.29 |
| Ah! | 15:21.05 |
| fz_buffer already has a shared thing. | 15:21.18 |
| a 'shared' flag that says not to free it. | 15:21.30 |
| so your existing code was alright. | 15:21.47 |
| Damn, sorry. | 15:21.56 |
| New code looks fine. | 15:22.48 |
| I might be tempted to add a FIXME: there saying that if we had an fz_new_buffer_with_const_data, we could avoid the malloc/memcpy. | 15:23.25 |
sebras | np. I should have used the shared interface in order to make the old code correct. and this is probably for the better. | 15:23.31 |
| this way the data is actually owned by the page/whatever uses the buffer. | 15:23.48 |
| Robin_Watts: ok, so LGTM and I push? | 15:35.47 |
| Robin_Watts: the question is whether we actually can avoid the memcpy(). because the buffer belongs to the string then I can't believe that this is ok. | 15:36.28 |
_abc_ | Re. Wrt earlyer, rewriting broken pdfs with ps2pdf, in gs --version 9.05 and later, there is no error prinout when rewriting, with gs 9.02 I get: **** Warning: Short look-up table in the Indexed color space was padded with 0's. | 15:37.04 |
| **** This file had errors that were repaired or ignored. | 15:37.08 |
sebras | Robin_Watts: even if *is_copy == TRUE then this allocation is likely done by the JVM and may be freed at any time..? | 15:37.09 |
_abc_ | **** The file was produced by: | 15:37.10 |
| **** >>>> Acrobat Distiller 10.1.14 (Windows) <<<< | 15:37.13 |
| **** Please notify the author of the software that produced this | 15:37.15 |
| **** file that it does not conform to Adobe's published PDF | 15:37.18 |
| **** specification. | 15:37.20 |
| oops okay done | 15:37.23 |
sebras | _abc_: instead of pasting stuff it is usually smart to use pastebin.com :) | 15:37.38 |
_abc_ | ime that kind of warning should be produced by more modern ps2pdfs too, or not be suppressed by default. tia | 15:37.38 |
| sebras: I was hoping it would go on one line... | 15:37.47 |
Robin_Watts | sebras: Yes, lgtm, push away. | 15:37.54 |
sebras | _abc_: if you post too many messages the irc server might kick you out. | 15:37.56 |
_abc_ | I think irssi has rate limit. 10 lines should not lead to a kick. Thanks. | 15:38.19 |
sebras | _abc_: yeah, no problem. just want to help out so you avoid being kicked. :) | 15:38.22 |
Robin_Watts | We *could* avoid the memcpy in this case, because between the ClaimString and ReleaseString, the JVM can't move the buffer. | 15:38.24 |
| and the buffer doesn't persist beyond that time. | 15:38.47 |
sebras | Robin_Watts: ah, so I'd postpone the ReleaseString until Buffer_finalize, I see. | 15:39.08 |
_abc_ | JVM? You are adding java support to gs? | 15:39.10 |
sebras | _abc_: to mupdf. | 15:39.25 |
_abc_ | Please ignore me I'm just passing through | 15:39.28 |
Robin_Watts | _abc_: It is entirely possible that we only spot the errors in newer gs. | 15:40.14 |
| sebras: Urm... As far as I can see you fz_drop_buffer, THEN ReleaseString. | 15:40.58 |
| so you're fine. | 15:41.01 |
sebras | Robin_Watts: yes, but the ReleaseString is always. | 16:25.01 |
Robin_Watts | Which function are we talking about? PDFDocument_addStreamString ? | 16:25.46 |
sebras | Robin_Watts: so if fz_buffer keeps the pointer around and assumes that the data is there and then addStreamString() calles ReleaseString() then the data is gone. even if pdf_document did fz_keep_buffer(). the pointer itself is stale while the "object" is valid. | 16:25.51 |
| yes. | 16:25.56 |
Robin_Watts | Right, well, then the problem is that you're fz_drop_buffer'ing in the always clause then. | 16:26.25 |
sebras | Robin_Watts: but I should, right. because pdf_add_stream() calls fz_keep_buffer()... | 16:26.57 |
Robin_Watts | so it does. | 16:27.06 |
| Right, so your new code is fine because it memcpys, and your old code would indeed have been a problem, | 16:27.25 |
| Sorry. | 16:27.31 |
sebras | Robin_Watts: np. as long as we agree eventually. :) | 16:27.42 |
| Robin_Watts: I could probably postpone the ReleaseString until Buffer_finalize() though and save the memcpy. | 16:28.03 |
| Robin_Watts: but then again when the Java object is no longer references does that mean that the mupdf C-structures has stopped referencing the buffer too? | 16:29.10 |
| Robin_Watts: so I do think doing the memcpy() is the better option. | 16:29.30 |
Robin_Watts | sebras: No, AIUI, you should never hold java objects locked over JNI calls. | 16:29.43 |
| Or at least, it's bad form to. | 16:29.59 |
| So, yes, memcpy is bets. | 16:30.06 |
| best | 16:30.08 |
sebras | Robin_Watts: ok, so then there is no reason to add any FIXME either. the code has now been declared Perfect<tm> :) | 16:30.48 |
| Robin_Watts: in you PWG-output patch you check pixmap->n with 1, 3, 4... does pixmap->n no longer include alpha? | 16:49.37 |
Robin_Watts | pixmap->n includes alpha. That code assumes alpha == 0 | 17:00.29 |
| I think there is a test for that? | 17:00.32 |
| yeah, second if in the function. | 17:00.54 |
| So we have pixmap->n components, of which pixmap->alpha of them are alpha ones. | 17:01.19 |
sebras | yes of course. | 17:22.43 |
| nvm me. :) | 17:22.57 |
| Robin_Watts: d'oh. the identifier completion has bitten me again. trivial patch over at sebras/master. | 17:24.38 |
Robin_Watts | sebras: LGTM | 17:36.11 |
fredross-perry | sebras, you there? | 18:25.14 |
| anyway, with your latest sebras/master, I am getting JNI-relate errors in Link and Outline when I tryto build and run the new Android example. | 18:27.54 |
| Failed to get field for com/artifex/mupdf/fitz/Link pointer J | 18:27.55 |
| Failed to get field for com/artifex/mupdf/fitz/Outline pointer J | 18:28.07 |
| etc | 18:28.08 |
stevelitt | I wish there were a way to make mupdf display two pages at once, as if I were reading a real book. My new book is PDF format, 5" tall by 3" wide, for mobile device viewing. Those viewing it on a computer screen could easily fit two of those pages side by side. | 18:33.22 |
malc_ | stevelitt: there are plenty of viewers out there that can do multiple pages | 18:35.48 |
stevelitt | malc_ yes, but they don't have mupdf's speed, keyboardability, and ease. | 18:47.01 |
malc_ | stevelitt: some do | 18:47.43 |
stevelitt | I need to recommend a reader to my customers, and dual page would be a plus. | 18:47.48 |
malc_ | stevelitt: there's a mupdf backend for okular for instance | 18:48.17 |
stevelitt | malc_ which dual page capable viewers have mupdf's speed, keyboardability, and ease? | 18:48.38 |
| I can't in good conscience recommend anything KDE to my customers. | 18:48.51 |
malc_ | stevelitt: mine | 18:49.31 |
| stevelitt: https://github.com/moosotc/llpp/ | 18:49.53 |
stevelitt | I'm downloading llpp now... | 18:51.44 |
malc_ | stevelitt: neat, shout if you'll need any help building it | 18:52.33 |
stevelitt | I'll take you up on that malc_. I want to compile it as a normal user. lldd% build.sh build doesen't work. Neeither does ./build.sh build. | 18:58.30 |
| I'm in the llpp-master directory, and ocaml is installed. | 18:58.56 |
malc_ | stevelitt: what does build.sh say? | 18:59.08 |
stevelitt | [slitt@mydesk llpp-master]$ ./build.sh build | 18:59.33 |
| bash: ./build.sh: Permission denied | 18:59.33 |
| [slitt@mydesk llpp-master]$ | 18:59.33 |
malc_ | erm... sh build.sh build | 18:59.43 |
stevelitt | ... | 18:59.51 |
| Error not finding gl.h. Hang on while I find out what I need to install... | 19:00.28 |
malc_ | stevelitt: that depends on your os/distribution.. mesa-devel, libgl-devel or something | 19:02.12 |
stevelitt | Neither of those, I'm still looking... | 19:07.12 |
malc_ | stevelitt: what system is that? | 19:08.17 |
stevelitt | Hang on, malc_, I'm making progress... | 19:13.22 |
| Void Linux. It turned out to be MesaLib-devel | 19:15.58 |
| I'm having to do an upgrade to download freetype-devel... | 19:16.38 |
| malc_, where is it expecting to find ft2build.h? | 19:23.29 |
| [slitt@mydesk llpp-master]$ ls -l /usr/include/freetype2/ft2build.h | 19:23.38 |
| -rw-r--r-- 1 root root 2383 Jul 14 12:16 /usr/include/freetype2/ft2build.h | 19:23.38 |
| meter -Wsign-compare -Wshadow -o build/link.o' -c ./link.c | 19:23.54 |
| ./link.c:46:22: fatal error: ft2build.h: No such file or directory | 19:23.54 |
| #include <ft2build.h> | 19:23.54 |
malc_ | stevelitt: you haven't followed BUILDING instructions, | 19:24.49 |
| i guess | 19:24.51 |
stevelitt | yeah, they're pretty obscure. | 19:25.20 |
malc_ | stevelitt: what exactly is obscure? | 19:25.57 |
| stevelitt: it might be more productive to take this conversation to privmsg, little to do with ghostscript after all | 19:27.04 |
stevelitt | Easy way: llpp% sh build.sh build -- what's llpp%? I did sh build.sh build and it couldn't find ft2build.h | 19:28.46 |
malc_ | stevelitt: llpp% is the directory with llpp's git checkout | 19:29.11 |
Robin_Watts | stevelitt: MuPDF is a portable C lib. The viewers are just thin wrappers built around it. | 20:34.22 |
| It'd be easy enough to do a multi-page viewer version. | 20:34.43 |
| malc_'s code is proof of that. | 20:34.54 |
malc_ | Robin_Watts: sumatrapdf uses mupdf, zathura and okular have mupdf backends so yeah | 20:40.41 |
| Forward 1 day (to 2016/07/18)>>> | |