| | <<<Back 1 day (to 2018/09/11) | 20180912 |
| delrier | sebras: not seeing that error, I am however getting "error: invalid page object" and "warning: assert: overwrite hash slot with different value!" | 07:29.39 |
| sebras | delrier: ok, I might have found something in the code that fixed my issue, it's awaiting review. | 08:13.58 |
| | delrier: can you please report a bug for the error message about the hash slot and attacah the PDF that induces the error? | 08:14.29 |
| delrier | sebras: it's in the same file as i attached to bug 699750, however I cant seem to reliably get the error on the same page | 08:59.10 |
| | sebras: i have also attached 2 new pictures from the same pdf in the issue showing the bug with black & white | 08:59.26 |
| tor8 | sebras: "Set colorspace bgr flag also for ICC colorspaces." LGTM | 10:31.35 |
| | but I'd rephrase the message as "Set the profile BGR flag for non-default ICC colorspaces too." | 10:33.50 |
| | sebras: and if you're happy with the cluster diffs from the freetype update, go ahead and push that too | 10:34.23 |
| sebras | tor8: I am, thanks! | 10:38.12 |
| tor8 | sebras: tor/master has 3 commits for review if you got a minute | 10:42.05 |
| Robin_Watts | OK, sebras, this painting problem... | 10:58.33 |
| | Can you point me at the file/invocation that shows the problem please? | 10:58.55 |
| | sebras: That patch looks plausible to me. Without being able to capture it in the debugger here, I can't see how that causes the problem we're seeing though, but it seems like it should be harmless to me. | 11:10.16 |
| moolc | i'll be damned... yet another ghostscript update... the distro maintainers of gs are on crack or something | 12:06.02 |
| kens | We rolled out a new Release Candidate the other day | 12:06.24 |
| | Because we had to hurry 9.24 there were some problems with it | 12:06.36 |
| moolc | kens: there were _6_ gs 9.24 updates pushed on unsuspecting users of this linux distribution.. | 12:07.33 |
| kens | Well, that wasn't our fault :-) | 12:07.47 |
| | We only did one 9.24 release and one 9.25 release | 12:08.02 |
| | I assume the maintainers picked up interim commits | 12:08.13 |
| moolc | kens: it wasn't! | 12:08.47 |
| | kens: i assume their smoke some serious shit | 12:09.01 |
| | -r | 12:09.07 |
| kens | Well this is the sort of thing that happens when people go public with problems, instead of sensible reporting | 12:09.28 |
| moolc | appears so.. anywho | 12:14.53 |
| sebras | Robin_Watts: can I bother you with helping me to look at 58def9ec2 on sebras/wip? | 16:00.59 |
| | Robin_Watts: that's the patch I was discussing yesterday. | 16:01.05 |
| | Robin_Watts: in some functions you use op in other eop for the fz_overprint* argument. | 16:01.29 |
| | Robin_Watts: and some times you check if eop or op == NULL and somtimes you call fz_overprint_required(). | 16:02.00 |
| | Robin_Watts: I'm not quite sure how to differentiate these two cases. | 16:02.11 |
| | so I'm a bit uncertain about my commit. | 16:02.25 |
| kens | sebras whether op or OP is set maybe ? | 16:02.39 |
| Robin_Watts | eop = effective overprint, I believe. | 16:03.20 |
| | and !fz_overprint_required(op) is better than op == NULL in all cases, I think. (suspect, hope) | 16:03.46 |
| sebras | Robin_Watts: as far as I understand fz_overprint_ | 16:04.05 |
| | required() does the NULL test too, but it is more stringent to return a true value. | 16:04.37 |
| Robin_Watts | fz_overprint_required(op) returns true in a subset of the cases that (op != NULL) does. | 16:05.24 |
| sebras | Robin_Watts: yes, perhaps it is just easier for me to whip up a potentially incorrect patch and have you look it over than try to understand the difference between those two cases. | 16:07.42 |
| Robin_Watts | sebras: In general op == NULL means, (I think) that "no one has specified overprinting". | 16:08.10 |
| | whereas people might have specified overprinting, but have set the bits to mean that nothing gets overprinted. | 16:08.30 |
| | (which is effectively the same thing) | 16:08.45 |
| | so fz_overprint_required is just a test that captures both those cases in one. | 16:09.11 |
| | (Did that make sense?) | 16:09.15 |
| sebras | Robin_Watts: in the second case there is overprinting info but it is actively disabled, while in the first case there is no overprinting info. | 16:09.50 |
| | so if I find that we test eop somewhere it'd better be fz_overprint_required(). | 16:10.15 |
| | and the fz_overprint* argument toi most functions should be named eop, and only op when the stack allocated fz_overprint buffer is actually supplied. | 16:11.01 |
| Robin_Watts | Well, my hope was that in the event that we ever didn't use the 'simple' code for "op == NULL", and fell through to the slower code that copes with overprinting, that the results should be the same as the slower case if overprinting is disabled at the component level. | 16:11.48 |
| | eop vs op has more meaning than that, I think. | 16:12.16 |
| | ok, so look at: fz_draw_fill_image | 16:15.30 |
| | That gets op passed into it. | 16:15.35 |
| | eop is initially set to the same thing. | 16:15.45 |
| | If color_params isn't defined, or color_params->op == 0, then eop is made NULL. | 16:16.20 |
| | Then when we convert_pixmap_for_painting, we fill eop in. | 16:17.10 |
| | using set_op_from_spaces | 16:17.47 |
| | I'm sure there was a time I almost understood all this :( | 16:18.53 |
| sebras | looking | 16:19.47 |
| | ok.. but then we call fz_paint_image() | 16:22.50 |
| | which really is fz_paint_image_imp() | 16:22.58 |
| | where we in the case of FZ_PLOTTERS_RGB just checked if eop is set. | 16:23.17 |
| | i.e. a NULL-check | 16:23.31 |
| | how can I determine that this check ought to be fz_overprint_required()? | 16:23.47 |
| | I believe that to be true, but I'm not convinced. | 16:23.58 |
| | I do see that fz_paint_affine_g2rgb_lerp() and fz_paint_affine_g2rgb_near() do not take any eop. | 16:25.01 |
| | while the remainder of the paintfn do. | 16:25.23 |
| | well, functions that return paintfn. | 16:26.02 |
| | perhaps that logic is enough. | 16:26.08 |
| Robin_Watts | only subtractive spaces need overprint. | 16:28.35 |
| | hence g2rgb plotter don't need them, I think. | 16:29.07 |
| sebras | Robin_Watts: have a look at fz_paint_glyph_solid() and fz_paint_glyph_alpha() | 16:29.10 |
| | both call fz_overprint_required() for the eop argument, that seems sane to me. | 16:29.38 |
| Robin_Watts | Yes. | 16:29.53 |
| sebras | in fz_paint_glyph() if dst->colorspace == NULL we check if eop == 0 | 16:29.57 |
| | shoudl that be fz_overprint_required()? | 16:30.05 |
| | inside the assert. | 16:30.07 |
| | oh, and why not == NULL¿ :) | 16:30.32 |
| Robin_Watts | eop was probably originally an int. | 16:30.43 |
| sebras | yes, I think that's where these issues stem from. | 16:30.59 |
| Robin_Watts | But yes, that should probably be fz_overprint_required. | 16:30.59 |
| sebras | Robin_Watts: ok, I think I understand this a bit better now. thanks for the hand holding. | 16:31.42 |
| | Robin_Watts: I'll return with a patch later. :) | 16:31.49 |
| Robin_Watts | sebras: Thanks for (once again) tidying up my mess. | 16:31.56 |
| sebras | Robin_Watts: no worries, this is due to delrier reporting a bug and me finding something similar while looking at the j2k specs. | 16:32.55 |
| chrisl | tor8: ping | 16:49.02 |
| tor8 | chrisl: yes? | 17:19.23 |
| chrisl | tor8: I sent you an email - just saying that the website git repos have moved to /home/git-private/web/* | 17:20.35 |
| tor8 | chrisl: right. | 17:22.24 |
| | I see you've updated the post-update hooks as well, thanks. | 17:22.50 |
| chrisl | Yeh | 17:22.58 |
| | But now you know to shout at me if anything doesn't work | 17:23.31 |
| xHire | hello! :·) I wanted to ask: how can I copy text from a PDF? In 1.11, I just used right mouse button, selected the text and that was it. This doesnât work in 1.13. Is there any trick, shortcut, configuration option or something? | 18:15.22 |
| | I looked into the bugzilla, but there isnât anything related to this. | 18:15.45 |
| sebras | xHire: are you using mupdf-gl? | 18:16.58 |
| | or mupdf-x11? | 18:17.14 |
| xHire | no, mupdf-gl | 18:17.31 |
| | Iâll try the other one | 18:17.41 |
| | cool, x11 works! | 18:18.33 |
| | sebras: thanks a lot! :·) | 18:18.41 |
| sebras | xHire: yes, there's probably a bug in mupdf-gl. | 18:18.42 |
| xHire | the selection behaves a little bit differently from 1.11 (the black rectangle doesnât disappear after releasing the right button), but it does what I expect it to do :·) | 18:19.33 |
| sebras | xHire: if you use mupdf-gl I think it copies the text to the clipboard, meaning you can e.g. paste it in chrome/firefox using Ctrl-V | 18:19.51 |
| | but you can't middle click in a terminal to paste. | 18:19.58 |
| xHire | sebras: I tried both | 18:20.03 |
| sebras | ah, I get Ctrl-V to work, but not middle clicking, i.e. mupdf-gl copies to the CLIPBOARD, but not to the PIRMARY selection buffer. | 18:20.38 |
| xHire | I even tried pressing Ctrl-C while holding right button (i.e., while the text was selected) and even after releasing it (when the selection disappeared), but didnât work | 18:20.42 |
| sebras | I think I saw a patch for that somewhere, but I can't find it this second. | 18:20.53 |
| xHire | I guess Iâm fine with -x11 :·) | 18:23.59 |
| | I never new there are two versions | 18:24.28 |
| | *knew | 18:24.31 |
| moolc | sebras: the selection mechanism in x11 is underbar[1] as http://keithp.com/~keithp/talks/selection.ps shows us ([1] been watching an english movie by german director with swedish subtitles and found it peculiar how close .se word for that is to .de) | 18:24.49 |
| sebras | xHire: are you building mupdf-gl from source? | 18:26.31 |
| xHire | sebras: yes, on Gentoo | 18:26.41 |
| sebras | xHire: if you open platform/gl/gl-main.c you should be able to find ui_set_clipboard() | 18:27.06 |
| | xHire: in it you'll find glutSetClipboard(GLUT_CLIPBOARD, buf); | 18:27.17 |
| | xHire: add a line glutSetClipboard(GLUT_PRIMARY, buf); below it and recompile. | 18:27.42 |
| | xHire: tor8 added this in a mupdf-gl ui cleanup with a bunch of other stuff. | 18:28.13 |
| | xHire: this will be part of the next release. | 18:28.19 |
| | xHire: does that work for you? | 18:29.36 |
| xHire | sebras: OK, will try, thank you! :·) (right now, Iâm still in the middle of updating qtwebengine, so probably tomorrow or over the weekend) | 18:30.10 |
| sebras | xHire: sure, if you encounter issues you know where to find us. | 18:30.34 |
| xHire | I think Iâll stay for a while :·) | 18:30.56 |
| | oh, btw, when I have this opportunity: I love mupdf and mutools, theyâre awesome! :·) | 18:32.20 |
| sebras | xHire: I'll make sure to let tor8 know (he's started both projects). | 18:34.52 |
| xHire | sebras: thanks! ⥠| 18:35.04 |
| | Forward 1 day (to 2018/09/13)>>> | |
Log of #mupdf at irc.freenode.net.