| | <<<Back 1 day (to 2017/07/12) | 20170713 |
| malc_` | marrenarre: works here | 00:06.14 |
| marrenarre | malc_`: Youâre not noticing the same behaviour? | 00:06.31 |
| malc_` | marrenarre: au contraire | 00:06.50 |
| marrenarre | Linux/X? | 00:07.24 |
| malc_` | marrenarre: + i3 | 00:07.36 |
| marrenarre | Development version? | 00:07.43 |
| malc_` | marrenarre: yes | 00:08.00 |
| marrenarre | malc_`: So you first enable fullscreen via i3, and then you disable fullscreen via MuPDF, and it works perfectly? | 00:09.47 |
| malc_ | oh.. no | 00:09.57 |
| marrenarre | :P | 00:10.04 |
| | It works perfectly if you do both parts using the same method, but they donât work well together. | 00:10.22 |
| malc_ | marrenarre: and it's what it was made to do (looked at the source) | 00:10.25 |
| marrenarre | ? | 00:10.45 |
| malc_ | marrenarre: there simply isn't any code to watch for _NET_WM_STATE in mupdf so if you switch the fullscreen via WM, mupdf has no idea you've done so | 00:11.14 |
| | internally it still thinks it's in "normal" mode | 00:11.24 |
| marrenarre | Well of course. Thatâs the problem. | 00:11.32 |
| | I think it should watch for it and adjust accordingly. | 00:12.40 |
| malc_ | marrenarre: easier said than done :) | 00:12.54 |
| marrenarre | Why so? | 00:13.13 |
| malc_ | because one would need to hook property notify and given the asynchronous nature of x11 event delivery it still wouldn't work 100% of the time | 00:15.12 |
| marrenarre | Oh. I wish I knew more about X11. | 00:15.55 |
| | I mean it seems to me like it is handling the events synchronously, and anyway it is already in fullscreen by the time it would handle it. | 00:16.24 |
| mvrhel_laptop | Robin_Watts: So I just pushed a simple fix for the TextKnock page of the Altona file | 00:16.43 |
| | I think we are going to run into several of these types of issues as we push on. Luckily most should be this simple to fix | 00:17.06 |
| malc_ | marrenarre: consider yourself lucky not knowing more about x11 :) | 00:18.03 |
| marrenarre | Aww but I would like to make a window manager one day. :( | 00:18.22 |
| | How did you learn? | 00:18.38 |
| malc_ | marrenarre: by not using xlib/xcb and talking the protocol directly | 00:19.04 |
| marrenarre | But how did you learn to do that? | 00:19.15 |
| | (I read that people who do that are insane, by the way.) | 00:19.38 |
| malc_ | marrenarre: by reading the protocol specification | 00:19.39 |
| marrenarre | That sounds like the kind of thing thatâs really long. | 00:20.02 |
| malc_ | marrenarre: it's actually a lot easier than using xlib/xcb... | 00:20.06 |
| marrenarre | Oh okay cool. | 00:20.22 |
| malc_ | marrenarre: x11 protocol is a whole lot easier than one would imagine.. in fact Joe Armstrong wondered, in his PhD thesis, why people use those wrapper libraries, I decided to test his hunch that going for the protocol is easier, he was right, at least in my experience | 00:21.33 |
| marrenarre | Is this what you read: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html? | 00:21.54 |
| malc_ | yep | 00:22.11 |
| | there are some dark corners though... XKEYBOARD, GLX among them | 00:22.52 |
| marrenarre | Thatâs cool. Thanks for the info! | 00:23.05 |
| malc_ | np.. btw. just checked my own mupdf based application, the one that talks protocol directly, it appears i only get fullscreen toggle via WM right half of the time... sigh | 00:24.43 |
| marrenarre | Ah. | 00:26.16 |
| | Oh actually over half of that document is taken up by the appendices, the glossary, and the index. | 00:31.24 |
| malc_ | marrenarre: it's very simple indeed | 00:32.09 |
| marrenarre | I should definitely check it out some day. | 00:32.22 |
| malc_ | marrenarre: http://repo.or.cz/llpp.git/commitdiff/1ee4d62d5f1fafe16fef5229c16481da9fe30cb2 thanks i guess :) | 00:44.06 |
| marrenarre | malc_: Youâre welcomeâ¦?? | 00:46.44 |
| | Glad I could help I guess. :) | 00:47.01 |
| malc_ | marrenarre: without your invaluable input i would have never discovered this 'orrible omission... i rarely switch this thing to and out of fullscreen via i3 key bindings :) | 00:48.10 |
| marrenarre | Oh I see. Nice that you found it! | 00:52.12 |
| | Well, I should go now. Itâs 03.35 here in fact. | 01:35.23 |
| | Good night! | 01:35.36 |
| mvrhel_laptop | Robin_Watts: So two commits for you to look at. These fix the two issues that showed up on the clusterpush bmpcmp | 01:43.54 |
| Robin_Watts | tor8: So, michaels latest changes are on robinn/mvrhel_master | 10:24.00 |
| | I reckon they are good to go. | 10:24.07 |
| | The bmpcmp on my area at the moment is the results of -filter=ppmraw.72.0 with a threshold of 64. | 10:24.51 |
| tor8 | the X's are supposed to be invisible, right? | 10:51.01 |
| kens | In general, yes | 10:51.33 |
| Robin_Watts | tor8: yeah, so (barring edge effects), we are there. | 10:52.15 |
| tor8 | the edge effects look like sort of errors you get when blending with alpha using non-premul math | 10:53.20 |
| | and interpolation. | 10:53.29 |
| kens | Therte's something weird looking in test 47, page 7 | 10:55.37 |
| | bottom left corner, the second capital D is a strange colour | 10:55.57 |
| | page 15 some of the ovals are white, and shouldn't be | 10:56.46 |
| | actually some of them are gray and shouldn't be too | 10:57.11 |
| | Of course, they were wrong before too | 10:57.36 |
| | The whole left column seems to be incorrect | 10:58.01 |
| | Overall though, much improved | 10:58.49 |
| | The shadows in test 104 look like a regression, but I need to download the test file | 10:59.56 |
| Robin_Watts | kens: Thanks for those. I'll pass that on to mvrhel to look at before I push. | 11:00.14 |
| tor8 | Robin_Watts: so, if I'm reading this commit correct, we're holding ALL color values for CMYK inverted, not just the pixmap 0..255 byte values? | 11:00.27 |
| kens | I just checked 104, the shadows are wrong now, were OK before | 11:00.40 |
| Robin_Watts | tor8: yes. | 11:00.44 |
| | All values in a subtractive color space. | 11:00.53 |
| tor8 | instinctive gut reaction: eww! | 11:00.54 |
| Robin_Watts | tor8: I think it's neater than the alternative. | 11:01.15 |
| tor8 | I can't remember why I added the fz_ensure_additive function in the first place. I have some vague recollection that it was to do with alpha blending. | 11:02.21 |
| | but now I can't convince myself that the math wouldn't work out just fine if we never inverted them | 11:02.37 |
| | then again, my math is rusty | 11:02.54 |
| Robin_Watts | tor8: But are you happy with those commits on the whole? | 12:01.31 |
| | (robin/master has just been updated with my latest changes which build on top of michaels, to add spot color handling). | 12:02.09 |
| tor8 | on the whole, yes, but I wonder if we can keep the colors non-inverted | 12:09.24 |
| Robin_Watts | tor8: Feel free to try. | 12:59.30 |
| marrenarre | Hello again. I was here yesterday, talking about the fullscreen issue. The issue is that enabling fullscreen via e.g. a window manager is not noticed by mupdf so when you try to disable it in mupdf afterwards, mupdf tries to enable fullscreen even though you are already in fullscreen (because you did not enable fullscreen through mupdf) and thus nothing happens. | 13:30.35 |
| | tor8: I was told to ask you about it. | 13:35.26 |
| tor8 | marrenarre: yeah, fullscreen and x11 has historically been a bit of a mess | 13:36.17 |
| | are you using mupdf-x11 or mupdf-gl? | 13:36.30 |
| marrenarre | I tried the development version of each and they both had this problem. | 13:36.43 |
| tor8 | I'm not surprised. We don't listen to any particular WM message that we've been fullscreened. | 13:37.13 |
| | mupdf-gl uses GLFW | 13:38.30 |
| marrenarre | malc_ explained to me that it would be quite complicated to fix this due to the asynchronous nature of X11. | 13:38.41 |
| tor8 | mupdf-x11 sends a WM request to go fullscreen (NET_WM_STATE_FULLSCREEN) | 13:39.06 |
| | there might be a way to look at the window properties before asking to change state, but those window properties are not handled or set by all WMs | 13:40.15 |
| | it would be trivial, if only X11 had sent us a message that we've gone fullscreen and we could update our internal 'are we fullscreen' variable | 13:41.18 |
| | but as I recall it, there is no such message | 13:41.30 |
| | and that would only solve the bug in mupdf-x11 on x11, not for mupdf-gl | 13:42.13 |
| | marrenarre: are you in a position to build mupdf and test something for me? | 13:43.45 |
| | add a line printf("toggle_fullscreen %d\n", !!glfwGetWindowMonitor(window)); to the beginning of toggle_fullscreen() in platform/gl/gl-main.c and tell me what it prints when you've gone fullscreen in the wm and hit the fullscreen button in mupdf | 13:44.37 |
| | Robin_Watts: from my rudimentary experiments using the XPS and TIFF CMYK files with opacity it looks like things come out alpha composited correctly even when working in subtractive colorspaces | 13:59.07 |
| Robin_Watts | tor8: I've spent long enough getting this working that I'm not changing tack on a vague promise. | 14:00.50 |
| | It's not just plotting that's the issue, it's all the different blend modes too. | 14:01.14 |
| tor8 | Robin_Watts: of course! I want to get to the bottom of this. | 14:01.35 |
| marrenarre | tor8: Iâm cloning the repository ATM but itâs going very slowly for some reason. | 14:01.41 |
| Robin_Watts | If you want to take michaels branch and turn that into an equivalent that that doesn't need the inversion, then great! | 14:01.57 |
| marrenarre | Around 20 KiB/s. | 14:01.59 |
| tor8 | Robin_Watts: on tor/subtractive is a commit that nobbles the is_additive stuff that should let us plot with cmyk subtractive spaces | 14:02.05 |
| | in tests_private/xps/ms/Handcrafted/ImagePixelFormats.xps on page 9 there is a CMYK-alpha tiff that needs premultiplying | 14:02.34 |
| Robin_Watts | There is no is_additive in my current branch... | 14:02.49 |
| tor8 | Robin_Watts: I know, I just took origin/master (before your inversion commit) and experiment with that | 14:03.13 |
| Robin_Watts | right. | 14:03.25 |
| tor8 | mutool draw -o out.ps -c cmyk tests_private/xps/ms/Handcrafted/ImagePixelFormats.xps 9 | 14:03.26 |
| | looks identical whether I use -c cmyk or -c rgb when viewing the output with gs | 14:03.50 |
| | (and I've added a printf to fz_new_pixmap_with_data to ensure we create CMYK rendering buffers, and we do) | 14:04.34 |
| | and nobbling the fz_premultiply_pixmap call in load-tiff.c results in two different renders | 14:07.21 |
| marrenarre | tor8: toggle_fullscreen 0 | 14:15.31 |
| | toggle_fullscreen 1 | 14:15.31 |
| tor8 | marrenarre: and the first time you press it, you're already in fullscreen? | 14:15.49 |
| marrenarre | tor8: Yes. | 14:15.58 |
| tor8 | marrenarre: damn. won't be an easy fix then :( | 14:16.07 |
| | because GLFW doesn't know that it's gone fullscreen | 14:16.15 |
| | Robin_Watts: I will try to tweak your mvrhel_master branch to not use inversion, and see what diffs we get | 14:17.40 |
| Robin_Watts | tor8: cool. I'm neck deep in spots stuff at the moment, and desperately trying not to get distracted. | 14:18.04 |
| tor8 | Okay, I shall do this in silence then :) | 14:18.30 |
| marrenarre | tor8: Why doesnât it know that? Isnât it supposed to? | 14:19.58 |
| | What about this function: http://www.glfw.org/docs/3.0/group__window.html#gaeac25e64789974ccbe0811766bd91a16? | 14:21.57 |
| | Wait thatâs the same one. | 14:22.42 |
| | Is this a bug or something? The behaviour doesnât make sense given the description. | 14:23.06 |
| tor8 | marrenarre: I suspect it only knows the state of the window when it was created; any modifications by the WM aren't reflected. | 14:28.04 |
| Robin_Watts | boggles at fast_rgb_to_gray | 14:36.21 |
| | tor8: In commit a8a47bb3f2 you do rgb to gray by doing: | 14:39.31 |
| | d[0] = ((s[0]+1) * 77 + (s[1]+1) * 150 + (s[2]+1) * 28) >> 8; | 14:39.41 |
| | That's equivalently: | 14:39.57 |
| | d[0] = (s[0]*77 + s[1]*150 + s[2] * 28 + 255)>>8 | 14:40.21 |
| | Why the first form? | 14:40.48 |
| tor8 | Robin_Watts: I honestly can't remember | 14:47.11 |
| | it *might* be me trying to scale up to 0..256 math by ugly hacking it | 14:47.36 |
| Robin_Watts | The maths is correct (I just pencil and papered it to check). | 14:47.56 |
| | it correctly maps 0..255 -> 0..255 | 14:48.14 |
| | (we don't want to go to 0..256) | 14:48.21 |
| marrenarre | Oh well okay. Thatâs too bad. | 14:48.31 |
| tor8 | Robin_Watts: the +1 form dates back to at least 2004, commit ce1bf1ef28a160c48c287d302ab7795330806cf0 is the first one I can find | 14:53.26 |
| Robin_Watts | tor8: ah, well, no biggy. Was just wondering if there was some cunning reason I had missed. | 14:53.58 |
| tor8 | you could probably ask sebastian to dig through the old old old original mupdf cvs :) | 14:55.30 |
| | the one I copied bits from to start the current code | 14:55.41 |
| | I know he's kept a copy of that sitting around somewhere | 14:55.56 |
| Robin_Watts | tor8: And the odds of finding a reason in that are? :) | 14:56.19 |
| tor8 | probably less than ideal :) | 14:56.39 |
| Robin_Watts | It'll come down to a commit with a message like "Color conversions". | 14:56.44 |
| | :) | 14:56.47 |
| mvrhel_laptop | morning Robin_Watts. So there were a few more files that were regressions? | 15:13.27 |
| Robin_Watts | mvrhel_laptop: Morning. | 15:13.35 |
| | Yeah, kens spotted a few. | 15:13.38 |
| | tor8 thinks he can maybe make this all work without inverting subtractive colors, so he's giving that a go. | 15:14.23 |
| mvrhel_laptop | ok I will look at those this morning | 15:14.29 |
| | Robin_Watts: ha | 15:14.31 |
| | maybe he can do the same with gs then? | 15:14.37 |
| | as it inverts all the subtractive colors before blending too | 15:14.51 |
| | I supposed if we had different blending equations for subtractive colors we could avoid doing the inversion | 15:17.12 |
| | But if we want to use the same equations then they are going to need to be inverted | 15:18.39 |
| | That is clear in the PDF spec | 15:18.44 |
| | tor8: ^^ | 15:20.40 |
| sebras | Robin_Watts: also that old cvs repo is not available to me atm. | 15:24.14 |
| Robin_Watts | mvrhel_laptop: Hmm. | 15:33.40 |
| | just pondering a problem. | 15:33.48 |
| | When I call pdf_page_separations, I want to get the list of separations on a page back. | 15:34.06 |
| | This list includes names, and equivalent colors. | 15:34.17 |
| | In order to get the equivalent colors, I was going to load the colorspace, and convert '1' to rgb and cmyk respectively. | 15:34.55 |
| | But I don't have the default_cs stuff in the pdf_page_separations calls. | 15:35.19 |
| mvrhel_laptop | hmm. That is unfortunate | 15:36.29 |
| Robin_Watts | Maybe the fz_separations structure should contain a list of fz_colorspace pointers? | 15:37.20 |
| mvrhel_laptop | It is definitely needed to get the correct color | 15:37.21 |
| Robin_Watts | That way I can generate the equivalent colors direct as required. | 15:37.50 |
| mvrhel_laptop | That would make sense | 15:37.51 |
| Robin_Watts | yeah, that's doable, I think. | 15:38.18 |
| mvrhel_laptop | I have the D chopped down. Need to eat breakfast before figuring this one out | 15:49.55 |
| | Robin_Watts: you there? | 16:45.36 |
| Robin_Watts | I am. | 16:45.42 |
| mvrhel_laptop | A performance question for you. I found the issue with the D color in the altona test. | 16:46.04 |
| | So when we have a non-isolated group we copy the backdrop to the new group | 16:46.32 |
| | but if the color space is different we need to do a color conversion. (Not doing the conversion is the source of the problem) | 16:47.05 |
| Robin_Watts | right. | 16:47.11 |
| mvrhel_laptop | right now we do a fz_copy_pixmap_rect | 16:47.20 |
| Robin_Watts | fz_clone_pixmap_area_with_different_seps is probably what you want. | 16:48.03 |
| mvrhel_laptop | It would be nice, when we need to do the conversion to just create a new pixmap the size of the bbox intersection and convert that | 16:48.04 |
| | is that an existing function? | 16:48.26 |
| Robin_Watts | wouldn't it :) | 16:48.28 |
| | mvrhel_laptop: It exists in my branch. | 16:48.37 |
| mvrhel_laptop | does it do what I just said above? | 16:49.06 |
| Robin_Watts | That's what I use to do the bits you hate. | 16:49.06 |
| mvrhel_laptop | I mean in terms of the interesection. I don't want to convert the whole backdrop | 16:49.37 |
| Robin_Watts | given a source pixmap, and an fz_irect, and a destination colorspace and set of separations it makes the appropriate clone. | 16:49.47 |
| | yeah, just the given area. | 16:50.00 |
| mvrhel_laptop | cool. | 16:50.10 |
| | so how should we do this? Should I pull that part into code? | 16:50.26 |
| | or do we wait on all of this | 16:50.44 |
| | and merge into one branch maybe? | 16:50.53 |
| Robin_Watts | mvrhel_laptop: I am fairly tempted to say we should push what we have, cos it's far more of a progression than a regression. | 16:51.24 |
| mvrhel_laptop | Robin_Watts: I agree. | 16:51.39 |
| Robin_Watts | Did you check out the SEGV? | 16:51.41 |
| mvrhel_laptop | oh let me do that now | 16:51.46 |
| | so that was tests_private/pdf/sumatra/1044_-_hidden_annotation_rendered.pdf.pgmraw? | 16:54.08 |
| Robin_Watts | yeah, that rings a bell. | 16:54.57 |
| | robin/master now looks to be in reasonable shape, I think. | 16:55.08 |
| mvrhel_laptop | great | 16:56.05 |
| | ha! The segv is caused by the fz_copy_pixmap_rect and the mismatch color spaces | 16:57.45 |
| | it ends up in the /* FIXME: Crap conversion */ section | 16:58.30 |
| | source is gray and destination is CMYK | 16:59.25 |
| | so, now what to do | 16:59.41 |
| | Robin_Watts: any suggestions? | 16:59.52 |
| | I could work on fixing the crap conversion.... | 17:00.00 |
| | or I could pull in your fz_clone_pixmap_area_with_different_seps | 17:00.39 |
| Robin_Watts | oh, urm... | 17:00.52 |
| | I dunno. | 17:01.36 |
| mvrhel_laptop | let me look at fz_clone_pixmap_area_with_different_seps | 17:01.52 |
| | which commit is that in? | 17:02.37 |
| Robin_Watts | mvrhel_laptop: best to just look at the tree on the final commit. | 17:03.30 |
| | http://git.ghostscript.com/?p=user/robin/mupdf.git;a=blob;f=source/fitz/separation.c;h=5baea132ff5b0197a623b9167ca1be3315ed3704;hb=d2ad809052f073b332c692759631ac585a7de009 | 17:04.13 |
| | line 228 onwards. | 17:04.17 |
| mvrhel_laptop | yes | 17:06.21 |
| | This looks like it will do what I need, but extracting it would be way too much work. I will fix the crap conversion so we don't segv so we can get the code in master | 17:07.26 |
| | Then we can fix this with your changes | 17:07.37 |
| Robin_Watts | I'm just pondering on that now. | 17:07.43 |
| mvrhel_laptop | Robin_Watts: one thing | 17:08.16 |
| | this function is much more complex that what I need | 17:08.28 |
| | In my case, we will always do the copy of the spots, and do the conversion of the process colorants | 17:09.02 |
| | so I could write a simpler one | 17:09.08 |
| | That would be another option | 17:09.15 |
| Robin_Watts | yes, but hopefully in the event of their being no spots, it'll be fast. | 17:09.18 |
| mvrhel_laptop | yes | 17:09.33 |
| Robin_Watts | If no spots, or if the same number of spots, we can do an optimised branch. | 17:09.38 |
| | That Crap conversion block makes no sense to me. | 17:10.11 |
| mvrhel_laptop | the error is that sn = 0 | 17:10.57 |
| | division by zero line 380 | 17:11.10 |
| Robin_Watts | mvrhel_laptop: Yeah, it hasn't been updated since src->alpha etc. | 17:11.26 |
| mvrhel_laptop | as src->n = 1 | 17:11.28 |
| Robin_Watts | Fixed version on the top of robin/master | 17:12.05 |
| | or at least, a version for your consideration. | 17:12.20 |
| mvrhel_laptop | cool | 17:13.26 |
| | ok. just need to fix dst to dest. but no more segv | 17:15.57 |
| | and output looks reasonable | 17:16.33 |
| | and altona still looks the same, but we know how we are going to fix that | 17:18.13 |
| Robin_Watts | cool. | 17:18.24 |
| mvrhel_laptop | Robin_Watts: Do you want to move that crap conversion down to where your mvrhel_master is and then do a clusterpush just to make sure? | 17:20.35 |
| Robin_Watts | mvrhel_laptop: Sure. | 17:20.47 |
| mvrhel_laptop | cool. I have to run Ethan to bus. I will be back in a bit to see the results | 17:21.08 |
| Robin_Watts | I suppose we ought to look at bmpcmps for other than ppmraw. | 17:24.08 |
| malc_ | Robin_Watts: mupdf_explored.pdf page 52 mentions FZ_IGNORE_SHADE - a thing that no longer exists | 17:26.11 |
| Robin_Watts | malc_: Thanks. | 17:26.36 |
| | malc_: To avoid me losing these comments (for which I am very grateful), could you stick 'em on a bug for me please? | 17:30.13 |
| malc_ | Robin_Watts: page 53 - FZ_DONT_INTERPOLAGE_IMAGES G=T | 17:30.22 |
| | Robin_Watts: can you open the bug first then i can comment and add the stuff as it's being discovered? | 17:30.55 |
| Robin_Watts | Sure. | 17:31.01 |
| | malc_: https://bugs.ghostscript.com/show_bug.cgi?id=698246 | 17:32.13 |
| malc_ | Robin_Watts: thanks | 17:35.23 |
| mvrhel_laptop | Robin_Watts: wow | 18:55.19 |
| | ok let me look at 312 for a sec | 18:55.27 |
| Robin_Watts | These might be the same issue maybe? | 18:56.40 |
| mvrhel_laptop | very likely | 18:56.46 |
| | maybe I should just do a conversion | 18:56.54 |
| | and we can optimize it out when we pull your changes in | 18:57.22 |
| Robin_Watts | Probably we should have fz_copy_pixmap_rect actually work in all cases :) | 18:57.25 |
| mvrhel_laptop | yes. oh I could do the conversion there | 18:57.38 |
| Robin_Watts | yeah. | 18:57.44 |
| mvrhel_laptop | ok let me do that | 18:57.49 |
| | that should be simple enough | 18:58.21 |
| Robin_Watts | I have to head off and deal with puppy chaos. will check back in later. | 18:58.24 |
| mvrhel_laptop | ok. have fun :) | 18:58.33 |
| | hmm interesting. D still has issue after this fix. digging further | 19:22.34 |
| | Robin_Watts: so my fix did not fix the issues in 312 and friends. looking into this as there is something odd going on | 20:02.01 |
| | ok. I have hacked this file to the point where it has to be obvious what is goiing onn | 20:21.45 |
| | lunch | 20:31.37 |
| malc_ | Robin_Watts: not sure if it's worth a bug comment, but your spelling is somehow inconsistent... behaviour, specialised but color | 20:37.16 |
| | Robin_Watts: actually you have both colour and color... | 20:38.49 |
| Robin_Watts | yeah. I am torn... | 23:12.29 |
| malc_ | yeah patriotism vs more typing.. hard choice | 23:23.01 |
| Robin_Watts | Correct spelling vs colonial :) | 23:30.47 |
| malc_ | hah | 23:34.28 |
| | Forward 1 day (to 2017/07/14)>>> | |
Log of #mupdf at irc.freenode.net.