| | <<<Back 1 day (to 2017/07/31) | 20170801 |
| suggestion | Earlier versions of MuPDF allowed the user to left click and drag to scroll downwards (and to change pages), this feature seems to be absent from the current version. It would be great to see it reinstated! | 12:48.24 |
| tor8 | suggestion: the new version uses the middle button to pan the page | 12:49.22 |
| | using left clicking to pan conflicts with clicking on links and forms | 12:49.47 |
| suggestion | @tor8, the old version uses the middle (scroll) button to pan too. But the middle button does not permit panning left/right nor does it permit changing the page | 12:50.47 |
| tor8 | suggestion: really? left/right panning works in mupdf-gl for me. not automatically switching pages is true, though. | 12:51.48 |
| suggestion | I stand corrected! I forgot that I can click the scroll wheel. | 12:53.10 |
| | (It feels rather unnatural, but I can get used to it.) | 12:53.40 |
| | Automatically switching pages would be a great addition. | 12:53.54 |
| tor8 | suggestion: https://www.amazon.com/HP-Optical-Button-Mouse-accessory/dp/B0002Y5LZ8 | 12:54.04 |
| suggestion | I like the scroll wheel too much ;-) | 12:54.28 |
| | Thanks for all the development effort! I have been a huge fan of xpdf for over a decade, but getting it running is quite painful these days. MuPDF is an excellent replacement. | 12:55.33 |
| tor8 | I'm glad you enjoy it. | 13:00.51 |
| knielsen | I have some patches for mupdf-gl, that implement dual-page view, interactive search, and proper copy-paste and some other smaller stuff: https://github.com/knielsen/mupdf | 13:22.44 |
| | Is there interest in getting (some of) these patches upstream, and if so what would be the best way to go about it? | 13:22.47 |
| malc_ | knielsen: what's interactive search? | 13:33.42 |
| knielsen | malc_: it's also known as "search as you type" | 13:34.02 |
| malc_ | knielsen: thanks | 13:34.32 |
| knielsen | malc_: so if I want to search for "giraffa", I start typing, and maybe when I have typed "gira", mupdf-gl will have found the right place already | 13:34.58 |
| malc_ | knielsen: I've seen instances when functionality like this was falling on it's face in presence of "complex" documents (with okular or maybe some of the browser internal viewers) | 13:36.17 |
| knielsen | malc_: in what way, eg. being slow? | 13:36.47 |
| | malc_: it's basically searching one page at a time, and being responsive to receiving more inputs on the way, I think it should not be much different from the existing search in terms of performance. But I'd be happy to see an example where it works poorly, certainly | 13:38.50 |
| tor8 | knielsen: impressive work! | 13:39.22 |
| malc_ | knielsen: chaotic behavior in general, unresponsiveness too | 13:40.06 |
| knielsen | tor8: tnx! | 13:40.17 |
| malc_ | normen and svensker coexisting peacefully and complementing each other.. wow | 13:41.00 |
| tor8 | knielsen: some of the patches look like we could take them on. personally not a fan of dual-page mode (it adds a fair number of complications to the code) | 13:41.05 |
| knielsen | malc_: hm, I have only good experience with interactive search (eg. okular). I would really miss it in my day-to-day use | 13:41.17 |
| | mupdf-gl is _much_ faster at searching than okular though | 13:41.30 |
| | tor8: sure, you're welcome to take what you want | 13:42.13 |
| malc_ | tor8: i guess you would really hate negative-page mode in my thing :) | 13:42.17 |
| tor8 | knielsen: however, we will need a copyright assignment in order to take on patches of this magnitude.we need it because we also do commercial licensing | 13:42.53 |
| knielsen | tor8: personally, dual-page view is probably the most important feature for me. It actually ended up fitting really well into the existing code, but yes it does touch many other parts | 13:43.08 |
| | tor8: yes, I saw, I will send it if you want to include any of the code | 13:43.34 |
| tor8 | knielsen: I'll need to read the patch more closely to see how offended I am by the changes. if they are small enough I will definitely consider it. | 13:43.40 |
| malc_ | knielsen: http://www.youtube.com/watch?v=Pdf-RtDDpaw | 13:43.43 |
| | tor8: you commercialize mupdf-[gl|x11] too? | 13:44.30 |
| knielsen | tor8: sure. Probably, some things will need changing, I tried to keep to the coding style etc. but I have never worked with mupdf code before. | 13:44.35 |
| | tor8: just let me know if you have some comments or suggestions for changes | 13:44.51 |
| tor8 | knielsen: the color modes patch uses shaders, which I have tried to avoid. opengl and shaders *always* runs into stupid cross platform or driver issues, in my experience | 13:45.23 |
| knielsen | tor8: yeah, the color mode patch is a bit controversial due to shaders | 13:45.47 |
| | tor8: a friend of mine really wanted it, and it was a fun exercise to learn about opengl shaders | 13:46.16 |
| tor8 | so I really only use opengl 1.2 features plus the ARB_texture_non_power_of_two extension in mupdf-gl | 13:46.33 |
| knielsen | tor8: I can pull out relevant patches in a separate branch, if you want. Probably the main decision is whether to take dual-page or not, as I think it interacts with some of the other patches | 13:47.28 |
| | tor8: also, the X11 primary selection is quite unix-specific (but again it was really important for my workflow) | 13:48.07 |
| tor8 | knielsen: I think patching GLFW to support the primary selection would be easier | 13:48.34 |
| knielsen | tor8: could be, yes | 13:48.48 |
| tor8 | we already have mupdf-specific patches in our GLFW submodule | 13:49.09 |
| | so adding another one for the primary selection would not be a big deal | 13:49.20 |
| knielsen | ok, I'll look into it, would be better than this hack of spawning xsel | 13:49.47 |
| malc_ | knielsen: spawning xsel/xclip is a lot easier than dealing with X selections | 13:50.18 |
| | knielsen: and you can also reuse the code to run pbpaste/copy on macos | 13:50.43 |
| tor8 | knielsen: I suspect it would be as easy as duplicating all the lines that use _glfw.x11.CLIPBOARD to also do the same with _glfw.x11.PRIMARY (once you add that Atom to the struct) | 13:51.40 |
| knielsen | malc_: ok, I'm not much familiar with macos. I suppose primary selection might be easy on GLFW since it already has code for clipboard selection | 13:51.49 |
| tor8 | knielsen: I think GLFW is hampered by the fact that non-X11 systems don't have a distinction between clipboard and selection | 13:52.47 |
| knielsen | yep | 13:52.57 |
| tor8 | so they don't expose the concept at all | 13:53.07 |
| | setting the selection would be handy. personally I'd like that, but I'm not in need of being able to paste the selection in mupdf. | 13:53.35 |
| knielsen | tor8: nah, I only implemented copying. No pasting into mupdf | 13:54.03 |
| | I suppose pasting into search could be useful, but it's not something I've needed... | 13:54.33 |
| Robin_Watts | Morning mvrhel_laptop | 14:08.56 |
| mvrhel_laptop | Morning Robin_Watts | 14:09.07 |
| | Robin_Watts: So today I will work on page 15 of the Atltona Technical v20 x4 document. | 14:11.38 |
| malc_ | knielsen: the search as you type with your patches also results in "funny" behavior on http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-376,%20Fifth%20Edition,%20Part%201%20-%20Fundamentals%20And%20Markup%20Language%20Reference.zip | 14:11.52 |
| mvrhel_laptop | Did you get a chance to see the gradient (page 8) issue? | 14:11.55 |
| | page 8 ? | 14:12.02 |
| knielsen | malc_: interesting, let me check | 14:12.18 |
| Robin_Watts | mvrhel_laptop: Looking into it now. | 14:12.36 |
| mvrhel_laptop | ok | 14:12.40 |
| malc_ | knielsen: search for abracadabra or something and then try to navigate while it does plow through 5+K pages | 14:12.53 |
| Robin_Watts | mvrhel_laptop: Got it, I think. | 14:14.22 |
| mvrhel_laptop | cool | 14:16.02 |
| knielsen | malc_: it seems to work the same with or without my interactive search patch. Note that navigation is explicitly disabled while it is searching, but you can abort the search with ESC | 14:18.12 |
| Robin_Watts | mvrhel_laptop: So, the only obvious diffs I could see against gs with Altona_Technical_1x1_x3.pdf were the ones where gs was wrong. | 14:18.38 |
| | so I'm assuming that's OK, and am moving on to the ones you mentioned in your email. | 14:18.57 |
| malc_ | knielsen: oh, sorry for false alarm then (not a mupdf user myself) | 14:19.02 |
| mvrhel_laptop | Robin_Watts: sounds great | 14:19.04 |
| Robin_Watts | gs gives errors while decoding page 9. | 14:19.12 |
| mvrhel_laptop | yes, but gives something reasonable | 14:19.35 |
| knielsen | malc_: well, it's a nice test document :-) okular takes forever to search through it | 14:19.39 |
| Robin_Watts | ok, so I shall look at that next. | 14:19.51 |
| malc_ | knielsen: yep, it's one of my go-tos when looking for interesting behaviors | 14:20.24 |
| Robin_Watts | All the 3 by 3 grid things on every page are wrong. | 14:20.30 |
| | composite K rather than device K. | 14:20.45 |
| mvrhel_laptop | oh | 14:25.16 |
| | I have to grab a bite to eat before I dive into this | 14:26.04 |
| Robin_Watts | mvrhel_laptop: meeting in 4 mins :) | 14:26.19 |
| mvrhel_laptop | eating bowl of cereal now.. :) | 14:27.39 |
| | Robin_Watts: those gray fills are from source colors that are RGB | 14:34.22 |
| | so composite gray is what they should be | 14:34.28 |
| | but wait | 14:34.42 |
| | ok yes | 14:35.02 |
| Robin_Watts | All I know is that my new bmpcmp shows them as being different, and when I compared gs and mupdf in photoshop there was a difference. | 14:35.12 |
| mvrhel_laptop | Robin_Watts: ok. I think mupdf is correct | 14:36.37 |
| Robin_Watts | mvrhel_laptop: oh, cool, result! | 14:36.57 |
| mvrhel_laptop | The cmyk percentages match Adobe | 14:38.00 |
| knielsen | tor8: ok, thanks, I'll send the copyright assignment and look at glfw primary selection. And you can let me know when you've looked at the patches which you'd want to include and what changes might be needed | 14:46.27 |
| mvrhel_laptop | Robin_Watts: So the rendering issues of page 15 appear to be due to mupdf drawing optional content group graphics | 15:03.52 |
| | I am not overly familiar with OCGs | 15:04.07 |
| Robin_Watts | mvrhel_laptop: urgh. | 15:05.54 |
| | I spotted another problem on the gradient page, but it's being heisenbuggy. | 15:06.31 |
| mvrhel_laptop | I am going to read the OCG section in the spec | 15:07.03 |
| | although it is a little long.... | 15:07.29 |
| Robin_Watts | mvrhel_laptop: OCGs basically just turn bits of content on and off. | 15:12.29 |
| | If I was you, I'd punt on that and look at any other issues first. | 15:12.55 |
| mvrhel_laptop | ok. I gave it to kens to get his advice | 15:13.44 |
| | about the file anyway | 15:13.51 |
| kens | OK so the content is defined as being present in marked content MC0 | 15:19.12 |
| | And that's in an OCG | 15:19.25 |
| | So we should only drw it if the OCG is on | 15:19.37 |
| | MC0 is OCG object #22 | 15:20.11 |
| | Which has /OCGs [20 0 R] | 15:20.21 |
| mvrhel_laptop | Robin_Watts: ok. I am moving on finally | 15:45.54 |
| | Robin_Watts: I am going to look at the missing orange fill on page 10 | 15:46.27 |
| Robin_Watts | ok. | 15:46.37 |
| | I have a wierd one on page 8 still - a fill is coming out as grey rather than orange. | 15:47.07 |
| | I think we're plotting it as orange, then we get an image overlaid that changes the colorspace, and in converting there and back somehow it's going grey. | 15:47.35 |
| | I'm getting there... | 15:47.40 |
| mvrhel_laptop | maybe some optional content ;) | 15:47.49 |
| sebras | tor8: a few patches on sebras/master | 16:03.35 |
| | tor8: all are small. | 16:03.40 |
| mvrhel_laptop | Robin_Watts: ok. I will have a fix for page 10 in a sec. found the issue | 16:32.45 |
| Robin_Watts | nice. | 16:32.50 |
| mvrhel_laptop | It was my fault | 16:33.05 |
| Robin_Watts | let's not start keeping track of whose fault things is, eh? It'd end badly for me. | 16:36.59 |
| mvrhel_laptop | ha I dont think so | 16:40.06 |
| | ok that is pushed on my repos blend_spot branch | 16:40.20 |
| | I single sign error | 16:40.26 |
| | s/I/A | 16:40.32 |
| | Robin_Watts: I am going to spend a little time on page 7 now | 16:41.13 |
| | The red square | 16:41.24 |
| Phrk_ | hi | 17:25.28 |
| mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 17:25.28 |
| Phrk_ | is there a way to have websocket in mujs ? | 17:25.50 |
| mvrhel_laptop | damn comcast service.... | 17:35.23 |
| | I am close to having one of the issues on page 7 figured out. We are pushing a form group to early in the drawing process | 17:36.12 |
| tor8 | Phrk_: only if you implement it as an extension yourself | 17:43.40 |
| | sebras: (for the logs) sebras/master LGTM, modulo the "all all" typo in the commit message | 17:44.07 |
| Phrk_ | and how can i do that since it's a standard lib ? tor8 | 18:00.55 |
| mvrhel_laptop | after 1 hour on phone with comcast back | 18:17.53 |
| Phrk_ | tor8, can i just give him the nodejs lib ? | 18:18.28 |
| | he doesn't seems to like it : SyntaxError: ./WebSocket.js:9: unexpected token: (identifier) (expected ';') | 18:18.53 |
| | line 9 is const EventEmitter = require('events'); | 18:19.06 |
| mvrhel_laptop | Robin_Watts: are you there? | 18:22.07 |
| Robin_Watts | I am. | 18:22.15 |
| mvrhel_laptop | Can you look at https://pastebin.com/WJGRFMBX for a sec with me | 18:22.41 |
| Robin_Watts | ok... | 18:23.40 |
| mvrhel_laptop | So this bit of content draws a rectangle and fills with with a Lab color | 18:24.02 |
| | That is the bit up to line 15 | 18:24.14 |
| Robin_Watts | "rectangle" :) | 18:24.24 |
| mvrhel_laptop | so at line 20 we have a form | 18:24.54 |
| | that has an RGB transparency group | 18:25.02 |
| Robin_Watts | oh, it is a rectangle, just a rotated one. | 18:25.05 |
| mvrhel_laptop | What is odd is this | 18:25.05 |
| | yes | 18:25.09 |
| | MuPDF does not draw the rectangle until after the Form group is pushed | 18:25.34 |
| | Which is wrong | 18:25.41 |
| | as the rectangle should be drawn earlier when we are in a CMYK destination space | 18:26.00 |
| Robin_Watts | Really? | 18:26.05 |
| mvrhel_laptop | prior to the group push | 18:26.06 |
| | well I can't figure this out | 18:26.36 |
| | maybe I am wrong | 18:26.41 |
| | oh maybe I should use the debug output images | 18:26.55 |
| | let me do that hold on | 18:27.03 |
| Robin_Watts | Well, pdf_run_f is the thing called when we hit 'f'. | 18:27.31 |
| | That calls pdf_show_path | 18:27.41 |
| | with dofill=1, and all the others 0. | 18:28.08 |
| mvrhel_laptop | Robin_Watts: I hit case B('D','o'): pdf_process_Do(ctx, proc, csi); first before any f is hit | 18:28.29 |
| Robin_Watts | Are you 100% sure you are running this file? :) | 18:28.56 |
| mvrhel_laptop | yes | 18:29.28 |
| Robin_Watts | Give me a copy of it. | 18:29.41 |
| mvrhel_laptop | just doubled checked :) | 18:29.41 |
| | ok | 18:29.44 |
| | Robin_Watts: sent... | 18:30.47 |
| | oh | 18:31.00 |
| | duh | 18:31.05 |
| Robin_Watts | should I look away? :) | 18:31.33 |
| mvrhel_laptop | yes | 18:31.36 |
| | hold on | 18:31.38 |
| | hmm ok. let me work on this a bit more pdf processing is correct ;) | 18:32.56 |
| | I missed that I was in a form already... | 18:33.30 |
| Robin_Watts | ok, I have a similarly bonkers thing going on here. | 18:33.53 |
| tor8 | Phrk_: which WebSocket.js are you trying to use? there's nothing in mujs that provides access to system level sockets. | 18:36.51 |
| | const EventEmitter = require('events') uses JS 6 syntax. mujs only supports JS 5 and earlier, you'll need to transpile to support JS6. | 18:37.49 |
| | Phrk_: WebSocket is a browser specific JS API, it's not part of the ecmascript standard | 18:38.46 |
| Phrk_ | tor8, this one : https://github.com/websockets/ws | 18:39.10 |
| | oh no socket in mujs ? | 18:39.57 |
| tor8 | yeah, that one uses the node.js APIs. | 18:39.58 |
| | indeed, there are no sockets in mujs. if you want them you'll need to implement the functions yourself. | 18:40.25 |
| | mujs only provides the core standard ecmascript language. "no batteries included". | 18:40.46 |
| Phrk_ | but is there any ready lib i can use for that ? | 18:41.08 |
| tor8 | not that I know of. | 18:41.15 |
| Phrk_ | and for http ? | 18:41.27 |
| tor8 | Phrk_: http://www.ecma-international.org/ecma-262/5.1/ if it's not in that spec, mujs doesn't have it. | 18:44.21 |
| malc_ | tor8: is this thing typeset in palatino? | 18:45.36 |
| tor8 | malc_: looks like palatino to me | 18:46.17 |
| malc_ | tor8: you don't see it every day on the web | 18:46.40 |
| Phrk_ | thx tor8 | 18:46.40 |
| Robin_Watts | mvrhel_laptop: I've got a blending problem here, I think. | 18:50.32 |
| | I wonder if this is a typo... | 18:53.19 |
| | In fz_blend_separable_nonisolated at line 675, you are using 255 - bc | 18:53.51 |
| | but bc has already been inverted... | 18:54.13 |
| malc_ | tor8: an the pdf version uses arial.. go figure | 18:58.31 |
| mvrhel_laptop | oh let me look | 19:00.54 |
| | Robin_Watts: that was the fix I did | 19:01.19 |
| Robin_Watts | what fix you did when? | 19:01.37 |
| mvrhel_laptop | hehe. In the logs here, I said I found the issue and pushed a fix on my repos blend_spot branch | 19:02.03 |
| | That was the issue in the orange fill | 19:02.11 |
| | It was a sign issue | 19:02.23 |
| | rc = 255 - bc - fz_mul255(sa, fz_mul255(255 - ba, sc) + fz_mul255(ba, rc) - bc); | 19:02.28 |
| | should be this | 19:02.31 |
| Robin_Watts | right. | 19:02.32 |
| mvrhel_laptop | hopefully you did not spend a lot of time stumbling on that | 19:03.23 |
| Robin_Watts | which orange color? | 19:03.23 |
| mvrhel_laptop | Page 10 of altona file | 19:03.37 |
| Robin_Watts | Ah. It's also on page 8 of the altona file. | 19:04.06 |
| | OK, your fix fixes page 8 of the altona file too. | 19:04.38 |
| mvrhel_laptop | good deal | 19:04.43 |
| Robin_Watts | but there is still a problem on that page. | 19:04.48 |
| mvrhel_laptop | :( | 19:04.54 |
| Robin_Watts | I will cut the file down again tomorrow and go looking for that. | 19:05.10 |
| mvrhel_laptop | ok. I will keep plugging on page 7 | 19:05.20 |
| Robin_Watts | I've put the latest stuff onto robin/spots | 19:05.38 |
| mvrhel_laptop | very odd situation with lab source color and some blending color space confusion | 19:05.45 |
| | Robin_Watts: ok I will update | 19:05.50 |
| | heat wave here this week | 19:06.05 |
| | supposed to get to 100 or so | 19:06.09 |
| Robin_Watts | It's alternately warm or raining here. | 19:06.37 |
| mvrhel_laptop | ok. I have tracked this issue down to improper color conversion | 19:32.28 |
| | doing the conversions in photoshop with the same profiles gets me where I want to be | 19:32.42 |
| | now I need to see where we are failing | 19:32.53 |
| | and it looks like it is the lab to wide gamut rgb | 19:34.41 |
| | aha! | 20:36.18 |
| | there is some funny business going on with the proof color space | 20:43.59 |
| | I think since you added the push of the separations group the proof is no longer really needed in the manner that we have it | 20:44.36 |
| | Before I rip it all out, I am going to cripple it for testing | 20:45.09 |
| Robin_Watts | hi | 22:56.00 |
| mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 22:56.00 |
| Robin_Watts | mvrhel_laptop: ping | 23:15.17 |
| | mvrhel_laptop: For the logs. There is an overprinting problem with shades. That's the cause of the remaining problem on page 8. | 23:47.55 |
| | I'll carry on in the morning. must sleep. | 23:48.04 |
| | Forward 1 day (to 2017/08/02)>>> | |
Log of #mupdf at irc.freenode.net.