| | <<<Back 1 day (to 2018/08/30) | 20180831 |
| tor8 | paulgardiner: okay, I have some rudimentary in-place text field editing in mupdf-gl on tor/master now | 11:46.35 |
| | the pdf_pass_event and how doc->focus is handled and needs to sync up is making things a bit more complicated than they should be :( | 11:47.12 |
| paulgardiner | Oh great. I'll take a look. Does the text layout during editing match the final layout? Since you said rudimentary, I'd imagine not for now, but more wondering if that is what you eventually intend. | 11:52.20 |
| tor8 | no, not at all | 11:52.42 |
| | I just overlay a standard text field on top | 11:52.49 |
| | and apply formatting once you 'commit' by hitting enter or changing focus | 11:52.58 |
| paulgardiner | Ah, I was hoping to eventually match how AR works | 11:53.25 |
| tor8 | which seems to be roughly how AR works | 11:53.32 |
| | AR has different font and text positioning when you're editing | 11:53.51 |
| paulgardiner | I thought AR handles all the different cases while editing (e.g., combed) | 11:54.02 |
| tor8 | eventually I might look into matching font and font size | 11:54.04 |
| | yeah, combed text it might do. but the actual text rendering and positioning differs when editing and when not editing | 11:54.26 |
| paulgardiner | Strange. I've never seen that from AR | 11:55.22 |
| tor8 | I could've sworn I saw that | 11:56.15 |
| | but now I can't :( | 11:56.18 |
| | bollocks! | 11:56.37 |
| paulgardiner | :-) | 11:56.48 |
| tor8 | I really don't fancy replicating the insane heuristics for the text appearance synthesis in the UI text widget too :( | 11:59.12 |
| | then I might just be better off implementing text editing directly on top of the pdf_obj text field, and have some abstract notion of current selection/cursor position and feed that back to the UI | 12:00.04 |
| | but ugh... | 12:00.10 |
| | keybindings etc | 12:00.21 |
| | can we decide to just not do in-place widget editing? :) | 12:00.50 |
| paulgardiner | I wonder if it would be too bad just repeatedly rerendering the annot | 12:08.28 |
| tor8 | paulgardiner: well, you want to be able to select text by clicking | 12:19.54 |
| | feeding that info back up is going to be a pain in the ass | 12:20.05 |
| | still, I think if you can just get the line start positions and use a matching font you ought to be able to trivially match the appearance | 12:20.36 |
| | if you re-fetch tor/master I have one that matches the font size which makes a huge difference | 12:21.06 |
| paulgardiner | I thought you had plans to add some sort of annot editor to the mupdf library based on the annot rendering code | 12:29.36 |
| tor8 | paulgardiner: for text fields you mean, or for every type of annotation? | 12:30.53 |
| paulgardiner | Yeah text widgets | 12:31.21 |
| | I may have misunderstood | 12:31.36 |
| tor8 | I'm reluctant to put any type of UI code and behavior into the library, but I was thinking of an exception to allow for in-place text field editing | 12:31.43 |
| paulgardiner | Yes, I think an exception makes sense for that. | 12:32.18 |
| tor8 | essentially duplicate what is in platform/gl/gl-input.c and put in communication hooks for drawing the selection highlight and passing the mouse and keyboard events | 12:33.01 |
| paulgardiner | Actually, for what I'd like to do in iOS, just being able to apply the current selection functions to a single widget might be enough. | 12:33.02 |
| tor8 | so you'd pass mouse input and keyboard and a selection state struct to something like pdf_edit_text_widget() and that would update the appearance stream and then you'd repaint the annot | 12:34.13 |
| paulgardiner | In the apps, it's not hard to add highlighting and caret, provided you have a way to ask where things are | 12:34.24 |
| tor8 | or get a list of characters, positions, sizes, and selection rectangles that would match the appearance if you want more performance | 12:34.41 |
| paulgardiner | Oh I see. That could work well too. | 12:34.47 |
| tor8 | or just feed back the highlight selection/caret | 12:34.58 |
| | and the appearance stream would only change on actual edits | 12:35.05 |
| | and leave the drawing of highlights to the app | 12:35.13 |
| | but then we'll not gain the nice benefits of whatever native UI system text field features and key bindings are used | 12:35.59 |
| sebras | tor8: https://lwn.net/Articles/763875/rss | 12:36.06 |
| tor8 | things like input method editors, etc | 12:36.10 |
| kens | sebras yes that was in the Register this morning | 12:36.42 |
| paulgardiner | iOS has a clever way to integrate the system's text input features with library-drawn text | 12:36.43 |
| | I imagine Android does too. | 12:37.01 |
| tor8 | sebras: let me guess -- C++ and Java | 12:37.04 |
| | paulgardiner: is there a list of text editing commands that get passed between the system and app then? | 12:38.01 |
| | or does it just expect to handle all text editing in the system, but ask the app for text layout and rendering only | 12:38.27 |
| | and the system sends back new text as it's being changed | 12:38.55 |
| | and queries for the layout of the text | 12:39.03 |
| paulgardiner | There's an interface called UITextInput that must be implemented | 12:39.20 |
| | It allows the system to ask about positions and ranges within the widget | 12:39.52 |
| | positions in terms of indexes, although it also asks for rects at times | 12:40.14 |
| inflex | Where is the colour of the font or runes kept? I'm trying to prevent my code from selecting watermark text (which currently dominates the page on some PDFs that I'm using) | 12:41.02 |
| tor8 | massively complicated (but hey, it's apple) but it seems to be along the second of my ideas | 12:41.14 |
| | where it handles all the editing, and just sends new text down and asks for positions and hit testing | 12:41.29 |
| paulgardiner | positions(text indexes) and ranges are abstract and defined by the app. The system says things like "give me the beginning position" "give me the position 4 chars to the right of this one" | 12:41.36 |
| | Make a range between these two positions | 12:41.50 |
| | substitute this text for what's in this range | 12:41.59 |
| tor8 | paulgardiner: yeah, and it has a 'give me the text for this range' | 12:42.01 |
| | and 'change the text in this range' | 12:42.07 |
| paulgardiner | yep | 12:42.13 |
| | Give me a set of rectangles for the range | 12:42.29 |
| | ... although so far we've gotten away without implementing that one for SmartOffice, because it handles the selection highlight internally | 12:43.02 |
| inflex | Currently I'm working in fz_enumerate_selection(), wondering if perhaps the color data I'm after isn't accessible from that point | 12:43.14 |
| tor8 | I don't see where it tells the UITextInput about the selection, just querying (maybe I'm blind) | 12:43.20 |
| | inflex: the extracted text structures don't hold color information | 12:44.01 |
| | because things are never as simple as being a color -- text could be a clip path, or gradient, or pattern fill, etc. | 12:44.24 |
| inflex | Well, in one way, I'm happy, to know that I wasn't missing the obvious; in another, that's problematic as the water mark keeps getting selected. I'm trying to see if I can just ignore based on character size thresholds, the other option would be the angle of the text, though I can't see that either. | 12:45.16 |
| tor8 | inflex: in enumerate selection, you can compute the angle from the quad | 12:45.58 |
| | if you're using the up to date mupdf which has fz_quad instead of just fz_rect for selections | 12:46.15 |
| inflex | I'll check | 12:46.30 |
| tor8 | or if you're looking through the fz_text_page structs yourself, there's a fz_stext_line.dir for direction | 12:46.42 |
| inflex | I did see the dir field, wasn't sure if that was just up/down/left/right, but thanks | 12:47.08 |
| tor8 | it's a vector pointing in the direction of the baseline | 12:47.21 |
| inflex | thanks | 12:47.45 |
| | Looks like I'm stuck with the fz_rect. Not sure I'm so keen on having to rewrite everything; though I imagine most of the changes are more in the areas other than the gl-main.c | 12:48.41 |
| | I'll use the 'dir' field. How complex would it be for me to add in the colour information to the char? | 12:49.24 |
| tor8 | paulgardiner: so I think you ought to be able to implement a UITextInput thing if we add a function like pdf_layout_text_widget which returns an array of characters and their positions and sizes? | 12:49.40 |
| | which is something we can compute using a function shared with the appearance synthesis | 12:50.13 |
| inflex | thanks anyhow tor8, the dir field should work out | 12:50.36 |
| tor8 | sebras: yes, very much c++ | 12:51.40 |
| | sebras: and Go and Java and a bunch of others | 12:51.59 |
| paulgardiner | tor8: I need to think that through, but first reaction is yes, although - your having already implemented a very nice set of functions for deriving selections from points - I'd like some way to make use of those too. | 12:52.13 |
| tor8 | paulgardiner: well ... if we make fz_layout_text_widget return the same structured text data structure that could be easy enough :) | 12:53.17 |
| paulgardiner | ... oh maybe the OS does the selection | 12:53.19 |
| | Ha. Yes that's a point. | 12:53.36 |
| tor8 | but I think the OS does everything if you just hand it 'here's the text and their positions' and it just feeds back 'change this now!' | 12:53.43 |
| paulgardiner | I think you may be correct | 12:53.53 |
| tor8 | and it asks the app to draw the text, and it (maybe) draws the selection itself | 12:54.07 |
| paulgardiner | If it doesn't, it would not be hard to do it in the app layers | 12:54.39 |
| tor8 | yeah, so I think a function to hand back text and corresponding hit-test locations ought to be enough for the apps to hook into something like UITextInput | 12:55.47 |
| paulgardiner | tor8: and then to update the text, would we reset the text of the widget and rerun layout? | 12:58.19 |
| tor8 | yeah. | 12:58.28 |
| | and the appearance stream would be regenerated and everything redrawn (slowly) | 12:58.44 |
| paulgardiner | Well not too bad for smallish strings | 12:59.16 |
| tor8 | though it might be possible to just rerun the layout and do an equivalent render from just the fz_stext_page structs | 12:59.21 |
| | but if text is rotated, that might be trickier than worth bothering with. it may be just fast enough to re-render from the appearance stream... | 12:59.56 |
| | if we keep the widget in its own pixmap and only re-render the widget itself and not the whole page | 13:00.17 |
| paulgardiner | Yes, that was my intention too. | 13:00.34 |
| | Might do that for all the widgets or maybe just the focussed one | 13:00.56 |
| tor8 | yeah. I'd suggest doing it for all, because then you don't need to pull the focussed one out of the page pixmap when the focus changes | 13:01.27 |
| | if you can do multiply blend mode when drawing pixmaps to the UI you can do it for all annotations too | 13:02.00 |
| | and not just widgets | 13:02.04 |
| | highlight annotations need multiply blend modes | 13:02.14 |
| | everything else is just a simple alpha blend | 13:02.19 |
| paulgardiner | Okay. That sounds good. | 13:02.36 |
| tor8 | I'll make a note to write a pdf_layout_tx_widget that returns a fz_stext_page | 13:02.53 |
| | and matches the layout of the appearance synthesis | 13:03.19 |
| paulgardiner | Excellent | 13:03.46 |
| tor8 | paulgardiner: or you could do something even more horrible | 13:04.13 |
| | when rendering the annotation to a pixmap, also render just the annotation to a stext_device :) | 13:04.27 |
| | and then you have your fz_stext_page... | 13:04.37 |
| | make a fz_new_stext_page_from_annot in source/fitz/util.c and you might just have it already :) | 13:06.13 |
| paulgardiner | Oh, that's interesting. | 13:07.10 |
| tor8 | paulgardiner: top of tor/master has one | 13:09.22 |
| inflex | tor8, solved it, thanks. At least for watermarks that are at odd angles. | 13:15.07 |
| | Solution was to put it in the find_closest_in_page() function. | 13:16.04 |
| paulgardiner | tor8: Thanks. Can't look just now, but will soon | 13:21.36 |
| | Forward 1 day (to 2018/09/01)>>> | |
Log of #mupdf at irc.freenode.net.