| | <<<Back 1 day (to 2017/07/11) | 20170712 |
| tapman | hi, just installed mupdf, I was annoyed with adobe acrobat reader and these unuseful pannels | 11:05.23 |
| | but now I don't have a preview of my pdf files in explorer, how can I have that with mupdf ? | 11:06.03 |
| | I mean the thumbnails | 11:06.23 |
| tor8 | tapman: mupdf can't create windows explorer thumbnails | 11:06.50 |
| | you could have both acrobat and mupdf installed, just pick mupdf as the default application | 11:07.12 |
| tapman | I thought I did that. | 11:07.27 |
| | but I just copy mupdf to the right place in program files x86, and "open with..." "always" with mupdf. | 11:08.13 |
| tor8 | then I don't know. I hate thumbnails in explorer so I've turned them off (I always use the "detail" view) | 11:08.14 |
| | and that makes the thumbnails disappear? | 11:08.23 |
| tapman | YES | 11:08.29 |
| tor8 | strange. I'm sorry to say I don't have an answer for you. | 11:08.42 |
| tapman | the pdf icon change to the mupdf icon | 11:08.43 |
| tor8 | ah. I think that behaviour is new with windows 8 or 10. | 11:09.58 |
| tapman | The thumbnails come back but I just change "open with..." "always" with acrobat reader DC | 11:10.03 |
| tor8 | mupdf doesn't set a document icon | 11:10.07 |
| | so in windows 7 and earlier it had the system default or let another application choose the icon. | 11:11.11 |
| | for PDF files | 11:11.15 |
| tapman | the icon is not important for me, the thumbnail is. | 11:13.12 |
| | the detail view is of course very important for me. | 11:13.30 |
| | and is there a windows preference dialog in mupdf ? | 11:14.43 |
| | because it opens the window not always in 100% and not entirely inside the screen | 11:15.16 |
| | tell me what you thing : what would be perfect for me, if it forces the opening inside the screen, maybe something like 80% of the height, and if the Z (Zoom to fit page) is activated each time I open a pdf file. | 11:21.45 |
| | s/thing/think | 11:21.58 |
| | the goal is to have no annoying action to do when opening and closing pdf files | 11:27.31 |
| | I'm not asking you to do something, juste asking for the status of the dev and if another usage is very different of my needs ;) | 11:28.44 |
| tor8 | tapman: the intent is to open the document zoomed to 100% and the window wrapped to fit the document perfectly | 11:47.43 |
| | that obviously doesn't work perfectly on small screens | 11:47.53 |
| | tapman: have you tried the SumatraPDF viewer? it's based on (an older) version of mupdf and could fit your purposes well. | 11:51.24 |
| tapman | tor8: I have just tried SumatraPDF, it's the same annoying features as acrobat reader. | 11:58.02 |
| | it opens a panel with bookmarks | 11:58.15 |
| | i didn't memorize the One Page Display, and I don't like the "Page continue display" | 11:58.56 |
| | and now, I have the horrible SumatraPDF icons :) | 11:59.27 |
| | and no thumbnails | 11:59.36 |
| tor8 | sounds like you want mupdf, but with a thumbnailer service (which I have no idea how to do, I'm not a windows developer) | 12:00.02 |
| tapman | I have just cloned the git of mupdf | 12:00.34 |
| | and it seems to be a big low level project coded in C. | 12:01.00 |
| tor8 | yes. there is a MSVC 2005 project file in platforms/win32/ | 12:01.30 |
| | there are two viewers for windows -- an older one using only win32 and gdi, and a newer one using glfw and opengl. | 12:01.56 |
| | changing the startup behaviour in either one to be what you want in regards to zoom levels etc should be a minor job | 12:02.17 |
| | platform/gl/gl-main.c and platform/x11/win_main.c (the win32 and x11 viewers share source, hence the 'x11' directory) | 12:02.44 |
| tapman | maybe, but that doesn't solve the thumbnails problem. | 12:03.15 |
| tor8 | nope, for that you need to do some more work | 12:03.32 |
| tapman | I think I remember there's a dll that handle that | 12:03.40 |
| | a dll from adobe acrobat | 12:03.48 |
| tor8 | Robin_Watts may be able to help there, he's more familiar with windows programming | 12:03.49 |
| tapman | ok thanks, but I'm an old C coder but that's all. | 12:04.27 |
| | don't know windows programming for now. | 12:04.42 |
| tor8 | my vague recollection is you need to create a dll that does the job. if you know what you're doing it's probably not too hard. we have command line tools to render to image files, wrapping that up in a dll to render the first page of a document in whatever format windows wants should be easy. | 12:04.44 |
| | but I have no idea where to start digging, and I don't currently have a functioning windows build system. | 12:05.11 |
| | my old virtualbox blew up... | 12:05.20 |
| tapman | ok, I have a dual boot win 10 and ubuntu | 12:05.57 |
| | but win 10 is very good now | 12:06.09 |
| | and I have some ubuntu tools inside win 10. | 12:06.23 |
| tor8 | the linux subsystem in win10 makes it almost usable :) | 12:06.36 |
| | I have win10 on my travel laptop | 12:06.42 |
| tapman | 217 source files, that's not too much | 12:08.27 |
| | another subject... | 12:09.36 |
| | have you an idea about EPUB | 12:09.44 |
| | a tool that will be a beautifier of epub files ? | 12:10.11 |
| | I hate epub files, but it's just text, so we should reformat it, with something like CSS | 12:11.11 |
| tor8 | mupdf's epub viewer can be told to ignore publisher styles and then you can supply your own CSS file | 12:22.06 |
| tapman | tor8: ok, I will try that, thanks ! | 12:25.42 |
| avih | tor8: do you plan to push your .toString(radix) to master? maybe also tag a 1.0.1? there were few important fixes since the premature 1.0 ;) | 15:54.20 |
| tapman | any idea why mupdf is slower than adobe acrobat reader ? | 15:54.47 |
| | mupdf is written in C so why is it slower that acrobat reader dc ? | 15:55.38 |
| tor8 | tapman: performance can vary a lot depending on implementation choices, even when using C :) | 15:56.22 |
| kens | That's a question akin to 'why isn't my piece of st5ring long enough ?' | 15:56.25 |
| avih | :) | 15:56.40 |
| tor8 | tapman: however, a very common source of mupdf slowness comes from files using JPEG2000 images | 15:56.47 |
| | the open source jpeg2000 library is dog slow | 15:56.54 |
| | avih: yes, just haven't got around to it yet | 15:57.14 |
| tapman | tor8: exactly what I just saw | 15:57.19 |
| tor8 | and jpeg2000 is a really crappy format, so nobody wants to waste their time writing a new faster open source decoder for it... | 15:57.58 |
| tapman | is there any other faster library for jpeg ? | 15:58.05 |
| | tor8: that doesn't exist yet ? | 15:58.20 |
| tor8 | there are other faster libraries for jpeg2000, but they're not open source. | 15:58.31 |
| tapman | tor8: no one want to buy the spec book because of the price maybe :) | 16:01.14 |
| | https://www.amazon.co.uk/JPEG-Compression-Standard-Multimedia-Standards/dp/0442012721 | 16:01.21 |
| tor8 | I've read the spec. it's *terrible*. | 16:01.28 |
| kens | I'#ve implemented a decoder, and the spec is a nightmare | 16:01.43 |
| tor8 | seriously designed by committe overwrought sh*t. | 16:01.46 |
| | tapman: also, we are talking about jpeg2000, which has *nothing* in common with jpeg (despite the name). | 16:02.34 |
| tapman | I'm not aware about the details, but you say that the PDF format use an old version of jpeg (JPEG2000) ? | 16:03.44 |
| tor8 | PDF files have embedded images, and these images can use many different formats. | 16:04.07 |
| kens | JPEG2000 is newer than JEPG | 16:04.15 |
| tor8 | one of the formats is JPEG (the good old fashioned jpeg that we all know and love) | 16:04.21 |
| kens | JPEG* | 16:04.21 |
| tor8 | another format is JPEG 2000, which is a stupid format designed to solve problems nobody had, and is extremely inefficient to decode | 16:04.54 |
| | if your PDF file uses JPEG2000 images, mupdf will be slower than acrobat at reading these files. | 16:05.16 |
| tapman | tor8: so ? maybe I can convert the pdf file to replace the JPEG2000 images with JPEG ? | 16:05.52 |
| avih | reading or rendering? or are they one with libmupdf? | 16:06.03 |
| tor8 | avih: more accurately, decoding :) | 16:06.19 |
| avih | right. threading? progressive enhancement? | 16:06.38 |
| tor8 | openjpeg is just slow. | 16:06.54 |
| | jasper was slower and buggy. | 16:07.03 |
| avih | but in a thread it won't halt everything else, right? | 16:07.11 |
| tapman | is there some good free documentation for implementing that ? | 16:07.23 |
| tor8 | we still need the decoded image to render, even if we'd do it on a background thread we'd be waiting for a couple of seconds for the image to decode. | 16:07.32 |
| avih | so you'll put a "loading" placeholder till it's done | 16:07.36 |
| Robin_Watts | avih: THen you'd need to rerender everything on top. | 16:07.45 |
| | avih: That doesn't fit with the way MuPDF is structured. | 16:08.04 |
| avih | Robin_Watts: how's that? i assume the dimensions can be known quickly. are they not? | 16:08.16 |
| tor8 | avih: other things can be drawn on top of the image. | 16:08.26 |
| kens | what iof a later object (z order) partially overlays the image avih ? | 16:08.31 |
| tor8 | and there are transparency and blending operations, the image could be used as a soft mask, etc, etc. | 16:08.48 |
| kens | Worse still, what if its transparent ? | 16:08.51 |
| avih | sure, so if stuff has to be redrawn, so be it, but it does improve the user experience in an interactive mode | 16:08.51 |
| | which indeed has different requirements than batch mode | 16:09.12 |
| tor8 | avih: a much better solution is to not use JPEG2000 :) | 16:09.19 |
| Robin_Watts | avih: MuPDF allows for tricks like that, sure. | 16:09.32 |
| kens | JPEG2000 is actually fairly rare, because the endoer requires a licence | 16:09.39 |
| avih | it's not a problem unique to jpeg2000 imo, even if it's an extreme case of it | 16:09.44 |
| tor8 | avih: yes, big images of any format take a while to decode and render. jpeg2000 is just an order or two magnitude more inefficient than anything else out there. | 16:10.15 |
| Robin_Watts | You could write a device that skips such images and feed the display list through it. | 16:10.44 |
| tor8 | luckily they're rare enough that we haven't felt a pressing need to do anything about it | 16:11.04 |
| avih | yeah, but a reader would still benefit from putting placeholders and keeping interactive till everything can be presented (disclaimer: i only used mupdf once and don't know if it does it or not) | 16:11.18 |
| Robin_Watts | avih: MuPDF is a C library, with lots of smarts in it. The apps are really thin layers. | 16:11.46 |
| avih | for you. but not for users of mupdf :) | 16:12.01 |
| Robin_Watts | The C library has enough hooks in to do stuff like this. | 16:12.02 |
| | If you want to write shinier apps, then you can. That's not our development thrust. | 16:12.34 |
| avih | i understand the tradeoffs mupdf makes and its priorities. i'm just saying it makes sense to you but not necessarily serves the user of mupdf itself | 16:13.03 |
| Robin_Watts | avih: When we get a paying customer that has a real problem, that'll be a priority that appears on our radar. | 16:13.52 |
| | Until then... | 16:13.55 |
| avih | IMO for most users mupdf is the most visible thing you produce | 16:14.20 |
| | i'm not arguing you should modify it as a high priority, just that you should acknowledge it | 16:14.46 |
| Robin_Watts | avih: For most paying users? it's not. | 16:15.29 |
| | Really, you're arguing that we should be worrying about something that isn't a problem for 99% of the users out there, paying or otherwise. | 16:15.54 |
| tapman | Robin_Watts: feel free to answer me or not ;) what kind of paid users ? | 16:16.03 |
| Robin_Watts | And you knock yourself out. | 16:16.05 |
| | tapman: MuPDF is dual licensed. | 16:16.17 |
| avih | i didn't want to get to a discussion of "who is the user", so let me rephrase: most people who use code you wrote use mupdf, IMO | 16:16.19 |
| kens | But hey don't pay us anything | 16:16.40 |
| | SO they get to use the code for free, which we're happy with | 16:16.49 |
| Robin_Watts | If you are happy to abide by the terms of the GNU AGPL, then you can use MuPDF for free under those terms. | 16:16.53 |
| avih | the fact that the vast majority doesn't pay is not weightless | 16:16.54 |
| kens | But our main focus is on people who pay us | 16:16.57 |
| tapman | Robin_Watts: oh ok I see, so you there's a commercial license ? but they are anonymous paid users ? | 16:17.15 |
| kens | Many many people use MuPDF under the terms of the AGPL | 16:17.30 |
| Robin_Watts | If you aren't happy with those terms (perhaps you want support, or you want to be able to ship it in a product that doesn't want to be AGPL licensed), then you can commercially license it from us. | 16:17.43 |
| kens | and do so for free, just like Ghostscript users | 16:17.44 |
| avih | kens: clearly i understand it, but IMO it's also a matter of image, as, IMO, your public face is mupdf | 16:17.56 |
| Robin_Watts | tapman: We have many commercial users (that pay our wages). I cannot disclose all their names. | 16:18.11 |
| kens | I think there's a partial list of our customers on the Artifex web site if that's of interest | 16:18.41 |
| avih | Robin_Watts: disclose parts of their names! :p | 16:18.47 |
| Robin_Watts | avih: And if this was a real problem for any significant number of users of the linux/windows viewer, we might be tempted to care. but it's not, so we don't. | 16:18.55 |
| tapman | Robin_Watts: they use mupdf in their embedded software I suppose ? | 16:18.57 |
| Robin_Watts | avih: 'g'. | 16:19.07 |
| kens | most people just use the demo viewers tapman | 16:19.10 |
| avih | Robin_Watts: yeah, that i agree with (problem to many) | 16:19.14 |
| kens | Huh seems we don't publish any kind of customer list any more | 16:20.12 |
| kens | wanders off to cook | 16:22.40 |
| Robin_Watts | mvrhel_laptop: The situation I describe in the email happens at the start of the draw device. | 16:24.14 |
| | If I'm passed an rgb pixmap with a separations structure, I have to make a cmyk pixmap with spots in. | 16:24.52 |
| mvrhel_laptop | Robin_Watts: right but there is no conversion there | 16:25.09 |
| Robin_Watts | likewise at the end of the draw device, I have to convert from the cmyk + spots back down to the original rgb. | 16:25.15 |
| | mvrhel_laptop: Urm? Why is there no conversion there? | 16:25.25 |
| mvrhel_laptop | that one requires conversion | 16:25.26 |
| | Its blank | 16:25.32 |
| | isnt it? | 16:25.34 |
| Robin_Watts | Says who? | 16:25.36 |
| | Doesn't have to be blank. | 16:25.44 |
| mvrhel_laptop | oh I would have thought it would be | 16:25.48 |
| Robin_Watts | No, you can call to render onto an existing pixmap. | 16:26.04 |
| mvrhel_laptop | Hold on phone | 16:26.12 |
| Robin_Watts | no worries | 16:26.16 |
| tapman | is this the reference book for JPEG2000 ? : http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0471484229.html | 16:29.34 |
| | or this one ? : https://www.amazon.com/Compression-Fundamentals-Standards-International-Engineering/dp/1461352452/ref=sr_1_2?s=books&ie=UTF8&qid=1499877007&sr=1-2&keywords=JPEG2000 | 16:30.51 |
| mvrhel_laptop | Robin_Watts: ok back | 16:46.01 |
| | sorry about that | 16:46.05 |
| Robin_Watts | No worries. | 16:46.11 |
| mvrhel_laptop | So I had not thought about the case where the pixmap already has drawing | 16:46.20 |
| | on it | 16:46.21 |
| | at the start | 16:46.27 |
| Robin_Watts | Even without that case, the folding down at the end is the same thing. | 16:46.38 |
| mvrhel_laptop | Yes. The folding down I could see | 16:46.48 |
| | And there we will run into all the cases in transparency | 16:47.05 |
| | And we will run into all the cases in transparency | 16:47.23 |
| Robin_Watts | I'm close to having something I think. | 16:47.31 |
| mvrhel_laptop | cool | 16:47.36 |
| | I am stepping through my bmpcmps right now | 16:47.47 |
| | for some transpanency fixes | 16:47.57 |
| | question for you though | 16:48.07 |
| | How is the number of components going to be denoted in the pixmaps? Is n going to be just the gray, rgb, and cmyk colorant count and will there be an alpha and spot count? | 16:49.07 |
| Robin_Watts | pixmap->s = number of spot channels. | 16:49.25 |
| | pixmap->alpha = number of alpha channels. | 16:49.31 |
| mvrhel_laptop | ok cool | 16:49.39 |
| Robin_Watts | pixmap->n = total number of channels. | 16:49.39 |
| mvrhel_laptop | oh | 16:49.43 |
| Robin_Watts | so colorants = n - s- alpha | 16:49.47 |
| mvrhel_laptop | ok | 16:49.50 |
| | I will need to account for that later in the transparency fixes have | 16:50.08 |
| Robin_Watts | mvrhel_laptop: I suspect your transparency fixes will make it in before all this stuff does. | 16:50.28 |
| mvrhel_laptop | ok good. Then I wont worry about it at this time | 16:50.41 |
| Robin_Watts | and I can help resolve it, regardless. | 16:51.00 |
| | mvrhel_laptop: At various points we seem to be passing fz_colorspace *prf, and fz_default_colorspaces *default_cs... | 17:14.01 |
| | is prf not in default_cs ? | 17:14.08 |
| mvrhel_laptop | Robin_Watts: sorry I am back now | 18:03.05 |
| | Robin_Watts: so your question is, "is prf not in default_cs" | 18:03.39 |
| Robin_Watts | indeed. | 18:05.17 |
| | I'm wondering if we really need to pass both. Is prf not implied by default_cs ? | 18:05.40 |
| mvrhel_laptop | Currently, we only support the proof profile being the output intent | 18:06.31 |
| | However, that could change | 18:06.35 |
| Robin_Watts | Ah, ok. | 18:06.47 |
| mvrhel_laptop | If we decide we want to support proofing | 18:06.48 |
| | Which we may | 18:06.57 |
| | as that would be one of the useful mobile applications for mupdf | 18:07.13 |
| | i.e. like gproof does | 18:07.34 |
| Robin_Watts | yeah, that makes perfect sense. | 18:07.43 |
| | Hmm. | 18:07.53 |
| | So when we create a draw device and pass in a pixmap, I can't immediately make a different pixmap, can I? | 18:08.26 |
| | cos the pixmap I have to make will depend on the default_cs stuff that hasn't been setup yet. | 18:08.43 |
| | I need to make that new pixmap 'just in time' for the first drawing operation I guess. | 18:08.59 |
| mvrhel_laptop | It will depend upon the spot colors in the file and the output intent (if one exists) | 18:09.50 |
| Robin_Watts | The spot colors we know about. | 18:10.14 |
| | The different colorspaces we don't. | 18:10.25 |
| mvrhel_laptop | The only color space we need to concern ourselves with would be the output intent | 18:10.41 |
| Robin_Watts | i.e. if I get an rgb pixmap in, and I want to make a cmyk+spots pixmap, I need to know how to convert from rgb to cmyk. | 18:11.03 |
| mvrhel_laptop | Which is populated fairly early I thought unless you guys changed that | 18:11.04 |
| | oh | 18:11.12 |
| | There is that case again | 18:11.26 |
| Robin_Watts | yes, it's "early" (like, the first device call), but it's not available during the creation call. | 18:11.42 |
| mvrhel_laptop | ha. I am having trouble wrapping my head around that one since it is a little odd | 18:11.43 |
| Robin_Watts | It's a rare case, yes. | 18:11.56 |
| | but it's a potentially useful one. | 18:12.03 |
| mvrhel_laptop | question | 18:12.15 |
| | is there a way to know that the incoming pixmap is blank (the common case). So that we avoid the conversion in most cases? | 18:12.42 |
| | This seems very wasteful to me | 18:12.53 |
| Robin_Watts | mvrhel_laptop: Not currently. | 18:12.57 |
| | We might be able to add that later. | 18:13.08 |
| mvrhel_laptop | I think it would be wise to have that information | 18:13.11 |
| | I am really cringing when I think about it | 18:14.03 |
| Robin_Watts | Yes, having some way to avoid this is very desirable. | 18:15.48 |
| mvrhel_laptop | The altona test files are already hard enough. Adding another needless conversion seems crazy | 18:16.21 |
| | especially if it is for some very rare cases | 18:17.31 |
| | Robin_Watts: Are you there? | 18:52.56 |
| Robin_Watts | I am. | 19:06.50 |
| | mvrhel_laptop: ^ | 19:15.18 |
| mvrhel_laptop | oh I was wondering if you could look over some of the commits on my repos when you get a chance | 19:15.47 |
| | If something is not clear let me know | 19:16.03 |
| | These depend upon your WIP of the cmyk switch which is on the list | 19:16.22 |
| Robin_Watts | mvrhel_laptop: ok, will do. | 19:18.22 |
| mvrhel_laptop | If these go in, I am not sure what I can work on with this until you have the skeleton in place with deviceN and overprint. I am guessing at that point there will be some corner cases etc. I could start looking at the iOS application to see what if any work we need to do on the application side (e.g. add profile selection ectc( | 19:18.27 |
| Robin_Watts | mvrhel_laptop: I may soon be at the point at which my stuff can go in (at least on a shared branch) | 19:20.09 |
| mvrhel_laptop | great | 19:20.17 |
| Robin_Watts | ok, my styff is on robin/master if you want to peek. | 19:22.15 |
| | It runs altona (in that it doesn't crash), and it gives me a partial rendering that looks plausible. | 19:22.40 |
| mvrhel_laptop | cool | 19:24.40 |
| Robin_Watts | mvrhel_laptop: Ok so...: http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=commitdiff;h=ea915f623a59729ad2a7495d2037da0383a61698 | 19:29.46 |
| | The pixmap.h changes look to be some of my code that has somehow ended up there?!? | 19:30.00 |
| | There is a whitespace thing in page.h | 19:30.26 |
| mvrhel_laptop | Yes. That could go. Not sure how that go in there | 19:30.54 |
| | I see the space too | 19:31.16 |
| Robin_Watts | In fz_list_begin_group, you're putting the colorspace into the list. | 19:31.21 |
| | What guarantee do we have that the colorspace will live long enough? | 19:31.33 |
| | We need to fz_keep it I think. | 19:31.41 |
| mvrhel_laptop | oh good point | 19:31.52 |
| Robin_Watts | I'll fix this stuff if you want. | 19:32.18 |
| mvrhel_laptop | ok. If its easy for you to do | 19:32.28 |
| | with some ninja git tricks | 19:32.38 |
| Robin_Watts | We can also simplify the stuff in pdf-run.c a bit. | 19:33.30 |
| | pdf_obj *cs = pdf_dict_get(ctx, pdf_page_group(ctx, page), PDF_NAME_CS); | 19:33.55 |
| | pdf_dict_get (etc) are all designed to cope with NULLs on entry nicely. | 19:34.14 |
| mvrhel_laptop | oh ok | 19:34.42 |
| | Robin_Watts: So what is "push_group_for_separations" doing? | 19:39.58 |
| Robin_Watts | That's the thing that you hate :) | 19:40.18 |
| mvrhel_laptop | wait | 19:40.44 |
| | it is not doing it with every drawing is it? | 19:40.53 |
| Robin_Watts | no. "if dev->top == 0" means it only ever runs when we're at the top of the drawing stack. | 19:41.17 |
| | We're only ever at the top of the drawing stack until its run, so it only ever runs once. | 19:41.31 |
| mvrhel_laptop | ok whew | 19:41.45 |
| | I see. | 19:42.49 |
| | So if we are at the top and we are going to want to handle the spots we do the push | 19:43.08 |
| Robin_Watts | yes. | 19:43.36 |
| mvrhel_laptop | And you needed to populate that option in various drawing commands | 19:43.36 |
| Robin_Watts | I don't grok that. | 19:43.50 |
| | If we need to do the push, we need to do it before we do any drawing. | 19:44.11 |
| mvrhel_laptop | yes | 19:44.16 |
| Robin_Watts | and we can't do it before we get default_cs. | 19:44.20 |
| mvrhel_laptop | right | 19:44.28 |
| | my point was I was seeing push_group_for_separations in various spots and it was confusing for me at first | 19:45.17 |
| | but it is like that as you need to do the push with the first drawing command that comes along | 19:45.34 |
| | which could be a tile, or a group, or a mask etc | 19:45.54 |
| Robin_Watts | yes. | 19:45.57 |
| | Any suggestions for neater ways to do it, please say! | 19:46.08 |
| mvrhel_laptop | I do wonder if there is a fair amount of common code initial code among these drawing methods that could be done in a single method | 19:47.27 |
| | But this may be the only one | 19:48.09 |
| Robin_Watts | mostly it's setting up local variables. | 19:48.14 |
| mvrhel_laptop | looks pretty reasonable overall. I am looking forward to it going in a branch and then being able to work on some of the final odd ball cases | 19:51.39 |
| Robin_Watts | ok, I've updated your commit on robin/mvrhel_master, and removed the WIP. | 19:52.16 |
| mvrhel_laptop | There are a few funny cases with gray and cmyk's black as well as interactions with overprint and transparency | 19:52.25 |
| Robin_Watts | Urm... | 19:53.33 |
| | http://git.ghostscript.com/?p=user/mvrhel/mupdf.git;a=commitdiff;h=30891542db7e4cb67e129ca5b9986973c77c6e2a | 19:54.04 |
| | fz_blend_nonseparable is using [n] a lot. | 19:54.28 |
| mvrhel_laptop | hence my question earlier today... | 19:54.48 |
| | well n is where alphas is yes? | 19:55.22 |
| Robin_Watts | Ah, n-= sa :) | 19:55.27 |
| | No, n-1 is where the alphas are :) | 19:55.37 |
| | but n -= sa makes n= n-1, so I'm happy. | 19:55.58 |
| mvrhel_laptop | ha | 19:56.01 |
| | ah n -= sa | 19:57.09 |
| | ok yes. that I found a confusing thing to have been done | 19:57.31 |
| | I think sa is probably always true in this code isnt it? | 19:58.06 |
| | But perhaps I am stuck only thinking of the pdf group case | 19:59.11 |
| Robin_Watts | No, sa is not always true. | 20:00.42 |
| | See fz_blend_pixmap where we call fz_blend_nonseparable. | 20:01.00 |
| | If sal, then sp[n] is valid. | 20:01.47 |
| | likewise if bal, bp[n] is valid. | 20:01.59 |
| | I think you're good. | 20:02.14 |
| | I think fz_blend_nonseparable_gray should be a static inline, not just a static. | 20:04.07 |
| mvrhel_laptop | hmm I am still trying to understand when sa = src->alpha; would be false | 20:04.08 |
| Robin_Watts | mvrhel_laptop: if (src->alpha == 0) { void (*crash)(void) = NULL; crash(); } | 20:05.38 |
| | then clusterpush :) | 20:05.42 |
| mvrhel_laptop | Robin_Watts: Yes about the inline addition | 20:05.43 |
| | Robin_Watts: I may do that... | 20:06.01 |
| Robin_Watts | I'm a bit confused about fz_blend_nonseparable_nonisolated. | 20:08.17 |
| | It looks like we have a _gray and an rgb version. | 20:08.26 |
| mvrhel_laptop | hold on let me look | 20:08.37 |
| Robin_Watts | can we not get cmyk versions? (possibly this is a really dumb question) | 20:08.40 |
| mvrhel_laptop | oh the fz_blend_nonseparable_nonisolated version does rgb and cmyk | 20:09.19 |
| | so cmy is treated the same as rgb | 20:09.25 |
| | and then we have a special handling of k | 20:09.33 |
| | at the bottom | 20:09.38 |
| Robin_Watts | Ah! | 20:10.14 |
| mvrhel_laptop | gray is a bit different enough (and simpler) that I put it in its own | 20:10.15 |
| Robin_Watts | I follow. sorry. | 20:10.23 |
| mvrhel_laptop | np I had to look that up in the spec to make sure I did it right | 20:10.35 |
| Robin_Watts | ok, so I have a revised mvrhel_master on my repo, and my stuff all rebased on top of that. | 20:11.45 |
| | Let's cluster test it, and if it passes, push all your stuff. | 20:12.00 |
| | Does that seem fair? | 20:12.03 |
| mvrhel_laptop | That would be great | 20:12.10 |
| | Did you add the inline? | 20:12.25 |
| Robin_Watts | I did. | 20:12.31 |
| mvrhel_laptop | cool | 20:12.35 |
| Robin_Watts | and I pulled in my version of the halftone reversal rather than yours. | 20:13.02 |
| mvrhel_laptop | great | 20:13.10 |
| Robin_Watts | identical commits, except I removed a comment that was no longer relevant. | 20:13.15 |
| mvrhel_laptop | ok | 20:13.19 |
| Robin_Watts | I'm gonna quit soon, but tomorrow I shall split the big "WIP" commit at the end of my branch out to more reasonable smaller commits. | 20:14.33 |
| mvrhel_laptop | ok. That sounds good | 20:14.53 |
| Robin_Watts | but if you wanted to keep working on top of the WIP it should be easy enough to sort stuff after I do that. | 20:15.01 |
| | so you shouldn't be blocked. | 20:15.12 |
| mvrhel_laptop | ok. Thanks | 20:15.40 |
| | Robin_Watts: did you clusterpush yet | 20:19.00 |
| | I found two issues | 20:19.03 |
| Robin_Watts | I did, but no biggy. | 20:19.39 |
| mvrhel_laptop | ok. In draw-blend.c | 20:19.54 |
| Robin_Watts | memcpy is reversed. | 20:20.22 |
| mvrhel_laptop | around line 576 memcpy(sp, bp, n + 1); should have been memcpy(bp, sp, n + 1); | 20:20.24 |
| | hehe | 20:20.27 |
| | also | 20:20.39 |
| Robin_Watts | and n+1, really? | 20:20.43 |
| mvrhel_laptop | yes.... | 20:21.05 |
| Robin_Watts | n+ min(sal,bal) | 20:21.15 |
| mvrhel_laptop | ok | 20:21.20 |
| | this is where I am having problems with the sal, bal... | 20:21.54 |
| | in any event, if ba was 0 we should copy the source data over | 20:22.22 |
| | and move on | 20:22.28 |
| Robin_Watts | b = the background | 20:22.37 |
| | s = the source (the thing we are blending with the background), IIRC. | 20:22.51 |
| mvrhel_laptop | thieyes | 20:22.56 |
| | yes | 20:22.58 |
| Robin_Watts | hence we want something like... | 20:23.00 |
| | memcpy(bp, sp, n + (sal && bal)); | 20:23.34 |
| | if (bal && !sal) | 20:23.35 |
| | bp[n+1] = 255; | 20:23.37 |
| | (This is why we use the inline thing - so that each call to this function produces unrolled code where all this stuff optimises out) | 20:24.18 |
| mvrhel_laptop | ok. so the above is in the if (ba == 0) section? | 20:24.52 |
| Robin_Watts | Yes. | 20:24.57 |
| mvrhel_laptop | and does the copy with alpha if they both have alpha | 20:25.13 |
| | and only the colors if only one or neither dont have alpha | 20:25.51 |
| Robin_Watts | Urm... | 20:26.00 |
| | it copies the alpha if they both have alpha. | 20:26.07 |
| mvrhel_laptop | memcpy(bp, sp, n + (sal && bal)); | 20:26.23 |
| Robin_Watts | if only the destination has alpha, then the soruce alpha is assumed to be 255, and is copied. | 20:26.24 |
| mvrhel_laptop | copies the color and alpha if they both have alpha | 20:26.46 |
| Robin_Watts | yes. | 20:26.58 |
| mvrhel_laptop | ok | 20:27.01 |
| | then if the background has alpha but the source did not, it sets it to 255 | 20:27.18 |
| Robin_Watts | If we have no destination alpha, but we do have source alpha then the source alpha is dropped. | 20:27.20 |
| mvrhel_laptop | ok | 20:27.24 |
| Robin_Watts | yes. | 20:27.25 |
| mvrhel_laptop | that needs to be done in two spots | 20:27.38 |
| | the fz_blend_nonseparable_nonisolated_gray and the other one | 20:28.11 |
| Robin_Watts | yeah, and there is a tiny C89 fix required too. | 20:28.20 |
| mvrhel_laptop | yes | 20:28.24 |
| | that was the other issue | 20:28.26 |
| | the definition was in the wrong spot | 20:28.35 |
| | around line 643 | 20:29.01 |
| Robin_Watts | OK, new mvrhel_master, clusterpushing now. | 20:30.06 |
| mvrhel_laptop | great | 20:30.26 |
| Robin_Watts | and a new robin/master rebased on top of that... | 20:30.26 |
| mvrhel_laptop | cool | 20:30.30 |
| Robin_Watts | How many diffs are we expecting here? | 20:30.34 |
| mvrhel_laptop | I was getting 4531.... | 20:30.49 |
| Robin_Watts | Same number I got. | 20:30.58 |
| mvrhel_laptop | ok There are progressions on the ghent tests | 20:33.00 |
| | let me see if I can find them | 20:33.09 |
| | oh its still wrapping up | 20:33.50 |
| | I need to go pick up ethan at the bus stop | 20:33.57 |
| | I can look over the bmpcmp if you want when I get back | 20:34.17 |
| | and let you know via email for you in the morning if I see any issues | 20:34.33 |
| Robin_Watts | Thanks. | 20:36.24 |
| malc_ | Robin_Watts: at page 17 of mupdf_explored you have: "To avoid deadlocks, MuPDF guarantees never to take lock n if that thread already holds lock m (for n ¿ m)." what's ¿ ? (Boy do I feel Spanish) | 20:49.46 |
| Robin_Watts | < | 20:52.36 |
| | malc: < i.e. less than. | 20:52.46 |
| | Clearly something has gone wrong with the fonts :( | 20:53.12 |
| malc_ | Robin_Watts: looks that way, thanks | 20:53.22 |
| | page 37 "For embedded systems, or secure applications, the use of a local filing system may be inappropriate...", "filing system"? | 21:10.26 |
| Robin_Watts | mvrhel_laptop: So we get the same number of diffs with the new code (431). | 23:30.06 |
| | mvrhel_laptop: So we get the same number of diffs with the new code (4531) | 23:30.10 |
| | There is 1 SEGV though. | 23:30.22 |
| | I've run a test just of the ppmraw.72.0 and bmpcmp'd it with a threshold of 64. | 23:30.46 |
| | Page 3 of Altona Technical is looking bad. | 23:33.02 |
| | And tests_private/pdf/PDF_1.7_FTS/fts_17_1700.pdf.ppmraw.72.0 looks bad. | 23:35.23 |
| | yeah, something is not right with alpha blending. | 23:36.45 |
| | We can talk about it tomorrow. | 23:36.59 |
| | night. | 23:37.01 |
| marrenarre | Hi. MuPDF does not seem to handle being fullscreened by X that well. | 23:39.42 |
| | When I enable or disable fullscreen in i3 and then try to toggle it by pressing f, nothing happens. It is as if MuPDF did not notice that the state has already been changed and it should be changing it back. | 23:40.59 |
| | I looked in `x11_main.c`, and although I have no experience with programming X applications, it does not seem to me that MuPDF is âlisteningâ for fullscreen events. | 23:42.43 |
| | experience of* | 23:43.29 |
| | I am noticing this behaviour on the development version of `mupdf-x11` and as well as `mupdf-gl`, on a Linux/X system. | 23:45.16 |
| Robin_Watts | marrenarre: It may not be. The guy to ask would be tor8, and he's gone for the night (past midnight in his timezone). | 23:46.01 |
| | Try again tomorrow. | 23:46.04 |
| | OR, feel free to give us a patch. | 23:46.11 |
| marrenarre | I would like to, but I donât know if I could write the correct code having no prior experience with X. | 23:46.50 |
| mvrhel_laptop | Robin_Watts: yes I see that altona issue. looking at it now | 23:49.16 |
| | Forward 1 day (to 2017/07/13)>>> | |
Log of #mupdf at irc.freenode.net.