| | <<<Back 1 day (to 2019/02/11) | 20190212 |
| ator | sebras: did he wrap the same C++ pointer in multiple JS objects? | 09:58.40 |
| | yep, he did :) | 10:04.58 |
| | thanks for looking | 10:05.11 |
| sebras | ator: no worries. | 11:04.55 |
| | ator: did you have any response on the patches for mujs and mupdf? | 11:07.30 |
| ator | the first two (that I've put on tor/master) LGTM | 11:07.50 |
| | not convinced we want a pkg-config file. we'll just get conflicting bug reports/change requests from each distro. | 11:08.13 |
| sebras | we had one for mujs, hence me adding one. | 11:08.29 |
| ator | I almost regret adding the one in mujs | 11:08.41 |
| sebras | one curious thing for mujs though: we are creating a .so!?!?!?!!?!?!?!1 | 11:08.42 |
| ator | yes. the mujs API is *supposed* to be stable enough for a .so, and it doesn't have a bazillion third party dependencies. | 11:09.14 |
| sebras | it still surprised me quite a bit! :) | 11:10.12 |
| ator | mujs doesn't have *any* user-visible structs. it's all functions. | 11:10.36 |
| sebras | right, taking DESTDIR into account for that pkg-config is vital though. | 11:11.07 |
| | in mujs | 11:11.10 |
| | without it the paths will be wrong if you install with make DESTDIR=/tmp/mujs install e.g. | 11:11.25 |
| ator | ok. I've never personally used the .pc file. | 11:12.07 |
| sebras | I used it while trying to compile this ChemWiz thing. | 11:12.24 |
| ator | so I guess it should be $(DESTDIR)$(libdir) in the mujs.pc creation script too then? | 11:12.25 |
| sebras | creation script? wasn't it all done in the Makefile? | 11:12.45 |
| ator | creation *recipe* then :) | 11:12.59 |
| sebras | yes, but isn;t that what I put in mujs:sebras/master? | 11:13.33 |
| | perhaps I'm missing something there. | 11:13.50 |
| | ? | 11:13.52 |
| ator | oh, I've noly looked at your mupdf master | 11:14.32 |
| | sebras: that patch however will lead to stale builds. DESTDIR can change from one makefile invocation and another and not rebuild the mupdf.c | 11:14.57 |
| | mujs.pc | 11:15.00 |
| | sebras: fixed version on mujs tor/master | 11:16.33 |
| sebras | oh, I see. | 11:18.06 |
| | also I noticed we are not installing the .so file. did you mean NOT to do that? | 11:18.56 |
| | I think the .private things are sufficient to support both types of libraries. | 11:19.46 |
| ator | the default is to build (and install) the static library only | 11:19.47 |
| | if you want shared, there are separate targets for that | 11:19.55 |
| | make shared && make install-shared | 11:20.41 |
| sebras | so there is. | 11:21.10 |
| | I ought to test that the pkg-config file works with both. | 11:21.20 |
| ator | I just updated the DESTDIR commit, to simplify a bit | 11:21.33 |
| sebras | paulgardiner: good afternoon paul! | 11:21.36 |
| sebras | fetches | 11:21.45 |
| paulgardiner | hi all | 11:21.49 |
| ator | hi paulgardiner | 11:21.51 |
| | so, I've been poking around a bit more in the forms and event handling guts | 11:22.07 |
| sebras | ator: mujs:tor/master LGTM. | 11:22.21 |
| ator | I think how we handle the AA/K event is not quite right | 11:22.23 |
| | sebras: thanks. | 11:22.26 |
| paulgardiner | I can't remember what AA/K is related to | 11:23.07 |
| ator | paulgardiner: we should be feeding it event.change, event.selStart, event.selEnd, and looking at those when it pops back | 11:23.10 |
| | the keystroke event | 11:23.15 |
| | the one you trigger with setTextValue | 11:23.22 |
| | paulgardiner: don't shriek in horror, but I've got some work in progress stuff on the forms I want you to eventually take a look at and provide some input | 11:23.55 |
| | I've been filling out the various JS event triggers and cleaning up a bit of the event handling | 11:24.26 |
| | which does away with the pdf_pass_event stuff in favor of more explicit events | 11:24.56 |
| | paulgardiner: I also want to change/extend the 'event' passing back to the app, to handle more of the javascript requests (like getting and changing the current page, etc) | 11:27.48 |
| | turning the pdf_doc_event stuff into a pdf_js_event_handler struct with a lot of function pointers the JS can call out to instead of the event-type enum | 11:28.21 |
| sebras | ator: I just verified that yes indeed the pkg-config works for both shared and static libraries. nice. | 11:28.52 |
| paulgardiner | Ah yes, I remember AA/K now. IIRC, handling selStart and selEnd didn't seem appropriate when using a native text widget | 11:29.24 |
| ator | paulgardiner: yeah. I think we *may* get away with passing it one change event just before validating. | 11:29.49 |
| | paulgardiner: that has the whole field in it | 11:29.57 |
| | as a 'paste' event type of thing | 11:30.02 |
| | but we should be setting and reading the event.change property (which we don't have at all now) | 11:30.23 |
| | so I wanted to prod you a bit if you've got any ideas for how you want this feature exposed to your code | 11:30.52 |
| | pdf_set_field_value runs through the AA/V validator before changing the value | 11:31.55 |
| paulgardiner | Calling back into the app could be a big problem on mobile. We have to perform rendering in the background and hence most every thing else. To call back in to the app, we have to post to the UI thread and wait. That means we end up having sometimes UI thread waiting on the background, sometimes vice versa, and hence deadlock. | 11:32.03 |
| ator | but only does it for text fields, not for choice fields (which we ought to) | 11:32.09 |
| | paulgardiner: yeah, I'm thinking if the callbacks are null we can just not call them and return 'undefined' to the JS code | 11:32.41 |
| | but they ought to be there somewhere | 11:32.48 |
| | that bit isn't very urgent. I think it's more important to fix the AA/K, AA/V and E/X/D/U/Bl/Fo stuff first | 11:33.33 |
| | paulgardiner: an unrelated question -- do you call pdf_set_text_annot_position? | 11:35.55 |
| | or is that one of these leftovers that aren't used by anyone | 11:36.02 |
| paulgardiner | Also the proper handling of AA/K would need to be performed on the UI thread: otherwise iOS is going to get very upset if the reported back JS-driven changes come back asynchronously. | 11:36.23 |
| ator | paulgardiner: at the moment, I believe you are calling pdf_text_widget_set_text for each keystroke, but you're inhibiting events while editing | 11:39.29 |
| paulgardiner | ator: I don't believe I use pdf_set_text_annot_position, but that and pdf_create_widget must have been created for some reason. Maybe worth using git blame. I wonder whether once our JS Dom implementation used them. | 11:39.34 |
| ator | so the actual AA/K only gets called when you turn off the inhibitor at the final call when the user hits 'enter' | 11:39.49 |
| | right? | 11:39.51 |
| paulgardiner | Yep. | 11:40.09 |
| ator | paulgardiner: could be from the old android app | 11:40.17 |
| paulgardiner | I can't think why the old android app would call those | 11:40.39 |
| ator | paulgardiner: I dug through the history, and I couldn't find a single user of pdf_create_widget | 11:41.13 |
| paulgardiner | Sorry, i have to go. Back in probably an hour. | 11:41.14 |
| ator | paulgardiner: okay. | 11:41.32 |
| paulgardiner | ator: but how about the checkin comment for the commit that added it. | 11:41.39 |
| | You changed the JS dom considerably. Perhaps you removed the one use of it. | 11:42.05 |
| ator | I don't think I removed any of the JS dom calls | 11:43.04 |
| | paulgardiner: you added the pdf_set_text_annot_position function back in 2014, but never called it | 11:44.55 |
| | nor did the android app | 11:45.08 |
| paulgardiner | Whatever the reason, the commit that added the call would be the place to look. Good or bad, there had to be a reason for adding it. | 11:45.11 |
| | Oh okay | 11:45.20 |
| ator | maybe you thought you'd need it later but never got around to it? :) | 11:45.28 |
| paulgardiner | Strange. | 11:45.48 |
| | Must have been intended for the dom. Anyway that clears it up. | 11:46.18 |
| | ator: oops, there is a call to pdf_set_text_annot_position in MuSO... But perhaps there is a more general function that could replace it? | 12:37.02 |
| ator | pdf_set_annot_rect is what I use in mupdf-gl | 12:38.02 |
| paulgardiner | How do you know that size to use? | 12:38.29 |
| ator | I keep the old size :) | 12:38.54 |
| | se do_edit_icon down by the 'Commit movement on mouse-up' comment | 12:39.10 |
| paulgardiner | So does pdf_create_annot set the size and you can then interrogate it? | 12:40.35 |
| ator | yes. pdf_create_annot sets it up with a default rect near the top left of the page. | 12:41.25 |
| | paulgardiner: urgh. this event madness is quity tricksy. | 12:42.09 |
| paulgardiner | Okay, that wont hurt to change in MuSO. | 12:42.26 |
| ator | seems like it always does a final 'K' event with no change and no selection before the 'V' event | 12:42.32 |
| | but also a 'K' event with a selection, in order to allow the JS to change the text | 12:42.56 |
| | so I'm thinking, if you want to avoid calling the K event for each keystroke, we need to: | 12:43.12 |
| | 1) call K with willCommit=false, change=new-text selStart=0 selEnd=end-of-old-text | 12:43.34 |
| | 2) call K with willCommit=true, change="", selStart= | 12:43.42 |
| | -1 selEnd=-1 | 12:43.47 |
| | 3) call V with willCommit=true | 12:43.54 |
| | 4) call C (if required) | 12:44.02 |
| paulgardiner | The move to more explicit handling of events, rather than using pdf_pass_event, sounds good, but it might be a really bad time for API changes in that area. | 12:44.10 |
| ator | 5) call F (to format for printing) | 12:44.10 |
| | paulgardiner: you about to do a release? | 12:44.30 |
| paulgardiner | Quite possibly. | 12:44.45 |
| ator | I can keep working on a branch for a while longer | 12:44.55 |
| | but the longer we wait, the more pain all at once :) | 12:45.01 |
| paulgardiner | You think? | 12:45.18 |
| ator | you choose: death by a thousand cuts, or a giant blow to the head... | 12:45.38 |
| paulgardiner | Either sounds attractive. :-) | 12:46.10 |
| ator | paulgardiner: if you look on tor/master, all but the final WIP are fairly minor cosmetic changes that shouldn't affect behaviour | 12:48.10 |
| | if you and fredross-perry don't mind taking those on, it would be a good first step | 12:48.31 |
| | the biggest change is having a separate iterator for annotations and widgets | 12:48.52 |
| | so the code doesn't need to keep checking 'is this a widget or is this an editable comment' all the time | 12:49.09 |
| paulgardiner | Did I not put in a separate iterator for widgets? Or do you mean you keep them in separate lists? | 12:50.20 |
| ator | I keep them in separate lists | 12:50.29 |
| | but yes, you did have a separate iterator which helped for widgets (but not annotations, cause that one still got both) | 12:50.53 |
| paulgardiner | The docs sort of present it as widgets being a type of annotation. | 12:52.04 |
| | Have you managed to find any files where the distinctions you made concerning AA/K are actually used. One problem I ran into with all this was not being able to test many of the features. I can't immediately see anything in the JS prelude that deals with the selection. Maybe I've code blind. | 12:54.06 |
| ator | paulgardiner: no, I'm just looking at the js_api_reference.pdf documentation | 12:54.43 |
| | and coding up my own test forms | 12:54.49 |
| | https://ghostscript.com/~tor/form-test.pdf debug prints all text field K/V/C/F events on its text field | 12:56.01 |
| | and should change all text entered into uppercase via the K callback (as per the example in the js_api_reference) | 12:56.21 |
| paulgardiner | That may have been why I left it where it stands: a lot of effort that potentially may make no difference in the wild. I suppose someone must use this stuff at times. | 12:57.03 |
| ator | paulgardiner: yes, I expect so. | 12:57.56 |
| | but I'm working on this trying to tighten it up and not paint ourselves into a corner should these things start becoming important | 12:58.25 |
| paulgardiner | Definitely a good thing to have it done more correctly, but still possibly bad for the release. | 13:04.40 |
| | More pressing for the release is bug 700561... although admittedly found by our tester rather than the customer. | 13:05.17 |
| | On the other hand, we don't have to update the MuSO submodules just yet, and we could work with fixes on a branch for a while if necessary. | 13:06.30 |
| ator | paulgardiner: that bug should be fixed already | 13:11.13 |
| | but I did stumble upon some weirdness in util.printf and AFNumber_Format | 13:11.27 |
| | paulgardiner: I've added an argument to mutool show to show the document level JS | 13:14.14 |
| | so "mutool show calc.pdf js" will print the document-level javascript to stdout | 13:14.27 |
| | and the locations in the error message stack traces should point back to the PDF object number that has the script so you can find the source text more easily | 13:15.12 |
| paulgardiner | Handy | 13:15.14 |
| | Just looking at your branch. Can we no longer render a single annotation? | 13:15.47 |
| ator | paulgardiner: we can, but only via the pdf_ namespace | 13:16.03 |
| paulgardiner | Oh right. Of course. That's fine. | 13:16.21 |
| ator | pdf_run_annot and pdf_new_pixmap_from_annot, etc. | 13:16.29 |
| | paulgardiner: I think, in order to replicate Adobe's behavior when editing text fields, we may need to have a 'currently editing text value' stowed away in the pdf_annot struct and use that for display when doing inline editing and K callbacks | 13:21.27 |
| | which doesn't get poked into the pdf_obj structure until it is committed by hitting enter or changing focus | 13:21.56 |
| | paulgardiner: does acrobat on mobile have JS support at all? | 13:22.52 |
| paulgardiner | Hmmm. I don't know | 13:23.09 |
| ator | or is there something else on mobile to compare with? | 13:23.18 |
| | I've updated the form-test.pdf to do something weird | 13:24.01 |
| | it uppercases everything you type, but lowercases the whole field when you format it | 13:24.20 |
| paulgardiner | Asking for trouble. :-) | 13:26.36 |
| ator | indeed! | 13:27.00 |
| paulgardiner | Which commit may have fixed 700561? | 13:27.04 |
| ator | paulgardiner: I listed them in a comment on the bug just now | 13:27.27 |
| paulgardiner | Great. Thanks | 13:27.38 |
| ator | if you take current origin/master you should have all those fixes and a few other stability fixes | 13:27.50 |
| | commit 812f1342d2f64f2f71764604fcf7462b481fd6af is probably quite important | 13:28.03 |
| sebras | ator: I prepared tests_private.js.xz in my home directory. it contains most of the javascripts from tests_private, one per line. | 13:40.03 |
| | ator: I guess it demonstrates what functions we would need. | 13:40.18 |
| | these are all objects containing /JS(string), I skipped hex strings and streams because that was harder to grep out. | 13:40.43 |
| | ator: interesting in example2 for doc.addLink() in pdfjs they do new Matrix2D, but that type is never defined in the spec... | 14:03.30 |
| | I hope that that example is clear enough because it seems like these have been used. | 14:04.07 |
| ator | sebras: huh. that's funny :) | 14:08.08 |
| sebras | ator: what is your bash alias to make git show and mutool show interchangeable? :) | 14:18.52 |
| | agh! | 14:18.55 |
| ator | sebras: woo! I *think* I've got the field keystroke/validation/calculate/format event sequence matching adobe's | 14:23.24 |
| | for non-inline editing | 14:23.32 |
| | it just pretends you ^V paste over the existing text and hit enter | 14:23.50 |
| sebras | nice! | 14:24.01 |
| | why can't we use the same events for non-inline editing even if we process each and every keystroek? | 14:25.27 |
| | it seems to me that it ought to be possible to have selections and text be the same. | 14:25.54 |
| ator | sebras: because we currently don't have much of an API for inline editing | 14:26.10 |
| | we need to keep the 'currently editing text' separately for feeding to event.value | 14:26.24 |
| | without setting the target field.value for each keystroke | 14:26.35 |
| sebras | right, but that means that it is possible, just not yet! | 14:26.55 |
| ator | yes. it should be possible to extend the pdf_annot with a 'currently editing text value' and a pdf_edit_text_field_value function to do the individual keystroke events before committing | 14:27.34 |
| | if we add that, and some way to make it (a) render and (b) get text layout to the UI, we can also get rid of the inhibit_trigger_events hack | 14:28.24 |
| | paulgardiner: currently your muso will change the field value even when it shouldn't because of the inhibit_events flag, where it ignores the return code saying to 'stop this edit!' | 14:29.23 |
| | paulgardiner: you could work around that by doing this when editing a text field http://ix.io/1ARm | 14:35.45 |
| | sebras: right, so now we still need to look at 'mutool show $PDF js' for document-level javascripts | 14:37.15 |
| | and possibly /JS 5 0 R streams | 14:37.23 |
| | anyway, it's a good list to start with | 14:37.46 |
| paulgardiner | ator: not quite understanding. I need to update the text because that's the only way I get it drawn on screen. And doing so is harmless provided I always set it to whatever it should be at the end of the editing session. | 14:39.55 |
| sebras | ator: yes, and it seems to me that tests_private/forms/v1.4/ucm*.pdf along with staff_self_rating.pdf use most of what we'd need to implement. | 14:40.20 |
| ator | paulgardiner: I mean if it fails to validate at the end of the editing session, it should be restored to what it was before | 14:40.45 |
| | see the paste link with pseudo-code | 14:40.58 |
| | maybe this is exactly what you're already doing, though | 14:41.18 |
| paulgardiner | Yeah, I have plans to address that eventually. At present I force the user to edit until it passes validation, | 14:42.09 |
| | Yeah, I have plans to address that eventually. At present I force the user to edit until it passes validation. | 14:42.12 |
| ator | http://ix.io/1ARp is a transcript of the event sequence in acrobat when selecting a form field, pasting over the content, and hitting enter (with the toUpperCase K, and toLowerCase F, functions) | 14:42.47 |
| | I have not poked it to see what happens when the 'fail' validation yet though | 14:43.20 |
| | paulgardiner: alright, sounds like a reasonable approach | 14:43.50 |
| | as long as they can cancel out and get it back to what it was | 14:44.09 |
| paulgardiner | I could make it easier for them to do that, but I'm at the stage of preferring to let tester and customer comments drive changes. | 14:45.25 |
| ator | paulgardiner: question -- since you already poke at the pdf_obj with pdf_set_field_value to get the appearance back when you do edits | 15:05.12 |
| sebras | ator: how do you feel about the commit on top of sebras/master? | 15:05.15 |
| ator | paulgardiner: I believe you would only need to inhibit the F (formatting) event, and could run the other events to do checking for each keypress, no? | 15:05.44 |
| | well, you'd also want to inhibit C events to not recalculate until the end as well | 15:06.05 |
| | paulgardiner: but I think you should be able to run K events while editing | 15:06.22 |
| sebras | I can definitely be convinced to change it, especially since I'm not 100% sure about the -gl interfaces. | 15:06.27 |
| ator | sebras: that should work, on linux... | 15:08.17 |
| | not so much on windows | 15:08.20 |
| paulgardiner | I prefer to inhibit C events to avoid multiple screen updates (I'm not redrawing the whole page on each change). At the moment at least, I don't think I want to run K because I'm not sure I can inform iOS about the changes it may have made. | 15:08.23 |
| ator | paulgardiner: if it could tell you about the selection changes and the new text (from pdf_field_value and the text quads) would that be enough to allow K events? | 15:09.31 |
| paulgardiner | I may be wrong about that second statement: when I most recently thought about this, I'd forgotten that you send in the selection range and get told how that changes. That may be enough that I can react to the changes K makes | 15:09.32 |
| ator | I think all non-K events should be inhibited | 15:09.40 |
| sebras | added some delicious #ifndefs. | 15:09.56 |
| paulgardiner | ator: that does sound like it would work and it would be a nice feature to react to K correctly. | 15:11.35 |
| | Again, I probably would want to get past the initial release without trying to add that. | 15:12.10 |
| ator | paulgardiner: sure. | 15:13.24 |
| paulgardiner | So the way that selection is handled would also deal with the caret? I'm hoping that the caret is represented as a selection with zero length | 15:15.08 |
| ator | paulgardiner: yes, in the K events that's true | 15:15.35 |
| paulgardiner | This all does sound very nice. | 15:15.48 |
| ator | an insertion K event has the selStart/selEnd be a zero length selection at the caret with a changed='X' for the character | 15:16.05 |
| | so if you feed in the selStart/End correctly, it should also get it back out as expected | 15:16.27 |
| paulgardiner | Nice. I'd forgotten K worked like that. | 15:17.21 |
| ator | paulgardiner: possibly because it was never hooked up in mupdf before :) | 15:18.06 |
| paulgardiner | Yeah. It probably made no sense other than for in place editing | 15:18.32 |
| ator | anyway, I'll put more changes in this regard on hold until you poke me asking for proper K | 15:18.34 |
| paulgardiner | Excellent. Thanks | 15:18.53 |
| ator | as it is now, I have it faking a 'select all, paste new value, hit enter' sequence when you do pdf_set_text_field_value without inhibiting events | 15:19.03 |
| | the WIP stuff on tor/master | 15:19.12 |
| | and some utility functions to do my pseudo-code in the java stuff in case fred wants to poke around | 15:19.26 |
| paulgardiner | Sounds good. | 15:19.39 |
| ator | with a startEditing, cancelEditing, commitEditing (that returns false and stays in editing mode if validation fails) | 15:19.55 |
| | and that stows away the original value so it can restore stuff if you escape out | 15:20.06 |
| sebras | ator: are you happy with the ifdefs? | 15:49.02 |
| ator | sebras: sorry, yes, a09c848bc40a44d8622f62cb4078a65e04223806 LGTM | 15:53.16 |
| sebras | ator: no worries, context switching is annoying. :) | 15:53.59 |
| | ator: ehm... https://pastebin.com/raw/Xn3m3qhC mutool show doc.pdf Root.Pages.Kids.1.Resources.XObject.5 doesn't really work now... | 17:26.08 |
| Robin_Watts_ | Nancy: It might be a function added by/for mvrhel. | 19:01.51 |
| | It's his kinda thing. | 19:01.57 |
| | STUPID CHATZILLA. Sorry. | 19:02.06 |
| | Forward 1 day (to 2019/02/13)>>> | |
Log of #mupdf at irc.freenode.net.