| | <<<Back 1 day (to 2018/11/29) | 20181130 |
| paulgardiner | tor8: did you have a chance to look at my in-place editing commits? | 12:54.27 |
| tor8 | paulgardiner: a brief glance | 13:03.52 |
| | I'm not fond of putting the is_editing state in the pdf_document. can it not live more appropriately in the pdf_widget? | 13:04.09 |
| | also, I'm not sure that's the behaviour adobe has. does it not forbid individual keystrokes while editing in-place? | 13:04.35 |
| paulgardiner | tor8: possibly. I will take a look. | 13:30.14 |
| | That was in reply to the movement of the is_editing flag. As for the forbidding of individual keystrokes, I'm not too worried about that at the moment, and in any case not sure I can implement that within the iOS APIs | 14:38.51 |
| | tor8: problem... pdf_field_set_value currently has access to the pdf_obj for the field, but not the pdf_annot struct | 14:43.15 |
| | ... and I think we call pdf_field_set_value from javascript which may not have any way to get hold of the pdf_annot. | 14:44.23 |
| tor8 | paulgardiner: right. but whether you can implement the /K per key callback in iOS shouldn't matter here, where you're specifically forbidding the /K callback while editing and only running it at the end? | 14:52.06 |
| | and if Adobe runs it per character, should we not try to emulate that behaviour too? | 14:52.35 |
| | when we can, that is | 14:52.42 |
| paulgardiner | If I run the /K callback the change to the text change that iOS asks for may not be what it gets, which may be problematic. | 14:56.10 |
| | too many "change"s in that sentence | 14:56.29 |
| | If I run the /K callback, the change to the text that iOS asks for may not be what it gets, which may be problematic. | 14:57.04 |
| | Maybe we need more than 2 modes. | 15:00.48 |
| | I could add a flag to pdf_text_widget_set_text which the call for the sake of the js dom would always set to false. Or make that an additional version of that function. | 15:09.27 |
| | thoughts? | 15:34.41 |
| tor8 | paulgardiner: honestly, I wasn't even aware of pdf_text_widget_set_text existing before you asked me this question... | 16:45.34 |
| | paulgardiner: I just assumed all content setting was via pdf_field_set_value | 16:45.53 |
| paulgardiner | I'm just looking for a way forward. | 16:50.34 |
| | Just want to get this feature in in some form or other. | 16:52.04 |
| tor8 | would a separate function or argument to pdf_text_widget_set_text do for now? | 16:55.10 |
| paulgardiner | Yes, that would work just fine, if you're happy with that for now. | 17:06.17 |
| | Ah no. | 17:06.36 |
| | It would need to be a argument to pdf_field_set_value | 17:06.58 |
| | It's pdf_field_set_value that needs to change its behaviour but doesn't have access to the annot struct. | 17:08.00 |
| | Perhaps, within pdf_text_widget_set_text I could expand the call to pdf_field_set_value, replacing the call with an altered version of the body of that function. | 17:09.53 |
| tor8 | paulgardiner: could do with a bool 'ignore_callbacks' to pdf_field_set_value | 17:15.58 |
| paulgardiner | yeah that would work | 17:21.47 |
| | Or "no_sideeffects" | 17:22.19 |
| tor8 | no_trigger_events | 17:23.21 |
| paulgardiner | Probably still need to add a flag to the annot struct because appearance synthesis is also affected, but that flag could be passed by pdf_text_widget_set_text to pdf_field_set_value. | 17:24.32 |
| tor8 | you mean to inhibit the 'F' formatting callback? yeah. | 17:25.04 |
| paulgardiner | Yep exactly. Anyway, thanks: I think I know how to proceed now. | 18:11.10 |
| tor8 | paulgardiner: cool. see you in a couple of days! | 18:17.00 |
| | Forward 1 day (to 2018/12/01)>>> | |
Log of #mupdf at irc.freenode.net.