| | <<<Back 1 day (to 2018/01/03) | 20180104 |
| Arno | Hi - happy new year ! | 08:03.33 |
| | A question: There are now 3 muPDF in appstore. My impression is, that the mini is slower/gets slower - which is not as expected. Though the smaller the app, the more RAM for the pdf itself? | 08:06.54 |
| Robin_Watts | Arno: The original mupdf app used a horrible hacked together JNI layer that was just enough to do what it needed. | 11:30.08 |
| | and consequently it's hard for people to tweak the app without having to change that code. | 11:30.52 |
| | We now have a nice reflection of the MuPDF libraries C API in java. | 11:31.13 |
| | so the new apps use that. | 11:31.22 |
| | They are much easier to tweak/maintain. | 11:31.35 |
| tor8 | Arno: the "MuPDF viewer" app is the best app for users if you don't need to annotate PDFs | 11:32.18 |
| Robin_Watts | The 'mini' app in particular is, AIUI, a rewrite of the app from the ground up using that java API. | 11:32.31 |
| tor8 | Arno: the "MuPDF mini" is a better example for developers to customize or build upon, using the new JNI layer that Robin jsut mentioned in a much easier manner | 11:32.52 |
| | but it does not pre-load pages in the background (that the other, more complicated apps do) so can appear a bit slower | 11:33.20 |
| | mike1: "mutool show input.pdf grep" will show all objects (without the content streams), one object per line, if that's easier for scripts to handle | 11:43.36 |
| | mike1: I use the output of that to grep for certain objects, for example | 11:43.55 |
| | mike1: if you want to do fancier stuff, do take a look at "mutool run". docs are here: https://mupdf.com/docs/manual-mutool-run.html | 11:45.12 |
| Arno | Thanks for explanation. So only the mini doesn't preload? I have to check it again. My impression was, that it becomes slower (as for a memory leak). But I wan't spread rumours ;) | 13:38.53 |
| | In fact I just need an viewer, that is able to do page fit or width-fit - so this should be fine. But again, the old app seems to be more responsive. As I have really old hardware with HiRes Screen, this matters . | 13:40.22 |
| paulgardiner | Robin_Watts, tor8: when deriving an fz_stream from an fz_output, should we arrange that the fz_stream holds a reference to the fz_output? In the file case, fz_drop_output closes the file. | 13:40.43 |
| Arno | Sorry I am new to irc, forget to adress @tor8 and @Robin_Watts | 13:41.39 |
| tor8 | paulgardiner: I'd arrange it so the 'borrowed' fz_stream doesn't close the FILE | 13:43.38 |
| paulgardiner | The case that I was mulling over was if the a stream was derived from an output and then the output was dropped. | 13:45.18 |
| | dropped before one had finished with the stream that is. | 13:45.48 |
| | I don't intend to do that in my own usage, but should we ensure it would work. | 13:47.10 |
| tor8 | I'd say don't do that... :) | 13:47.16 |
| | I would hope that we could keep this function private and not expose it to the public API | 13:47.46 |
| paulgardiner | It may be hard to completely hide it. An additional entry in the output structures list of function pointers is needed, I believe. | 13:49.55 |
| tor8 | paulgardiner: the probelm is that fz_output is not reference counted | 13:50.35 |
| | an output should only have one user, anything else is asking for trouble | 13:50.50 |
| paulgardiner | :-) I think that decides it then. | 13:50.50 |
| tor8 | and I'd be somewhat reluctant to add a reference count, since it goes against how it should be used | 13:51.19 |
| paulgardiner | No that's fine. | 13:51.29 |
| | I have no need for it. I was just asking because I was thinking of this as being public and wanted the cleanest behaviour (plus I hadn't noticed that outputs weren't ref counted) | 13:52.53 |
| | Not sure I can avoid changing the definition of fz_output_s | 13:55.18 |
| Robin_Watts | You will absolutely need to change fz_output_s to have a new function pointer in it. | 13:55.55 |
| | I believe this SHOULD be in the public API. | 13:56.53 |
| paulgardiner | So should I do that and call it directly in the signature code to avoid adding a new method? | 13:56.57 |
| Robin_Watts | but the rules should say "If you get a stream, you must not use the output again until the stream is dropped. | 13:57.32 |
| | " | 13:57.36 |
| | right. got to go climb a ladder to get the lights down. in high winds. should be fun. | 13:58.17 |
| sebras | when is this new hey_fz_output_give_me_a_fz_stream_so_I_can_read_your_data() going to be called? after writing the entire file and flushing the fz_output? | 14:02.20 |
| avih | tor8: hey, i just noticed that your mujs github page points to http://dev.mujs.com/ , which appears to 404 | 14:09.35 |
| | +be | 14:09.44 |
| tor8 | oh ffs. | 14:09.58 |
| sebras | :) | 14:10.17 |
| paulgardiner | sebras: in between outputting the document and writing the digest to a section of that document | 14:10.17 |
| sebras | paulgardiner: ok, but first the entire file (including that after the digest) is written with 000000 or something there the digest will appear later, right? | 14:11.08 |
| | paulgardiner: and then this magic function is called. | 14:11.15 |
| paulgardiner | yep | 14:12.04 |
| sebras | paulgardiner: since I assume FILE * might be reused and it contains a buffer inside I think these functions all need to be excuted by the same thread. in the same way when we say that only a single thread may read the document file. | 14:12.27 |
| paulgardiner | Yes absolutely | 14:13.12 |
| sebras | paulgardiner: I'm not sure whether freopen would make sense..? | 14:13.28 |
| | ignore me. | 14:14.22 |
| paulgardiner | I'm falling towards tor's "just don't do that" approach to the ouput being closed while the stream is still in use | 14:15.03 |
| sebras | paulgardiner: one way would be for the fz_output to know about all fz_streams it has created and when they are closed. so fz_close_output() throws if there are any fz_streams still open. | 14:20.05 |
| | perhaps that is not worth it though. | 14:20.18 |
| paulgardiner | Yeah, I think keep it simple | 14:21.10 |
| | Forward 1 day (to 2018/01/05)>>> | |
Log of #mupdf at irc.freenode.net.