| | <<<Back 1 day (to 2018/03/04) | 20180305 |
| sebras | fredross-perry: I believe calling Page.destroy() multiple time would be safe. the first time it will call Page_Finalize() in the JNI code which will drop the underlying page, next it will set pointer to 0 in the Java code. The second time it it called the JNI code will look for the pointer value and if it is not set, Page_Finalize() will return. | 03:35.16 |
| | fredross-perry: if the two calls to Page.finalize() happen quickly enough there seems to be a gap during which Page_finalize() might call fz_drop_page() twice though. | 03:39.00 |
| | fresross-perry: ehm.. make that two calls to Page.destroy(). :) | 03:39.52 |
| | fredross-perry: consider the case where Page.destroy() for the first call reaches Page_finalize() and it has just returned from fz_drop_page() but not returned yet. at this point a second call to Page.destroy() appears, calls into Page_finalize() which retrieves the pointer variable, still not set to 0 by the java code in the first call. then the second call proceeds to call fz_drop_page() again. that is an issue. | 03:42.17 |
| | fredross-perry: perhaps Page_finalize() should be changed so that it starts by first getting the pointer variable (for later use when calling fz_drop_page()), and then immediately sets the pointer variable 0. | 03:44.25 |
| | fredross-perry: that way there shouldn't be any gap during which two calls to fz_drop_page() might happen. | 03:44.45 |
| | where the second call has a stale pointer value. | 03:44.56 |
| | fredross-perry: this would of course only happen in a multithreaded environment where the page object is accessed by multiple threads simultaneously. is that the case in you code? | 04:04.54 |
| | I'm starting to think that my proposal wouldn't fix this case 100% either. we'd need for the finalize method to synchronize on the object itself I think. | 04:06.02 |
| divagante | Hi people... excuse me, I'd like to know how I can read a pdf from console. Try mupdf without success, also in other places they say that it is possible with evince but it doesn't work for me either. | 13:31.07 |
| tor8 | divagante: what do you mean "from console"? | 13:36.08 |
| divagante | terminal! | 13:36.30 |
| | no Xs.. | 13:36.37 |
| tor8 | if you just want to get the text of a pdf to show in something like 'less' or a pager, then "mutool draw -Ftext input.pdf" will convert to ASCII text | 13:37.01 |
| divagante | oh.. this is the only solution? transforms pdf? | 13:38.03 |
| tor8 | PDF is a graphic file format, it's kind of hard to display that in a terminal | 13:38.30 |
| divagante | for all this code... mmm.. | 13:39.04 |
| tor8 | you could take our library, use the text extraction functions, and write a curses based text-only viewer if you're crafty | 13:39.50 |
| divagante | I just wanted to save battery power on an old netbook when I'm traveling. | 13:40.21 |
| | jeje. | 13:42.28 |
| | tor8: Well, thank you very much. | 13:43.24 |
| malc_ | tor8: in the days of yore mupdf would fallback to pdf for filenames that didn't end with a known extension, can this somehow be emulated with the new register document machinery? | 13:56.07 |
| n35xdxb0 | everytime i scroll down a page, in mupdf, and start reading the new page, of its own accord, mupdf starts automatically transitioning down to new pages. like some sort of presentation mode. i keep pressing P to deactivate it. but then scroll a new page, and it happens again! anyone know what's going on? | 16:24.08 |
| | ok sorry, my mistake. there's a difference between p and P, misread the manpage. it's sorted now | 16:26.52 |
| | on my terminal emulator, p and P look very similar | 16:28.03 |
| | Forward 1 day (to 2018/03/06)>>> | |
Log of #mupdf at irc.freenode.net.