| | <<<Back 1 day (to 2018/02/13) | 20180214 |
| sebras | Robin_Watts tor8 (for the logs): I have prepared two patches on sebras/master that I know fix my problem, it is using nested fz_try()s though. | 02:36.07 |
| | I think the logic is clearer this way, but I know we try to avoid it. | 02:36.29 |
| | so I expect advice and comments on the first commit. | 02:37.06 |
| | an option would be to do something like: https://pastebin.com/raw/hRsGiBuL | 02:40.54 |
| | but I'm not sure that is more obivous. | 02:41.05 |
| Robin_Watts | sebras: Have you considered something like: | 10:34.53 |
| | int cleanup = 0; | 10:36.52 |
| | ... | 10:36.53 |
| | fz_var(cleanup); | 10:36.55 |
| | fz_try(ctx) { | 10:36.56 |
| | if (image->mask && gstate->blendcode) | 10:36.58 |
| | { | 10:36.59 |
| | fz_begin_group(); | 10:37.01 |
| | cleanup |= GROUP; | 10:37.02 |
| | fz_clip_image_mask(); | 10:37.04 |
| | cleanup |= CLIP; | 10:37.05 |
| | } | 10:37.07 |
| | etc ? | 10:37.08 |
| | We'd only have 1 fz_try, and the bits set in cleanup would tell us what needs cleaning up at any given time. | 10:37.33 |
| sebras | Robin_Watts: I have seen these elsewhere in the code, but I really don't think they are very clear. :-/ | 10:53.03 |
| | Robin_Watts: I have also seen solutions based on goto (perhaps not in this case), and I personally don't like those too much either. | 10:53.50 |
| Robin_Watts | sebras: Nested fz_try's are bad, I reckon. Multiple ones almost as bad. | 11:08.50 |
| | (cos the setup time is non zero) | 11:08.55 |
| | Not sure how the goto ones would work with exceptions. | 11:09.28 |
| sebras | I guess the setup time is the same for both nested and multiple fz_try()s. | 11:09.31 |
| Robin_Watts | Yes, but nested also increases the stack depth. | 11:09.45 |
| | (so it's as slow, and uses more depth) | 11:10.00 |
| | My person preference, I think, is for the cleanup variable ones, but I'm open to suggestions that you think are clearer. | 11:10.38 |
| sebras | Robin_Watts: another way is of course to break it up in separate functions, but then you will just say that the time spent on calling fz_foo() is the same as that calling fz_push_try(). | 11:10.43 |
| tor8 | paulgardiner: regarding the text encoding bugs; use the function pdf_load_stream_or_string_as_utf8 instead of pdf_get_string_or_stream in pdf_field_value (and maybe elsewhere) | 11:10.59 |
| Robin_Watts | sebras: yeah. All of programming is a tradeoff :) | 11:11.10 |
| sebras | Robin_Watts: I guess I should be doing the cleanup variable then. but ugh, I really don't want to. | 11:11.51 |
| paulgardiner | tor8: okay useful. What about setter functions? | 11:12.24 |
| tor8 | paulgardiner: and for the reverse (creating pdf_obj strings to hold unicode text) pdf_new_text_string() instead of pdf_new_string | 11:12.25 |
| Robin_Watts | sebras: See what tor8 thinks? | 11:12.25 |
| tor8 | that takes care of encoding it as utf-16 if needed | 11:12.40 |
| | and takes a utf-8 string as input | 11:12.50 |
| paulgardiner | Nice | 11:13.11 |
| sebras | Robin_Watts: yup. I'm not in a hurry. I'm leaving for an errand in a little while. | 11:13.11 |
| tor8 | sebras: Robin_Watts: I tend to dislike nested try/catches. when the tradeoff is between clarity and a minor performance worry, I always go with clarity. | 11:14.39 |
| | though deciding what is actually clearer is a difficult problem | 11:14.57 |
| Robin_Watts | sebras' pastebin above is certainly clear. | 11:15.23 |
| sebras | tor8: https://pastebin.com/raw/hRsGiBuL | 11:15.25 |
| | tor8: there's another variant of this on sebras/master with nested trys. | 11:15.43 |
| tor8 | I like the serialized try/catch in the pastebin to the nested version on sebras/master | 11:15.55 |
| sebras | tor8: how about having a cleanup variable like robin mentioned above? | 11:16.08 |
| | tor8: robin is correctly arguing that that solution is better performance wise. | 11:16.23 |
| | and for a hot path that could matter. | 11:16.45 |
| tor8 | the cleanup variable is what we went with try/always/catch to avoid | 11:16.47 |
| sebras | s/what/why/ | 11:17.00 |
| tor8 | pdf_show_image is not a hot path any way I can see it | 11:17.02 |
| | at most a few thousand calls per page | 11:17.21 |
| Robin_Watts | especially not in the masked && blending case :) | 11:17.23 |
| sebras | seems like the pastebinned proposal won then..? | 11:17.42 |
| Robin_Watts | yeah. | 11:17.47 |
| Robin_Watts | reboots for windows updates. brb. | 11:17.57 |
| sebras | Robin_Watts: it is a windows update... you'll be gone for a long time, and no one can tell if you'll ever be back from it... ;) | 11:18.39 |
| | tor8: ok, thanks. I'll fix my branch. | 11:18.50 |
| | tor8: down to 24 open oss-fuzz bugs, yey. :) (still have another 15 or so that I need to verify that they were correctly closed). | 11:19.38 |
| tor8 | paulgardiner: if you know it's a string object (and not either string or stream, as the javascript texts) then use pdf_to_utf8 | 11:20.18 |
| | which one to use depends on the pdf specification for each entry | 11:20.45 |
| | sebras: good going! | 11:20.53 |
| paulgardiner | Thanks. Not sure Henry wants me to look at these myself, but if I do get to them... | 11:21.35 |
| tor8 | paulgardiner: if they're blockers... | 11:22.07 |
| | I can't easily test this because none of this stuff works on a desktop viewer | 11:22.34 |
| | which is what I'm trying to set time aside to fix | 11:22.45 |
| paulgardiner | Hopefully I can get to them. They are in areas I know something about. | 11:25.02 |
| | Other than the saving to encrypted files one. Did you get anywhere with that one? | 11:25.31 |
| tor8 | paulgardiner: pdf_field_value and update_field_value should take care of most of them | 11:26.30 |
| | paulgardiner: I fixed that one last week. | 11:26.42 |
| | unless there's a new one? | 11:26.56 |
| | pdf_choice_widget_options will need changing since pdf_to_utf8 does a malloc so the call site needs to free the option strings | 11:27.22 |
| paulgardiner | 698918 | 11:27.57 |
| tor8 | paulgardiner: commit b59ff4e3956d8e62b6b76a0e23697b15bc8c9467 fixes 698918 | 11:28.15 |
| paulgardiner | Ah, great. I was just monitoring the bug status | 11:28.53 |
| tor8 | paulgardiner: oops. I forgot to change the status :) | 11:30.02 |
| paulgardiner | Should most "drop" methods accept NULL? | 11:30.15 |
| tor8 | yes. | 11:30.29 |
| paulgardiner | fz_drop_output maybe doesn't | 11:30.49 |
| sebras | paulgardiner: it absolutely does not. | 11:31.14 |
| Robin_Watts | sebras: Why not? | 11:31.30 |
| tor8 | hmmm. you're right. I may have been overzealous in fixing some other functions to not accept null | 11:31.32 |
| sebras | Robin_Watts: it dereferences out without checking out. | 11:31.41 |
| Robin_Watts | sebras: Right, so it's a bug. | 11:31.50 |
| sebras | Robin_Watts: it is. | 11:31.54 |
| | Robin_Watts: sorry if I made it sound that it shouldn't. of course it should. :) | 11:32.08 |
| Robin_Watts | sebras: No, was just checking. | 11:32.20 |
| tor8 | paulgardiner: on tor/master are a few commits that might fix the encoding issues with forms | 11:38.15 |
| | paulgardiner: completely untested, of course :) | 11:38.31 |
| paulgardiner | Great. Will give them a go. | 11:38.42 |
| tor8 | paulgardiner: Robin_Watts: I also added a set of convenience functions for creating dicts and arrays | 11:39.15 |
| | pdf_dict_put_XXX and pdf_array_push_XXX where XXX can be int, real, string, text_string, etc. | 11:39.44 |
| | so pdf_dict_put_int(ctx, doc, val) instead of the pdf_dict_put_drop(pdf_new_int()) nested calls | 11:40.09 |
| Robin_Watts | tor8: Can we not use 0xFFFFFFFCU ? | 11:40.17 |
| | That should force the compiler to make the enum unsigned. | 11:40.32 |
| | Right hand drift in the fz_drop_output one, but OK. | 11:41.31 |
| | if (!out) return; | 11:41.45 |
| malc_ | Robin_Watts: enums are by definition ints | 11:42.38 |
| | Robin_Watts: you can't make them unsigned no matter what | 11:42.51 |
| Robin_Watts | An enum is guaranteed to be represented by an integer, but the actual type (and its signedness) is implementation-dependent. | 11:43.15 |
| | Though K&R2 states "int". | 11:43.37 |
| | malc_: So yeah, fair enough. | 11:43.45 |
| malc_ | Semantics | 11:44.24 |
| | 3 | 11:44.24 |
| | The identifiers in an enumerator list are declared as constants that have type int and | 11:44.24 |
| | may appear wherever such are permitted.127) | 11:44.24 |
| Robin_Watts | tor8: Last 2 look OK. | 11:45.02 |
| malc_ | Robin_Watts: there's no -std=k&r2 so uhm | 11:45.18 |
| Robin_Watts | so all 4 lgtm, with a minor style wibble on the drop output one. | 11:45.25 |
| | malc_: Yeah, K&R2 is informative, not normative :) | 11:45.41 |
| tor8 | Robin_Watts: thanks. | 11:45.48 |
| malc_ | Robin_Watts: i think it stopped bing even informative a couple of decades ago :) | 11:46.02 |
| tor8 | I'll wait for paul to let me know if the text encoding ones actually solve his bugs | 11:46.05 |
| | (but if he doesn't say anything in a couple of hours I'll assume they're good) | 11:46.25 |
| paulgardiner | I just have something to finish off before looking. | 11:49.26 |
| | tor8: just about to try out those changes. Did you say I'll now need to free strings I previously didn't? | 12:10.58 |
| tor8 | paulgardiner: the ones returned by the pdf choice widget will need to be freed | 12:11.16 |
| | since we've malloced utf-8 decoded versions of whatever was in the pdf objects | 12:11.27 |
| paulgardiner | ta | 12:11.29 |
| tor8 | the pdf_field_value strings already needed to be freed, so no change there | 12:12.03 |
| paulgardiner | tor8: I'm not sure that completely solved the problem. The getters are working correctly, but possibly not the setters. Or it may be there's a problem with the appearance streams. | 12:41.11 |
| tor8 | appearance stream generation is probably not working well with encodings | 12:41.34 |
| | it's on my todo list, but it may take a while to get there | 12:41.43 |
| | first I need a way to easily test this stuff on my linux machine, which means adding annotation editing and form filling to mupdf-gl | 12:42.12 |
| paulgardiner | OSX VM? | 12:42.57 |
| tor8 | ugh, osx ;) | 12:43.27 |
| | you mean run xcode and iphone simulator in an osx vm? | 12:44.05 |
| paulgardiner | Yeah. That's what I do. | 12:44.22 |
| tor8 | I want it running natively. so much faster and easier turnaround when building. | 12:44.42 |
| paulgardiner | Well, not usually the simulator, but sometimes. Usually I connect a device. | 12:44.47 |
| | I'm just clicking one button to rebuild and doing all the editing via Xcode (at the moment at least) | 12:45.43 |
| | I have to admit the initial set up is hellish | 12:48.34 |
| tor8 | paulgardiner: yeah. I'm hoping that having a non-mobile ui will allow us to have a second look at the api as well. | 12:51.44 |
| | in terms of how events are handled | 12:52.13 |
| paulgardiner | To some degree, the api was designed around desktop: tap on mobile is sent to the library as mouse down followed by mouse up. | 12:53.12 |
| | I don't think I got around to handling hover events and the like though. | 12:53.28 |
| tor8 | paulgardiner: just don't spend too much time on it... I may end up revising event handling quite a bit once I have my head wrapped around how things should work to suit both mobile and desktop and scripting via js/java interfaces | 12:54.25 |
| paulgardiner | Probably should discus this with Henry as well. I think getting form-filling working is supposed to be one of priorities, but sounds like there could be a lot of wasted work if I carry on with it now. | 12:57.51 |
| | Out of interest, what do you see as wrong with the current API? IIRC, we just send it events when they happen and monitor for changes that need screen updates. Also handle display of alerts (along with their replies from javascript. | 12:59.13 |
| | That's interesting. I filled in a form with some non-ascii, which gave a garbled appearance stream (assuming the setting of the field worked correctly). I saved and opened it in Acrobat Reader. Same garbled appearance stream unexpectedly, but when I clicked the field, expecting to see the ungarbled form, a message popped up saying "A font package is required to take this action on this form" | 13:14.15 |
| | And after installing the font pack, when I click the field, I do see the correct text which I typed in under MuSO. So I think that means the setters you changed are working now. | 13:17.17 |
| tor8 | paulgardiner: it's how events interact with possible native widgets and their event loop structure | 13:18.19 |
| | that may or may not work as well as I want it; I just don't know enough yet to say | 13:18.38 |
| | paulgardiner: whether I focus on widgets or annotations first doesn't really matter to me. it's really whichever you feel you need a stable and complete api for first. | 13:19.19 |
| | because where I go in, there will be earthquakes... | 13:19.28 |
| | I was under the assumption that annotation editing is higher priority, since that's what we've talked most about (and added the JNI/java bindings for) | 13:20.20 |
| paulgardiner | There are two milestones for MuSO. Getting it doing everything that SO used to do without it and getting it doing everything that the old mobile mupdf apps do. The first needs annotations and the second needs annotations and form filling. | 13:23.53 |
| | So are you thinking the app may play a greater role in interpreting events and dispatching them, mixed in with the native events? | 13:26.56 |
| | Thinking of a document with widgets as being sort of like a UI in itself? I'm not sure I'm getting it. | 13:28.20 |
| tor8 | paulgardiner: what if the app wants to use an embedded native widget to handle pushbuttons and text fields? | 13:30.42 |
| | this is an area I want to explore the design space of | 13:31.04 |
| paulgardiner | But what if you do all that work and no one ever wants to do that? I thought that our current use of native widgets (e.g. for text widget filling) was something we wanted to move away from. | 13:33.22 |
| tor8 | the current text widget editing just pops up a dialog box on windows | 13:34.24 |
| paulgardiner | Yeah, which I thought we wanted to move away from and implement inplace editing eventually | 13:34.50 |
| tor8 | I foresee in-place editing being done in two ways -- either we implement it ourselves by using passed events | 13:35.21 |
| | but this will be pretty much a desktop only solution | 13:35.31 |
| | and requires exposing callbacks for things like copy & paste and input method editing | 13:35.50 |
| | or we allow some way for the client to know that 'here's a text widget --handle it at these coords' | 13:36.08 |
| | which can of course be done as we do now by just popping up a dialog on say android | 13:36.31 |
| | or by overlaying a native text widget | 13:36.42 |
| | or maybe by asking mupdf to handle the events and do in-place editing | 13:36.57 |
| paulgardiner | iOS has an interface that one needs to implement called UITextInput which allows the OS to handle editing within a document, along with predictive text, copy and paste etc. | 13:39.59 |
| | I think it can do the highlighting of selected text (some of the methods you implement are for telling the OS where bits of text are within the field) | 13:41.17 |
| | I don't think it handles display of the caret. | 13:41.46 |
| tor8 | querying the page for where there should be text fields and then creating native ones at the right places could be easier | 13:43.39 |
| paulgardiner | But wont look as good as inplace editing. | 13:44.18 |
| | I'm assuming controlling the placement and font of a text widget to exactly match that of the document would be very difficult. | 13:46.34 |
| | But implementing UITextInput and allowing it to repeatedly update the text widget doesn't look that hard. I've done similar for the non-mupdf side of SO | 13:48.22 |
| tor8 | paulgardiner: yeah. I think sebras experimented with something like that for mupdf-x11 a long long time ago | 14:01.15 |
| | feeding the events and updating the widget appearance stream in place | 14:01.24 |
| | VERY ineffective in terms of performance -- regenerating a content stream and interpreting it every time a key is pressed | 14:01.45 |
| | and doing text selection is a bit awkward there too | 14:01.55 |
| | but if we do our own widget display code, we can easily make it match the PDF file's final appearance | 14:02.16 |
| | even if we don't actually feed it through the pdf interpreter for every keypress | 14:02.34 |
| sebras | tor8: paulgardiner: I did, but I think that commit has been lost to /dev/null. | 14:10.46 |
| paulgardiner | Well you could do that as an optimisation within the library: keep recreating the display list and displaying it until finished with the specific widget. Then update the appearance stream. | 14:21.08 |
| | Seems unnecessary hassle within the app to have to explicitly create a second view over part of the page that again mupdf is responsible for drawing. | 14:22.09 |
| sebras | Robin_Watts: tor8: prior commits updated on sebras/master. still cluster well. | 15:07.56 |
| Robin_Watts | sebras: Style nit... I'd have the comment on the first one inside the while loop. | 15:11.19 |
| | otherwise I'd be inclined to misread it. I see the } and the while as atomic. | 15:11.46 |
| | but that's minor, so ignore me if you disagree. | 15:11.58 |
| | otherwise all lgtm. | 15:12.57 |
| sebras | Robin_Watts: I already pushed that commit to master. | 15:21.56 |
| Robin_Watts | fair enough :) | 15:22.20 |
| sebras | Robin_Watts: this is the second time I get comments from you on things I already pushed. maybe I should hold of the first set of things you LGMTed until you LGTM the second batch so I know for sure I have collected all comments. :) | 15:22.48 |
| Robin_Watts | sebras: Or I should look properly the first time :) | 15:23.09 |
| paulgardiner | tor8: just checking, when you say "do our own widget display code", you mean having mupdf draw the widget to match how it would look in the document, rather than having two versions of a complex algorithm both in mupdf and in the app. I've just remembered all the different cases for text widgets: e.g., changing the text size to fit flowed text in the widget rect. | 15:26.56 |
| tor8 | yes. | 15:27.32 |
| | have mupdf do all the event handling and display code, just return a fz_pixmap for the client to display | 15:27.50 |
| | but that will be at odds with OSX and expectations that text widgets behave a certain way on a platform | 15:28.30 |
| | but I suspect that is less and less of a concern, given the way native toolkits are going and how even microsoft has dozens of competing text edit implementations | 15:29.05 |
| | with the mobilification of operating systems, etc. | 15:29.17 |
| | there just isn't a consistent base line to aim for anymore :( | 15:29.39 |
| paulgardiner | No, that would be bad for iOS I think. People expect every app to work the same in that regard. | 15:29.40 |
| | That's the point of the UITextInput interface. | 15:30.04 |
| tor8 | paulgardiner: which is why I think just overlaying a native text edit widget for editing is probably better | 15:30.07 |
| | even if the text appearance won't match exactly | 15:30.24 |
| | or expose some sort of 'edit' interface where we do the display and the event handling is handled at a higher level | 15:30.49 |
| | but that interface is bound to be different for each OS as well | 15:30.58 |
| paulgardiner | I don't see what's so difficult about actually getting it right. | 15:31.02 |
| Robin_Watts | There are 2 acceptable competing possibilities here. 1) get the native OS to overlay a text widget on the screen in the right position, and edit in that. When editing is completed, write it back to the document. | 15:33.14 |
| | 2) do all the editing "in house", with repeated relayouts etc, so it looks perfect each time. | 15:33.40 |
| tor8 | Robin_Watts: I believe that is the approach mvrhel is doing in gsview, at least we talked about something like that a few years ago. | 15:33.52 |
| paulgardiner | I think there are more than 2 | 15:34.00 |
| Robin_Watts | My gut says 1 is easier, gives people a "less surprising" experience etc. | 15:34.44 |
| paulgardiner | I guess there are 2 end results | 15:34.49 |
| Robin_Watts | Consider if you've got some screwy extension added that makes cut/paste etc work in a particular way (or supports extra buttons on a stylus or something). | 15:35.41 |
| | Matching that is going to be an endless nightmare. | 15:35.57 |
| paulgardiner | That's what UITextInput is for. | 15:36.07 |
| | It's the interface the OS uses to talk to it's own widgets. | 15:36.36 |
| tor8 | paulgardiner: UITextInput doesn't exist on Android, win32, x11, gtk+, qt, etc. | 15:36.44 |
| Robin_Watts | 2) gets us back to the "UE2 vs native" situation we've had in the past. | 15:37.02 |
| paulgardiner | I believe something like it exists on Android. | 15:37.09 |
| tor8 | paulgardiner: which means doing the subset, or #ifdeffing, or some other hacky not-really-all-the-way-there-on-all-platforms solution | 15:37.38 |
| paulgardiner | But in any case, we should to the best job on iOS we can, independently of whether we can do the same on other platforms. | 15:37.55 |
| tor8 | I think doing 1 will get us to an acceptable target faster, and be less buggy and more adaptable to future implementations | 15:38.09 |
| Robin_Watts | paulgardiner: I'd be tempted to do 1 to start with. It's easiest, right? Then we can revisit with a more complex solution later if required. | 15:38.17 |
| paulgardiner | It's the app that implements UITextInput not the librrary | 15:38.23 |
| tor8 | sure, it won't look the same while editing and while 'committed' but that's largely to be expected | 15:38.28 |
| paulgardiner | We are doing 1. I'm just arguing against reworking the API in a way that stops us doing 2 | 15:39.09 |
| Robin_Watts | paulgardiner: Right. | 15:39.32 |
| paulgardiner | Why would you not have it the same while editing if you can do that? | 15:39.54 |
| | I mean aim for that eventually at least | 15:40.12 |
| tor8 | paulgardiner: because laying out for PDF and the operating systems text layout are unlikely to match exactly | 15:41.24 |
| | in terms of kerning, exact font spacing, etc | 15:41.35 |
| paulgardiner | So that's why you have mupdf do the layout also for the widget | 15:41.53 |
| tor8 | I expect for mupdf-gl to have display code that will match exactly (considering I will be reusing the same text layout code) so adapting that to something using UITextInput might very well be trivial | 15:42.33 |
| paulgardiner | I'm not suggesting trying to make a native widget match PDF (other than having mupdf draw it). That would be hellish | 15:42.39 |
| tor8 | paulgardiner: then I don't understand... if we don't match PDF, what are you trying to match? | 15:43.34 |
| paulgardiner | tor8: but then that's going back to having two version of a complex algorithm, one in the lib. One in the app. | 15:43.58 |
| | I am intending to match PDF, but just not with a native widget, at least not by means other than having mupdf draw it. | 15:44.36 |
| tor8 | paulgardiner: anyway, my main point is that I don't think the pdf_pass_event api is going to be enough. | 15:44.41 |
| | so I anticipate changes around that level | 15:44.50 |
| | nothing that should be too difficult to work around with the ios and android viewers, but I expect I'll get it working with mupdf-gl and then we can see what changed | 15:45.12 |
| | paulgardiner: so you want mupdf to handle display of the widget, but enough hooks to do the behavior of the widget with the OS and have that all hooked up into the OS event handling? | 15:45.59 |
| | that sounds terribly complicated :) | 15:46.08 |
| | paulgardiner: we can probably talk more about this in two weeks... I doubt I'll get around to doing anything with forms before then | 15:46.49 |
| paulgardiner | What hooks? I'd just need to repeatedly update the text. I'd have been happy enough just to update the document directly and not have a separate widget, but you say that cannot be made efficient enough. | 15:50.03 |
| | Hang on. To do this right, you have to keep updating the widget on every key press because for some documents there is javascript that monitors that process and may alert or actually change the text on the fly | 15:51.22 |
| | I'll try to shut up about this after one last thought: we currently have the concept of there being a currently focused widget within mupdf. If rendering of changes to that one widget could be optimised that might allow in place editing to be done quite simply. | 16:06.18 |
| fredross-perry | I am late to this. But what about showing a native widget while editing, then hide the widget and update the page? | 16:24.26 |
| | and maybe cook up some API for each platform to supply their own widgets? | 16:25.16 |
| jogux | it's a fine balanced decision. There are all kinds of potential issues, not the least of which is keeping the native widget in the right place as things scroll. | 16:27.20 |
| Robin_Watts | fredross-perry: That's option 1. | 16:32.10 |
| | I think we're all agreed that option 1 is possible, and simpler. | 16:32.40 |
| fredross-perry | and I don't think users will notice that the rendering while editing is a little different, really I don't. | 16:33.27 |
| Robin_Watts | paulgardiner is (AIUI) arguing that we should leave the route open for option 2, cos it'd be "better" if we have the ability to work that way, even if we only end up doing so on a subset of platforms. | 16:33.31 |
| jogux | fredross-perry: that will all depend on your version of 'different'. There are quite a lot of potential issues, particularly in the CJK languages where han unification is an issue. | 16:34.24 |
| | (han unification is where the wonderful people at the Unicode consortium decided to give characters that have different appearances in Chinese, Japanese and Korean that same unicode code point) | 16:35.10 |
| paulgardiner | I don't think anyone is looking at option 2 any time soon. I just think it is important we get there eventually and in particular don't design APIs away from it. | 16:35.29 |
| Robin_Watts | jogux: Not to mention subset fonts. | 16:36.00 |
| jogux | well they're "fun" in both approaches. :( | 16:36.34 |
| fredross-perry | I assume that we'd leave it to the native widget to do what it does (more or less), matching the user's expectations on that platform? | 16:36.50 |
| jogux | fredross-perry: I presume we're this is unrelated to the previous points, if so that would be my assumption too. | 16:37.20 |
| fredross-perry | IOW, if I need to use an IME, then the widget won't look like the final product while editing. | 16:37.26 |
| paulgardiner | fredross-perry: you get a lot of useful context from seeing the text appear in place. If nothing else, seeing when you've typed sufficient characters in a widget with individual boxes for the chars. | 16:37.59 |
| | Plus there's the javascript thing I mentioned earlier. Some forms give feedback and alter text as you type. | 16:38.39 |
| fredross-perry | Do PDF forms support the idea of text boxes that expane while you're typing? | 16:39.17 |
| paulgardiner | You can put arbitrary javascript in a PDF doc and it can respond to each change in the text | 16:39.49 |
| jogux | paulgardiner: potentially even the native approach can still feed the text to the js... | 16:40.03 |
| paulgardiner | It can put up an alert it can delete and create annotations. It can change the text. It can color the text | 16:40.22 |
| jogux | well technically all of that is possible... | 16:41.41 |
| paulgardiner | jogux: Yeah I realised that, but then what are we gaining by having the native widgets. We have to say to the document "change the text, but don't try to change the display", "oh nearly forgot: is the text still what I just told you it was, or has it been changed". | 16:42.18 |
| jogux | yeah, I agree | 16:42.36 |
| fredross-perry | I may be naive. I was thinkg of editing a form element as a sort of modal thing. Now I'm editing, now I'm done. So no burning need to update the document with each key. imho. | 16:47.35 |
| jogux | as Paul says, that breaks any javascript that's looking for updates. | 16:49.02 |
| fredross-perry | What is a scenario where Javascript is used while editing? | 17:01.55 |
| jogux | where the person that has created the document has added javascript to the document that does stuff as the user types. | 17:07.50 |
| Robin_Watts | fredross-perry: Imagine you have a document that takes a credit card number. | 17:08.28 |
| | You might have javascript that inserts spaces every 4 numbers. | 17:08.41 |
| | Or refuses to accept chars other than digits etc. | 17:08.53 |
| fredross-perry | Right, but those things (imo) could happen without asking the doc itself to update, until you leave editing mode. | 17:10.02 |
| jogux | well it means the native widget has to be wired up such that javascript can do things to it, and is told about text being entered into it. | 17:11.20 |
| Robin_Watts | fredross-perry: They *could* but the document model admits of cases where they aren't. | 17:11.34 |
| | A first attempt that only did it at the end wouldn't be disastrous. | 17:11.55 |
| | Boxing ourselves into a solution where it CAN only be done at the end would be more so. | 17:12.20 |
| fredross-perry | Right. So the API for a platform-dependent component that provides the widgetry could be making this decision, not mupdf per se. | 17:16.50 |
| | iow, handle the event, and have mupdf respond at the component's election. | 17:17.34 |
| Robin_Watts | fredross-perry: The need (or desire at least) to have mupdf be able to javascript process the contents of a text field as it is edited, need not preclude the use of native UI text fields (if that's what you mean). | 17:23.00 |
| fredross-perry | Right, I am thinking that. | 17:23.27 |
| | I'm just sayng that the decision about whether to update the doc as each key is typed can be left to the widget-provider. I hope this is clear. | 17:24.08 |
| Robin_Watts | The library should cope either way, with the widget provider choosing whether to bother or not, yes. | 17:25.04 |
| fredross-perry | This will probably be simpler and btw we don't have to build all the widget providers. Let some other devs do the obscure ones. | 17:31.32 |
| | Forward 1 day (to 2018/02/15)>>> | |
Log of #mupdf at irc.freenode.net.