| | <<<Back 1 day (to 2018/01/25) | 20180126 |
| Robin_Watts | sebras: Ah, right. | 00:00.22 |
| | Yeah, separate textures isn't going to work if you want to get blends correct. | 00:00.44 |
| kens | tor8 sebras, that recent bug report (698927) does seg fault for me. Its in std_conv_color() because srcs->to_ccs is NULL | 14:46.21 |
| sebras | kens: there's a assert that gets triggered for me. | 14:48.42 |
| kens | Yes there is | 14:48.48 |
| | Same problem though | 14:48.51 |
| | the source sand destination colour spaces have their to_ccs and from_ccs set to 0 | 14:49.37 |
| | Looks like a Michael problem to me | 14:49.49 |
| | I don't know enough to look any further | 14:49.57 |
| | Could be a problem to do with display lists, since that is where the source colour space at least is set | 14:50.47 |
| | Ah, its sets colorspace to fz_keep_colorspace(ctx, fz_device_gray(ctx)); at that point the to_ccs and from_ccs are both NULL | 14:51.43 |
| | All of teh ctx->colorspace->* spaces are like that | 14:52.38 |
| sebras | kens: yes, I just found that too. | 14:53.10 |
| | and we're doing gray -> rgb conversion. | 14:53.19 |
| kens | CalRGB but yes | 14:53.27 |
| sebras | CalGray -> CalRGB. | 14:53.43 |
| kens | Yeah | 14:53.46 |
| | At this poitn I put up my hands and say 'not my problem' | 14:53.59 |
| sebras | kens: it's not. | 14:55.44 |
| kens | Possibly there should be some default ICC profiles or something in those initial spaces. | 14:55.45 |
| | My head hurts from looking at TrueType, I need distractions.... | 14:56.12 |
| sebras | these are the default ICC profiles, but why the to_/from_ccs pointers are NULL I don't know. | 14:56.17 |
| kens | I couldn't possibly comment :-) | 14:56.27 |
| | Like I said, possibly one for Michael | 14:56.34 |
| sebras | Robin_Watts: mvrhel: https://bugs.ghostscript.com/show_bug.cgi?id=698927 I did my best. | 15:28.26 |
| Robin_Watts | sebras: yeah, for michael. | 15:29.13 |
| sebras | Robin_Watts: should I assign him? | 15:29.49 |
| Robin_Watts | sebras: I suspect that would be best. he can kick it back to someone else if he's too busy (I know he has a lot on his plate at the moment) | 15:35.51 |
| kens | Yeah I don't think the suggested patch from the reporter is good | 15:36.44 |
| Robin_Watts | mvrhel_laptop: Hey. A MuPDF color conversion bug has just come in. | 15:38.55 |
| sebras | mvrhel_laptop: I took a stab at the analysis, I hope it helps. | 15:51.50 |
| enometh | chrisl, if you cant address the issue do you resort to kicking and pretend there is no problem? | 17:15.49 |
| chrisl | enometh: I warned you about your language and attitude | 17:16.30 |
| enometh | what? have i not been polite? | 17:16.40 |
| chrisl | Referring to us as a "racket" is *not* polite | 17:17.10 |
| enometh | i'd be glad not to refer to it , but consider the scrollback | 17:17.30 |
| sebras | this channel is for discussing mupdf. if there is a bug in ghostscript or some of its tools, please report that in ghostscript's bugzilla over at bugs.ghostscript.com or try to have a civilized discussion over at #ghostscript. having heated discussions spill over to #mupdf helps no one. | 17:24.47 |
| enometh | i have a series of mupdf patches | 17:25.02 |
| | most of them are tied to the x11 ui though | 17:25.53 |
| sebras | enometh: ok, those are also best provided to us via bugzilla. | 17:25.56 |
| enometh | one introduces ipc to replace the displayed pdf in the same process | 17:26.39 |
| sebras | enometh: ok, that sounds like a rather large patch. and probably one where you need to explain why this feature is necessary (so as to motivate why a new ipc dependency(?) is warranted). | 17:28.45 |
| enometh | to do xpdf -remote | 17:28.55 |
| | xpdf uses x11 for the ipc | 17:29.08 |
| | this just uses a pipe. my concern is it may be leaking somewhere.. | 17:29.26 |
| | i see xpdf is no longer motif, i wonder what it does now. | 17:30.05 |
| | looks like they dropped the option | 17:30.31 |
| sebras | enometh: so this is meant to have mupdf-x11 showing one document and then from say a makefile or command line run a command to trigger mupdf-x11 to show another file..? | 17:31.49 |
| enometh | yes thats all | 17:32.05 |
| | all the other patches are x11 ui | 17:32.56 |
| malc_ | hmm... xpdf gained qt ui.. | 17:33.22 |
| enometh | the only things of interest may be "`" to jump back and forth like in vi, optional "smart" scrolling like xpdf did by default, numeric arguments to most commands, and one fix for hjkl for contiguous scrolling. | 17:36.52 |
| | smart means pagedown goes down, then moves right | 17:37.14 |
| sebras | enometh: have you tried mupdf-gl? | 17:38.19 |
| enometh | yeah, easier to implement outlines | 17:38.44 |
| | hehe | 17:38.46 |
| sebras | enometh: mupdf-x11 has had very few updated in later years as development has gravitated towards mupdf-gl. | 17:39.47 |
| enometh | oh, and search, so it highlights all matches on a page and jumps through them on next | 17:39.56 |
| sebras | Robin_Watts: can I trouble you with a single commit review on sebras/master? the sanitize make target would be beneficial to me, so I don't want to wait for tor8. :) | 17:41.35 |
| Robin_Watts | sebras: looking | 17:41.46 |
| | sebras: With the obligatory gripe that only Americans spell sanitize that way, sure, lgtm :) | 17:43.33 |
| sebras | Robin_Watts: hey, at least it is not zanitize! | 17:43.58 |
| | Forward 1 day (to 2018/01/27)>>> | |
Log of #mupdf at irc.freenode.net.