Log of #mupdf at irc.freenode.net.

 <<<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 looking10: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) LGTM11: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 mujs11:08.41 
sebras one curious thing for mujs though: we are creating a .so!?!?!?!!?!?!?!111: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 mujs11: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 
ator oh, I've noly looked at your mupdf master11: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.c11:14.57 
  sebras: fixed version on mujs tor/master11: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 only11:19.47 
  if you want shared, there are separate targets for that11:19.55 
  make shared && make install-shared11: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 bit11:21.33 
sebras paulgardiner: good afternoon paul!11:21.36 
sebras fetches11:21.45 
paulgardiner hi all11:21.49 
ator hi paulgardiner11:21.51 
  so, I've been poking around a bit more in the forms and event handling guts11:22.07 
sebras ator: mujs:tor/master LGTM.11:22.21 
ator I think how we handle the AA/K event is not quite right11:22.23 
  sebras: thanks.11:22.26 
paulgardiner I can't remember what AA/K is related to11:23.07 
ator paulgardiner: we should be feeding it event.change, event.selStart, event.selEnd, and looking at those when it pops back11:23.10 
  the keystroke event11:23.15 
  the one you trigger with setTextValue11: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 input11:23.55 
  I've been filling out the various JS event triggers and cleaning up a bit of the event handling11:24.26 
  which does away with the pdf_pass_event stuff in favor of more explicit events11: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 enum11: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 widget11: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 it11:29.57 
  as a 'paste' event type of thing11: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 code11:30.52 
  pdf_set_field_value runs through the AA/V validator before changing the value11: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 code11:32.41 
  but they ought to be there somewhere11: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 first11: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 anyone11: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 editing11: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 
paulgardiner Yep.11:40.09 
ator paulgardiner: could be from the old android app11:40.17 
paulgardiner I can't think why the old android app would call those11:40.39 
ator paulgardiner: I dug through the history, and I couldn't find a single user of pdf_create_widget11: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 calls11:43.04 
  paulgardiner: you added the pdf_set_text_annot_position function back in 2014, but never called it11:44.55 
  nor did the android app11: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 okay11: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-gl12: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' comment12: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' event12:42.32 
  but also a 'K' event with a selection, in order to allow the JS to change the text12: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-text12:43.34 
  2) call K with willCommit=true, change="", selStart=12:43.42 
  -1 selEnd=-112:43.47 
  3) call V with willCommit=true12: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 longer12: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 behaviour12:48.10 
  if you and fredross-perry don't mind taking those on, it would be a good first step12:48.31 
  the biggest change is having a separate iterator for annotations and widgets12:48.52 
  so the code doesn't need to keep checking 'is this a widget or is this an editable comment' all the time12: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 lists12: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 documentation12:54.43 
  and coding up my own test forms12:54.49 
  https://ghostscript.com/~tor/form-test.pdf debug prints all text field K/V/C/F events on its text field12: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 important12: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 already13:11.13 
  but I did stumble upon some weirdness in util.printf and AFNumber_Format13:11.27 
  paulgardiner: I've added an argument to mutool show to show the document level JS13:14.14 
  so "mutool show calc.pdf js" will print the document-level javascript to stdout13: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 easily13:15.12 
paulgardiner Handy13: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_ namespace13: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 callbacks13:21.27 
  which doesn't get poked into the pdf_obj structure until it is committed by hitting enter or changing focus13:21.56 
  paulgardiner: does acrobat on mobile have JS support at all?13:22.52 
paulgardiner Hmmm. I don't know13: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 weird13:24.01 
  it uppercases everything you type, but lowercases the whole field when you format it13: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 now13:27.27 
paulgardiner Great. Thanks13:27.38 
ator if you take current origin/master you should have all those fixes and a few other stability fixes13:27.50 
  commit 812f1342d2f64f2f71764604fcf7462b481fd6af is probably quite important13: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 
ator sebras: woo! I *think* I've got the field keystroke/validation/calculate/format event sequence matching adobe's14:23.24 
  for non-inline editing14:23.32 
  it just pretends you ^V paste over the existing text and hit enter14: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 editing14:26.10 
  we need to keep the 'currently editing text' separately for feeding to event.value14:26.24 
  without setting the target field.value for each keystroke14: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 committing14: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 hack14: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/1ARm14:35.45 
  sebras: right, so now we still need to look at 'mutool show $PDF js' for document-level javascripts14:37.15 
  and possibly /JS 5 0 R streams14:37.23 
  anyway, it's a good list to start with14: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 before14:40.45 
  see the paste link with pseudo-code14:40.58 
  maybe this is exactly what you're already doing, though14: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 though14:43.20 
  paulgardiner: alright, sounds like a reasonable approach14:43.50 
  as long as they can cancel out and get it back to what it was14: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 edits15: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 well15:06.05 
  paulgardiner: but I think you should be able to run K events while editing15: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 windows15: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 makes15:09.32 
ator I think all non-K events should be inhibited15: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 length15:15.08 
ator paulgardiner: yes, in the K events that's true15: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 character15:16.05 
  so if you feed in the selStart/End correctly, it should also get it back out as expected15: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 editing15:18.32 
ator anyway, I'll put more changes in this regard on hold until you poke me asking for proper K15:18.34 
paulgardiner Excellent. Thanks15: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 events15:19.03 
  the WIP stuff on tor/master15:19.12 
  and some utility functions to do my pseudo-code in the java stuff in case fred wants to poke around15: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 out15:20.06 
sebras ator: are you happy with the ifdefs?15:49.02 
ator sebras: sorry, yes, a09c848bc40a44d8622f62cb4078a65e04223806 LGTM15: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)>>> 
ghostscript.com #ghostscript