| | <<<Back 1 day (to 2017/09/20) | 20170921 |
| hatinabunny | yesterday tor8 added a feature: following a link to a destination also scrolls to the coordinates of the uri on page | 08:42.40 |
| | (for internal links) | 08:42.44 |
| kens | Sounds more like honouring a named destination to me | 08:43.03 |
| hatinabunny | the previous behaviour was to stay at the same coordinates as before clicking the link | 08:43.15 |
| | now, if I am zoomed in, and I scroll to the bottom of a page, and then I hit '.' to go to the next page | 08:43.42 |
| | I end up at the bottom of the next page | 08:43.51 |
| | is this a feature? | 08:43.55 |
| | I would expect to move to the top of the next page | 08:44.04 |
| kens | Depends on the named destination. A dest with a null null null rectangle should stay at teh same position on the page, one with a destination rectangle should move to display that rectangle. | 08:44.08 |
| hatinabunny | kens: yes, that is exactly what tor implemented | 08:44.24 |
| kens | But the problem is something else changed as well ? | 08:44.45 |
| hatinabunny | no, it is just that I encountered a 'similar' 'bug'... | 08:45.01 |
| | with the page-up page-down behaviour | 08:45.11 |
| | (talking about mupdf-gl, by the way) | 08:45.19 |
| kens | Ah, well that's a different thing | 08:45.21 |
| | I think you will need to talk to tor about that. | 08:45.32 |
| hatinabunny | ok | 08:45.36 |
| kens | I guess he should be along in a bit | 08:45.48 |
| hatinabunny | I would think that PageDown always moves to the *top* of the next page | 08:46.02 |
| | but, maybe there is a good reason for the current behaviour | 08:46.12 |
| kens | No idea, sorry | 08:46.22 |
| hatinabunny | no problem | 08:46.27 |
| | mupdf is a great tool! | 08:48.19 |
| rammanoj__ | a small doubt of mutool draw how actually to send the output to the stdout for piping | 09:02.06 |
| | I tried this way mudraw -F png filename.pdf 5 | usr/bin/convert -depth 8 - klq.png but it gave error | 09:03.07 |
| | the error is convert: no decode delegate for this image format `' @ error/constitute.c/ReadImage/501. | 09:03.56 |
| | convert: no images defined 'klq.png' @ error/convert.c/ConvertImageCommand/3210. | 09:03.56 |
| | can anyone help me out | 09:04.56 |
| kens | rammanoj__ : we can't give you an answer to questions about errors from convert, we told you that yesterday | 09:50.24 |
| | All I can tell you there is that it 'looks like' convert doesn't know how to read a PNG file. | 09:50.52 |
| | I suggest you go ask these questions on an ImageMagick forum | 09:51.05 |
| tor8 | Ionic: mupdf-x11 has a presentation mode that works like a slide show with transitions | 09:52.24 |
| | if you enable it, you will get a transition effect (usually a cross fade) between pages | 09:52.38 |
| | and it will automatically advance after a couple of seconds | 09:52.52 |
| rammanoj__ | kens: okay thankyou I want to actually know how to give out stdout in mudraw so that it can be used for piping. Actually problem is not of those errors can you say how to give stdout? | 09:53.13 |
| kens | Not me, no | 09:54.00 |
| | In future, probably best you ask the question you want an answer to rather than quoting error messages though | 09:54.21 |
| tor8 | hatinabunny: the pgup/pgdown keys (and , and .) are intended to only change page (since if you've zoomed in to skip the page margins, you probably wouldn't like it scrolling | 09:54.21 |
| | the space and 'b' keys will advance by a screenful and go from the bottom to top and vice versa when going backwards | 09:54.36 |
| | rammanoj__: mutool draw -F png -o - file.pdf 5 | whatever | 09:56.24 |
| | rammanoj__: if you do not specify a file name with -o, mutool will write to 'out.png' | 09:57.02 |
| | ah, no, that's not even true. my bad, sorry. if you don't specify an output filename it won't write any output at all. | 09:59.21 |
| | so you need to specify '-o -' to write to stdout | 09:59.41 |
| rammanoj__ | thankyou it got worked | 10:01.13 |
| tor8 | Ionic: the mupdf-gl and mupdf-x11 viewers are completely separate code bases with different key bindings | 10:16.20 |
| Robin_Watts | tor8: So... suppose I open a draw device, and I send a page to it. | 10:22.11 |
| | Then I send some more stuff to it. | 10:22.21 |
| | Whether or not I want that device to handle overprint or not, is not decided purely by the page contents, but by whether the 'extra' stuff I send uses overprint. | 10:22.58 |
| | Thus the 'overprint or not' information can't come purely from the act of running the page. | 10:23.17 |
| tor8 | what would this 'extra stuff' be? | 10:23.25 |
| Robin_Watts | tor8: Any other device calls I feel like. | 10:23.36 |
| | I reckon I want a 'fz_page_uses_overprint' call. | 10:24.00 |
| tor8 | as a device call or something to set up the draw device? | 10:24.26 |
| Robin_Watts | not as a device call. | 10:24.37 |
| tor8 | okay, something to feed/use to set up the draw device then | 10:24.52 |
| Robin_Watts | The caller can then choose to pass in a pixmap for overprint or not when it creates the device. | 10:24.58 |
| | yes. | 10:25.00 |
| tor8 | that the caller (mudraw in this case) would use | 10:25.06 |
| | sounds good to me. | 10:25.13 |
| Robin_Watts | yes. | 10:25.13 |
| | cool. | 10:25.17 |
| tor8 | I like that better than the automatic pushing an overprint sim group in the draw device | 10:25.54 |
| Robin_Watts | tor8: The draw device will still "automatically" push an overprint sim group, if the incoming pixmap signals that it should do so. | 10:26.58 |
| | The push of the extra group has always been triggered by the callers request for overprint sim. | 10:27.19 |
| | (if the pixmap supplied has an fz_separations object) | 10:27.50 |
| tor8 | okay. then I'm not sure I understand exactly what you're proposing. | 10:28.43 |
| Robin_Watts | Let me get you a commit to look at. | 10:29.00 |
| hatinabunny | tor8: thanks! I'll use Space and 'b' henceforth | 11:24.36 |
| tor8 | hatinabunny: space and b also work if you have multiple columns and have zoomed in so only one is visible | 11:25.16 |
| hatinabunny | aah, cool | 11:27.49 |
| | tor8: didn't know that | 11:27.54 |
| | let me test | 11:27.56 |
| | tor8: wow! that is really cool and useful | 11:30.31 |
| | especially in the document I'm working on now | 11:30.40 |
| | lots of pages with a 4:3 layout (like slides) and then a landscape A3 in between | 11:31.12 |
| Robin_Watts | tor8: Top commit on robin/spots does what I want, I think. | 13:19.11 |
| tor8 | Robin_Watts: right, so overprint simulation only happens if we have a separations object to the draw device | 13:32.44 |
| | and this checks the page for overprint and creates an empty separations in order to force overprint simulation groups to be pushed | 13:33.12 |
| | 1) pdf_page_uses_overprint might be a better name | 13:34.37 |
| | 2) pdf_obj_memo2? ... why not change pdf_obj_memo to be: int pdf_obj_memo(ctx, obj, int bit, int *value) and have an enum PDF_OBJ_MEMO_USE_BM=1, PDF_OBJ_MEMO_USE_OP=2 for our two uses | 13:35.39 |
| Ionic | tor8: ah, so it doesn't actually go into fullscreen and enables stretching... okay, that's interesting to know | 13:35.52 |
| Robin_Watts | tor8: uses_overprint or has_overprint ? | 13:37.52 |
| | uses_overprint, I think, yes. I agree. | 13:38.06 |
| tor8 | Robin_Watts: either one, but I think uses is clearer | 13:38.12 |
| Robin_Watts | pdf_obj_memo2 is ugly, yes. | 13:38.21 |
| | I would be inclined to lose pdf_obj_memo entirely in favour of pdf_obj_memo_bm and pdf_obj_memo_op | 13:38.54 |
| | we need 2 bits for each 'memo'. | 13:39.23 |
| tor8 | Hey! Who are you and what did you do to Robin? | 13:39.23 |
| | :) | 13:39.32 |
| | I've never seen you propose more functions when a bit flag could be used :P | 13:39.45 |
| Robin_Watts | 1 to say it's set, and 1 to say what it's set to. | 13:39.46 |
| | yeah, just messing. Let's go back to what you said. | 13:39.59 |
| tor8 | separate memo_bm and memo_op calls sounds good to me. | 13:40.09 |
| Robin_Watts | why int *value ? | 13:40.12 |
| tor8 | the current one has an int *memo | 13:40.34 |
| | out-parameter | 13:40.36 |
| Robin_Watts | tor8: Ah, that's the reading one. gotcha. | 13:40.55 |
| | will fix. | 13:41.15 |
| | But you're happy with the overall shape? | 13:41.22 |
| tor8 | I think a flag for which memo to use would be fine | 13:41.36 |
| | just make sure to multiply it by two :) | 13:41.48 |
| | since we'd end up with set_obj_memo_bm and set_obj_memo_op as well as the getters | 13:42.19 |
| Robin_Watts | yeah... | 13:42.33 |
| tor8 | yes, if my understanding above was correct I'm good with the shape | 13:46.47 |
| | I was fearing we'd end up pushing overprinting groups even when there were no overprinting on the page | 13:47.32 |
| Robin_Watts | tor8: No, the intention of this is to prevent exactly that. | 13:51.21 |
| tor8 | Robin_Watts: yup. I see that now. | 13:51.37 |
| | and thus approve! | 13:51.44 |
| Robin_Watts | We *will* push the extra group if there is an output intent that doesn't match the output devices space. | 13:51.53 |
| tor8 | the only question I have remaining is what happens when a naive user doesn't set up a separations object and just draws to a plain pixmap | 13:52.51 |
| | like our non-mudraw viewers and tools | 13:53.02 |
| | do we get any sort of overprint simulation then too, or do we just default to 'nope, not gonna do that'? | 13:53.25 |
| Robin_Watts | exactly. | 13:59.21 |
| | (the latter) | 13:59.48 |
| | Updated commit on robin/spots | 14:13.09 |
| tor8 | Robin_Watts: looking better. still the name of the fz_page_overprint function, and you've got a thirdparty/jbig2dec submodule update mixed in as well | 14:23.15 |
| | but I still need to go over the other commits on robin/spots | 14:23.25 |
| Robin_Watts | tor8: ass. Thanks. | 14:23.26 |
| | sure. | 14:23.30 |
| tor8 | the first one I've commented on before, it needs a bit of cleaning up | 14:23.37 |
| Robin_Watts | My latest change makes lcms cry in the cluster. I'm trying to figure out why. | 14:24.07 |
| | (I mean, it's being tickled to run in more cases than before, so it's understandable that problems have appeared *now*, I just don't know why they've appeared :) ) | 14:24.49 |
| | Can you reiterate your comments, if you can remember them? | 14:25.11 |
| tor8 | Robin_Watts: how do you feel about adding a colorspace->c and pixmap->c field that has number of process colorants (so we don't have to do the n=pix->n - pix->s - pix->alpha dance) | 14:25.28 |
| | Robin_Watts: that would be difficult, it was before the meeting :) | 14:25.39 |
| | https://ghostscript.com/mupdfirclogs/2017/09/12.html towards the bottom (search for "Logic for Sep") | 14:26.37 |
| Robin_Watts | tor8: I wouldn't want to add 'c'. | 14:26.38 |
| | colorspace->n == c. | 14:26.52 |
| | so for colorspaces it's a bad idea. | 14:26.58 |
| tor8 | oh right, I was thinking of pixmaps. for colorspaces it's different. | 14:27.18 |
| Robin_Watts | for pixmaps, we *could* add it, but a) all it saves is the the subtraction, b) it costs us an extra int cos we have no space left in the struct, and c) I'd need to assert it was correct everywhere :) | 14:27.45 |
| tor8 | I'm irked by how we have 's' for 'spots' and 'alpha' for 'a' | 14:27.51 |
| Robin_Watts | You would prefer 's' and 'a' or ('spots' and 'alpha') | 14:28.24 |
| tor8 | c) is the killer for me :) | 14:28.25 |
| | I would. | 14:28.31 |
| Robin_Watts | I could change 's' to spots. | 14:28.48 |
| tor8 | Robin_Watts: gotta go, back in a couple of hours. | 14:29.48 |
| Robin_Watts | cu. | 14:29.53 |
| | tor8: For the logs: I am confused. The changes you asked for in "Logic for Sep and DeviceN", were all in the commit message. I've done them. | 15:14.36 |
| | The other changes (to the colorspace flags enum values), I've also done. | 15:16.12 |
| tor8 | Robin_Watts: ah, my bad. | 22:52.24 |
| Robin_Watts | tor8: no worries, just wasn't sure there wasn't stuff I'd missed :) | 22:59.11 |
| tor8 | it's a bit late now. will continue reviewing tomorrow. | 23:00.52 |
| | Forward 1 day (to 2017/09/22)>>> | |
Log of #mupdf at irc.freenode.net.