| | <<<Back 1 day (to 2018/01/07) | 20180108 |
| sebras | mcfl: if you are in mupdf-gl press 'I' and if you are in mupdf-x11 press 'i', this will invert the entire document, including images though. | 11:28.25 |
| | mcfl: as for copying text, you can right click in both mupdf-gl and mpudf-x11 to copy text and it should end up either in your PRIMARY or CLIPBOARD selection. | 11:31.07 |
| | mcfl: I hope this helps. | 11:31.12 |
| kens | Morning sebras, Happy New Year | 11:31.28 |
| sebras | kens: morning! happy new year to you (and the family) too! :) | 11:32.32 |
| mcfl | sebras: 'I' works great - thank you! I can't get the right-click to work in mupdf-gl, though - it doesn't seem to do anything at all, no visual indications, nothing in the clipboard (at least nothing pastes to other apps) | 12:17.00 |
| sebras | mcfl: in mupdf-gl you should be able to right-click-drag to highlight text that will automagically be copied. | 12:17.55 |
| tor8 | mcfl: if you're using the newest mupdf-gl, it only highlights actual text it finds on the page | 12:19.32 |
| | if it's not working as it should on your particular document, could you open a bug and attach the file so we can investigate why not? | 12:19.52 |
| mcfl | sebras, tor8: ok, duh, senior moment - it would help to drag while right-clicking - it's working perfectly! Thank you both! | 12:24.02 |
| sebras | mcfl: :) I'm happy to hear that. | 12:24.49 |
| paulgardiner | Seeing weird behaviour when attempting to sign a document via fz_stream and fz_output. The byte-range info and the digest are ending up added to the end of the document. It is as though _fseeki64 affects only the next read not the next write. | 13:11.31 |
| Robin_Watts | Urm... | 13:14.34 |
| | So you're getting a new fz_stream from the fz_output. | 13:14.54 |
| | How is that fz_stream constructed? | 13:15.04 |
| paulgardiner | Just using the same FILE ptr | 13:19.01 |
| Robin_Watts | ok, so stop it before the fz_seek_output in the debugger. | 13:19.49 |
| | Then Ctrl-Alt-Q and ftell(FILE) to see where you are. | 13:20.06 |
| | Then let it do the fz_seek_ouput, and Ctrl-Alt-Q and do the same again. | 13:20.18 |
| | I think you're asking for problems though, frankly. | 13:20.52 |
| | I thought we'd agreed that the idea was that we'd get the stream, do the md5, release the stream, THEN continue writing. | 13:21.18 |
| | i.e. we wouldn't interleave use of the stream and the output. | 13:21.44 |
| paulgardiner | I think I am doing that | 13:21.46 |
| Robin_Watts | Not according to my reading of the patch on your git repo. | 13:22.08 |
| | You get the stream, then loop around the incremental sections. | 13:22.22 |
| | For each section you read shit, then write shit. | 13:22.40 |
| paulgardiner | Maybe not exactly, but it's the writing that's being problematic, which is unbuffered outside the FILE | 13:22.47 |
| Robin_Watts | After the loop you drop the stream. | 13:22.48 |
| | paulgardiner: As I say, I'd ftell in the debugger to see whether the call is having any effect. | 13:24.12 |
| | but the code looks wrongly structured to me. | 13:24.39 |
| | (maybe it should be Ok in this instance, but it's wrong long term) | 13:24.57 |
| paulgardiner | What's the problem you envisage? | 13:25.26 |
| Robin_Watts | exactly what I described above. | 13:26.00 |
| | The output shouldn't be used at all while the stream exists. | 13:26.32 |
| | (It may not explain this problem, but it's not what I expect long term, cos it places additional constraints on the buffering we can do to outputs etc.) | 13:27.07 |
| paulgardiner | Oh okay. I was in earlier version bracketing every read with getting a stream and then dropping that. I can easily go back to that. | 13:28.35 |
| | ftell reports the seek is working and adding a flush after the write shows that it is the next write that puts data at the end of the file although the seek position is well within it. | 13:48.30 |
| | Very odd. | 13:48.40 |
| | Can it be to do with opening for append?! | 13:49.08 |
| sebras | paulgardiner: yes. | 13:50.51 |
| | from http://pubs.opengroup.org/onlinepubs/9699919799/ | 13:50.56 |
| | Opening a file with append mode (a as the first character in the mode argument) shall cause all subsequent writes to the file to be forced to the then current end-of-file, regardless of intervening calls to fseek(). | 13:51.00 |
| paulgardiner | Ha ha | 13:51.30 |
| tor8 | paulgardiner: so I guess that TODO item to rewrite it to not use fopen append moved up the queue :) | 13:51.45 |
| paulgardiner | So I can just open and seek to the end instead and all willbe well | 13:51.49 |
| | tor8: not quite, but it is certainly in the queue | 13:52.32 |
| | I did not know that about append access (stating the obvious) | 13:52.52 |
| | I hadn't understood why we were using append access. It seems that, even if we seek to the end of the existing file, without append access, we end up overwriting it. Don't know why as yet. | 15:13.52 |
| tor8 | paulgardiner: you need to open with "w+" or something like that, in order to not truncate it when you open for writing | 15:17.16 |
| | sorry, "r+" | 15:17.59 |
| paulgardiner | I'm already doing so because of wishing to derive a stream from the output, but yeah that would be why we were using append I guess | 15:18.30 |
| | No, silly me. Was using w+ | 15:19.44 |
| | Whoop! Signing is back working again at last, albeit still currently hardwired to openssl. | 15:21.40 |
| Robin_Watts | paulgardiner: Nice. | 15:22.44 |
| paulgardiner | Robin_Watts: I still have to tidy up the use of streams in the way you pointed out earlier, but that's trivial I think. | 15:23.24 |
| Robin_Watts | yeah, didn't look huge. | 15:23.34 |
| | with the note that you have to allow for proper closing of the stream in the event it throws an exception mid write. | 15:23.56 |
| paulgardiner | tor8: I assume your request wasn't so much to stop using append as to not require the app to copy the input to the output before incrementally saving. When I get to that, can I assume that the input and output are different objects/files? | 15:26.01 |
| | I mean assume that we never save directly back to the original file, at least in the incremental case. | 15:26.43 |
| tor8 | correct. we should take care not to modify/delete the old file until we're certain the new file has been created correctly. | 15:37.10 |
| paulgardiner | Great. | 15:37.44 |
| | Forward 1 day (to 2018/01/09)>>> | |
Log of #mupdf at irc.freenode.net.