| <<<Back 1 day (to 2020/01/21) | Fwd 1 day (to 2020/01/23)>>> | 20200122 |
patanga | is there a way to read several pdfs one after the other , opening them with "mupdf 1.pdf 2.pdf"? | 03:28.07 |
openbsdtai123 | what he wants with xdotool? | 06:33.16 |
| sebras: would it be possible to add a getchar() non-blocking directly while displaying the PDF (on X11)? | 06:34.31 |
| See library termios. | 06:34.56 |
| Please find an example where your getchar() will allow you to have full controll of your displaying void. It is actually a very tiny little addon. | 06:40.10 |
| ( please find here the link ex: https://termbin.com/2jvb ) | 06:41.11 |
sebras | patanga: no, that's not something supported by mupdf-x11 or mupdf-gl. | 07:10.11 |
nmpr | I'm interested in knowing more about MuJS and looking through the source code, but has anyone ever thought of creating a typescript interpreter (like Lua or AngelScript) in c/cpp? | 07:16.52 |
sebras | openbsdtai123: this is for bash, but you can probably convert it to whatever shell you are using in bsd. start one instance of mupdf with & and then run this script. https://pastebin.com/raw/5v90czqB | 07:18.32 |
| nmpr: since the topic of this channel isn't javascript in general (or typescript) you are unlikely to get good answers. mujs was developed to satisfy the requirement about ecmascript support by the PDF standard and not wanting to add yet another external library dependency to MuPDF. | 07:20.49 |
nmpr | sebras: good to know. thanks! | 07:21.44 |
openbsdtai123 | the mupdf will be started by the terminal or system, getchar() is always there. | 07:22.32 |
| Who is the main author of mupdf so that I contact him? | 07:24.02 |
sebras | openbsdtai123: ator. | 07:25.36 |
openbsdtai123 | strange... | 07:25.49 |
sebras | openbsdtai123: why? | 07:25.58 |
openbsdtai123 | This addon is easy, possible to be made. | 07:27.58 |
sebras | openbsdtai123: just because it is possibel and even easy doesn't mean that its desirable. did you read the concerns he mentioned? | 07:29.06 |
| openbsdtai123: also he pointed you to a solution that works today and I just sent you a working script doing what you want. | 07:29.56 |
| accomplishing the same thing in a different way. | 07:30.14 |
openbsdtai123 | I will try to add it on weekend... I give you feedbacks and code, as soon as possible. | 07:30.51 |
sebras | openbsdtai123: you need to convince ator that taking that code into mainline mupdf is worth it. until you do those patches are unlikely to be merged. | 07:31.37 |
openbsdtai123 | Well, it ator does not see the necessity, it is not necessary to have it, because he is the main author. | 07:32.32 |
sebras | ator: I did review "Fix problem with annotation positioning." but I can't say I understand it. | 09:33.37 |
| ator: I'm suspecting that w and h becomes some expansion factor and that we need to convert the bbox thing to the right coordinate frame. | 09:34.11 |
| there are no programming mistakes in it at least. :) | 09:34.26 |
| ator: LGTM "Bug 701185: Use safe fz_format_output_path function to format" | 09:47.21 |
| ator: LGTM "Bug 701754: Check 'uniXXXX' glyph name length to avoid false matches." | 09:50.34 |
| ator: LGTM "Bug 701977: Workaround for bug 57519 in FreeType." | 09:51.00 |
| ator: Re: "gl: Add -T option to print a script to replicate the user actions." | 09:52.14 |
| in do_widget_canvas() there's an index assigment requesting some whitespace. | 10:02.50 |
| ator: one thing I have _not_ checked is if this covers _all_ actions that should be traced. I assume we will not know that until later. | 10:03.55 |
ator | sebras: yeah. I guess we'll find out if/when we start using it | 10:06.56 |
sebras | ator: LGTM "gl: Clean up annotation UI." | 10:07.44 |
| ator: I think that's all of tor/master? | 10:07.49 |
ator | the signing/verifying signatures may not be fully traced | 10:07.51 |
| sebras: it is, thanks! | 10:07.55 |
sebras | ator: will you do the honors on sebras/untar? | 10:08.09 |
ator | sebras: LGTM (looked at them before) | 10:08.44 |
sebras | ator: oh, sorry. I forgot to push them last time then. | 10:10.59 |
ator | I may not have said LGTM, but I remember looking them over :) | 10:14.59 |
sebras | ator: nvm, they are pushed now! :) | 10:17.05 |
sh4rm4^bnc | sebras, | 10:27.18 |
| <sh4rm4^bnc> hello, the following commit breaks build with libressl: https://github.com/ArtifexSoftware/mupdf/commit/55cf67158b926589bee4ea2421b4acc46e6f9844 . i'm getting undef'd references to PKCS12_SAFEBAG_get0_safes and PKCS12_SAFEBAG_get0_p8inf | 10:27.20 |
| <sh4rm4^bnc> (this manifests in mupdf 1.16+) | 10:27.20 |
sebras | sh4rm4^bnc: ok, so I commited that change, but I didn't write it, paulgardiner did. I don't use libressl so I don't even know how to fix this. | 10:33.01 |
avih | ator: in mujs Object.keys(Error("foo")) is ["message", "stackTrace"], but in firefox it's []. should they be enumerable? | 11:56.17 |
| (also, do you plan to fix js_isarrayindex?) | 11:56.43 |
ator | avih: yes, see commit on mujs:tor/master if that works for you | 14:19.25 |
avih | ator: sorry, my vps went down seconds after you posted. | 18:02.25 |
| ator: the commit looks good, but i didn't have a test case - you maybe did. however, i noticed a possibly related issue (still with this commit too): x = new String("x"); x["00"]=1; Object.keys(x) returns ["0"] instead of ["0", "00"] | 18:04.07 |
| ator: also, Object.keys(function(){}) returns ["prototype"] but it should return an empty array. like stackTrace and message, prototype is also not enumerable in firefox | 18:05.42 |
| ator: i stand corrected. the new commit seems to fix the "00" key with new String(..) | 18:33.14 |
sebras | sh4rm4^bnc: do you mind testing out this commit and see if helps you with libressl http://git.ghostscript.com/?p=user/sebras/mupdf.git;a=commitdiff;h=6a924c89d6bb633f3101b6632bbb4e2f81269267 | 19:45.50 |
| sh4rm4^bnc: that would help a lot, since I've been fighting to get VirtualBox running and then switching to virt-manager only to run out of disk space for faaaar to long tonight. | 19:46.25 |
| sh4rm4^bnc: I tried to install gentoo to test it, but ran out of disk space. :( | 19:47.09 |
| sh4rm4^bnc: I was inspired by this patch in gentoo: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/mupdf/files/mupdf-1.14-libressl.patch | 19:47.18 |
sh4rm4^bnc | sebras, nice, thanks! works with libressl 2.7.x and 2.9.x (not tested 3.0.x yet) | 20:45.58 |
| cool, even 3.0.2 builds | 20:58.33 |
sebras | sh4rm4^bnc: excellent. I'll test it a bit more on my end and see to it that it gets in. | 21:02.30 |
sh4rm4^bnc | great, thanks again! | 21:04.23 |
sebras | sh4rm4^bnc: we don't test with libressl, but if it is cheap enough to keep it working we'll do so. if you come across more issues in the future, please report them here or on bugs.ghostscript.com | 21:04.25 |
sh4rm4^bnc | alright | 21:04.38 |
| btw a similar PR i filed: https://gitlab.com/openconnect/openconnect/merge_requests/65 | 21:05.38 |
| imo optimal solution would be to check at configure time "whether PKCS12_SAFEBAG_get0_p8inf is exposed" | 21:06.17 |
sebras | sh4rm4^bnc: mupdf does not use autotools, so configure is not an option. | 21:06.58 |
sh4rm4^bnc | i'm aware | 21:07.06 |
sebras | sh4rm4^bnc: even if pkg-config libcrypt could help I think the idea is that libressl should be a drop-in replacement for openssl. | 21:08.11 |
| sh4rm4^bnc: so we might as well just test it using their VERSION define. | 21:08.24 |
sh4rm4^bnc | the nasty bit here is that openssl deliberately broke API (and i suspect it was to mess with libressl adoption) | 21:09.16 |
| the only solution that really helps (unless libressl devs can be convinced to add stuff they consider insecure back) is to check for functionality :/ | 21:10.36 |
| anyway, the fix seems good enough for the time being | 21:11.08 |
| it would actually be great if pkg-config could do configure-style checks... | 21:12.22 |
sebras | HenryStiles: sh4rm4^bnc: these functions are accessor functions for an object. if libressl thinks it is not possible to patch these few functions to their standards then I'd be surprised. | 21:12.59 |
| sh4rm4^bnc: why merge autoconf and pkg-config though? what would that solve that the two tools combined doesn't solve? | 21:13.53 |
sh4rm4^bnc | right. i'll raise the specific issue in #libressl to make developers aware | 21:14.03 |
sebras | sh4rm4^bnc: (given that most software uses autotools, albeit not mupdf) | 21:14.04 |
| sh4rm4^bnc: if the grievances between the two projects are causing other projects issues, then that's no good. | 21:14.52 |
sh4rm4^bnc | well you could write stuff like CPPFLAGS += `pkg-config --checkfunc SSL_foo HAVE_foo` | 21:15.06 |
| directly in your Makefile, as opposed to running a script | 21:15.39 |
sebras | sh4rm4^bnc: yes, but the question is if that is better in some way. :) anyway, too late to debate shell scripts for me. I need to head to bed. thanks for doing testing for us! | 21:17.02 |
sh4rm4^bnc | thanks for the fix! | 21:17.16 |
| <<<Back 1 day (to 2020/01/21) | Forward 1 day (to 2020/01/23)>>> | |