| | <<<Back 1 day (to 2016/08/01) | 20160802 |
| sebras | Robin_Watts: hm... I thought that the idea of StructuredText was to provide the apps with convienent interfaces to use for searching/highlighting/etc. | 12:05.41 |
| | Robin_Watts: but you seem to be advocating that StructuredText should not provide e.g. .search() and .copy() and .highlight()? | 12:06.16 |
| Robin_Watts | sebras: The idea of structuredtext is to provide a sufficiently general and convenient interface that can be used for all those things. | 12:06.41 |
| | I want to see StructuredText being powerful enough to do all those things, and more. | 12:07.06 |
| sebras | Robin_Watts: ok, but not provide those interfaces itself? only the building blocks for the apps to build upon? | 12:07.12 |
| Robin_Watts | What I don't want to see is StructuredText being *just* capable of doing *just* the things that we can think of. | 12:07.32 |
| | StructuredText returns a list of pages, of lines, of spans or chars (or something like that). | 12:08.52 |
| | s/or/of/ | 12:08.59 |
| sebras | in that case I guess StructuredText should really provide just the glyphs and positions and boundingboxes of each character and not bother with trying to segment it into words/lines/columns. | 12:09.01 |
| | but we do right now, no..? | 12:09.23 |
| Robin_Watts | sebras: Right. | 12:09.27 |
| | Except that currently that returned structure is both more and less processed than we might want for any given application. | 12:10.10 |
| | Having options in the device for how much processing is done seems like a good idea to me. | 12:10.29 |
| | But once we've got that structure out, all the processing on it should be done in java, I think. | 12:11.03 |
| sebras | Robin_Watts: by doing so I'm fearing that different apps will handle text differently. so you e.g. on iOS MuPDF can handle ligatures and on android it can't..? | 12:11.54 |
| | Robin_Watts: sure, the core library would indeed be very simple! :) | 12:12.13 |
| Robin_Watts | I'm clearly not being clear. | 12:12.25 |
| | Where we can encapsulate code into the central library, great. ligature handling is an example of that. It should be an option on the central device. | 12:12.58 |
| sebras | Robin_Watts: either that or I'm not a good student. or both. :) | 12:12.59 |
| Robin_Watts | But where we have other bits of code, that aren't in the central library, they should be done at the java level, not in the C. | 12:14.14 |
| | For instance, suppose we have some code that maps from a click in an android view to which part of the text it's on. | 12:14.47 |
| sebras | Robin_Watts: mmm, like the problem fredross-perry is working on. | 12:15.12 |
| | s/problem/feature/ | 12:15.24 |
| Robin_Watts | Exactly (unless I'm misunderstanding what fred is doing) | 12:15.35 |
| | We offer an API for doing 'stuff' with PDF files. | 12:16.03 |
| sebras | Robin_Watts: I'm not entirely sure what he's attempting to do, but I think he wants to do something similar to StructuredText.highlight()..? | 12:16.16 |
| Robin_Watts | We want that API to be broadly the same in all the different languages. | 12:16.17 |
| | sebras: Well, if the core has a StructureText.highlight() API, then that same API should be exposed through JNI for java to call it. | 12:17.06 |
| sebras | Robin_Watts: but as I understand it he's seeing that the entire line is highlighted instead of just a single... word? I think that's what he's looking for. | 12:17.08 |
| Robin_Watts | sebras: If our API is not powerful enough to cope with the uses people want to put it to, then we should fix it. | 12:17.48 |
| | But what I don't want to see is for the apps to have to code a load of new JNI stuff to work around problems in the API. | 12:18.28 |
| | Either our API is good enough, and everything the app needs to do can be done purely in java, or it's not, in which case there is a flaw in our API and we should fix it. | 12:18.54 |
| | Having the app need to dip in and out of JNI in app-specific code feels really wrong to me. | 12:19.17 |
| sebras | right, but the question is also at what level the JNI should be at. | 12:19.41 |
| Robin_Watts | sebras: The JNI should be the thinnest layer over the C it can manage to be, subject to it giving a java interface that seems as 'normal' as possible to java programmers. | 12:20.37 |
| | (which I accept is a statement with some hand waving involved) | 12:20.50 |
| | Take, the Matrix class for example. | 12:21.16 |
| sebras | Robin_Watts: :) | 12:21.17 |
| Robin_Watts | We could have implemented Matrix on top of fz_matrix. Which would have involved having a native fz_matrix structure for each Matrix, and accessors etc. | 12:21.49 |
| | We (I) chose not to do that, and instead Matrix is a purely java thing. | 12:22.11 |
| sebras | Robin_Watts: and we chose not to. I'm guessing to avoid JNI-translation overhead? | 12:22.22 |
| Robin_Watts | because it means people can do m.a etc rather than m.getA(); | 12:22.29 |
| | sebras: partly JNI overhead, but mostly because it would not have felt as normal. | 12:23.02 |
| | (we have different overheads, cos now the JNI has to construct fz_matrixes from the Matrix on each call) | 12:23.35 |
| sebras | Robin_Watts: I haven't read up on the JNI spec concerning fields until now, but there only seems to be methods to read/write the value, not to get a callback whenever the field changes value. | 12:25.43 |
| Robin_Watts | sebras: Indeed. | 12:25.58 |
| sebras | Robin_Watts: that's.... annoying. | 12:26.07 |
| Robin_Watts | sebras: Yes. The alternative would, I suspect, have profound implications for the way threading has to work. | 12:26.32 |
| | imagine the callbacks calling synchronised things that might be synchronised already. | 12:26.58 |
| sebras | Robin_Watts: I'm thinking that fred's current issue stems from the fact that StructuredText provides a user with textspans where the contents of the span can be words separated by spaces and so the span's bounding box ends up covering the entire line. while MuPDFCore_text returns the raw text without synthesized spaces into the spans. | 12:28.22 |
| Robin_Watts | sebras: Possibly, I have to confess to be being rather buried in SOT at the moment, so I haven't looked in detail. | 12:28.53 |
| sebras | Robin_Watts: you don't need to. that's what I'm paid to look at. :) | 12:29.19 |
| Robin_Watts | The spans bbox can end up covering the whole line - but the chars within the line have bboxes of their own, right? | 12:29.32 |
| sebras | Robin_Watts: but I need to discuss a bit so I know what direction the API should be heading in. | 12:29.36 |
| | Robin_Watts: I think so, but maybe not after processing. let me have look. | 12:30.24 |
| Robin_Watts | I don't see how they can't have. The 'char' structure (whatever that is called) contains a bbox. | 12:30.52 |
| | mutool.exe draw -o - -F stext ../MyTests/pdf_reference17.pdf 1 | 12:31.18 |
| | That shows the data in a convenient textual form. | 12:31.32 |
| sebras | Robin_Watts: I know, but it all depends on what fz_highlight_selection() actually does. | 12:31.49 |
| | Robin_Watts: this is the call that StructuredText.highlight() actually wraps. | 12:32.00 |
| Robin_Watts | sebras: Right. | 12:32.39 |
| | AIUI, that takes a single bbox rectangle, and returns a (hopefully minimal) list of rectangles for the text that is completely covered by that rectangle. | 12:33.24 |
| | s/list of rectangles/list of highlight rectangles/ | 12:33.43 |
| sebras | Robin_Watts: yes, but that returned list of rects each represent what..? a character? a word? a line? | 12:34.09 |
| | that's what I'm getting it. :) | 12:34.13 |
| Robin_Watts | sebras: Why does that matter? | 12:34.33 |
| | I personally might hope that all chars in the same font would be run together in a rectangle, so my selection doesn't vary in height wildly across a line. | 12:35.45 |
| sebras | Robin_Watts: so fred described that his problem is that he wants to be able to highlight highlight partial lines of text in the android app. | 12:35.48 |
| Robin_Watts | sebras: Right. It strikes me that Fred is looking to do a different style of highlighting. | 12:36.10 |
| sebras | Robin_Watts: fz_highligh_selection() does indeed return a sequence of rects each representing possible subset of the characters in each stext line. | 12:36.33 |
| Robin_Watts | The existing 'highlight()' stuff looks like it's designed for the way selection was done in the win32/linux viewer. | 12:37.02 |
| | Right hand drag to give a rectangle, select what's in that. | 12:37.13 |
| sebras | fz_highlight_selection() appears to cater to the -x11 -gl apps way of highlighting using the right mouse button. | 12:37.19 |
| | indeed. | 12:37.29 |
| Robin_Watts | A *nicer* more standard way of working would be to start to drag at the start of the word you want, and drag to the end of the word you want. | 12:37.42 |
| sebras | and have the *entire* lines inbetween being highlighted? | 12:38.22 |
| Robin_Watts | Now, either we want that to be implemented in every app by itself (in which case it should be done in java, with no new JNI code), or it should be implemented as a new core function, in which case we 'just' need the new JNI to expose that. | 12:38.39 |
| | sebras: Typically you'd expect a partial line, a number of complete lines, and then a partial line at the end (in the general case) | 12:39.08 |
| | (I appreciate that you use vi, and therefore might have insane expectations :) ) | 12:39.57 |
| sebras | Robin_Watts: in vi you have both box selection (similar to fz_highlight_selection()) and the Standard<tm> version of selection you mention. | 12:40.54 |
| | and actually you have whole line selection as well (i.e. select the entire line even in you start the selection halfway in). | 12:41.26 |
| Robin_Watts | sebras: Right. I think most people in this day and age would expect 'Standard' selection (as seen in most standard gui apps) | 12:41.36 |
| | (Think the way Word and acrobat etc handles selection) | 12:41.53 |
| sebras | Robin_Watts: we should at least cater for apps wanting to implement it. | 12:42.07 |
| | Robin_Watts: but to do so means that StructuredText must allow for iteration over all the blocks/lines/spans in it. | 12:42.30 |
| | Robin_Watts: and today that is not exposed though the JNI. | 12:42.38 |
| Robin_Watts | Right. | 12:42.51 |
| sebras | Robin_Watts: only StructuredText.highligh() is available (and implements the non-standard version) | 12:42.56 |
| Robin_Watts | Right, so we need to ensure that the Blocks/Spans/Chars information is exposed through the JNI. | 12:43.21 |
| | I hadn't entirely twigged that we weren't there already. | 12:43.30 |
| | Maybe that's what Fred was implementing when he said he was doing JNI. | 12:43.47 |
| | If so, then I think he's entirely correct. | 12:43.54 |
| sebras | Robin_Watts: unless we want to implement the highlighting method in the C-library, which we alreayd chose for one highlighting method. | 12:43.57 |
| Robin_Watts | Though I suspect that we want that to follow the Matrix school of thought there. | 12:44.24 |
| sebras | Robin_Watts: yes, _now_ that I understand what he meant I can see the issue at hand. :) | 12:44.27 |
| | Robin_Watts: well, in that case fz_highlight_selection() should be moved to pdfapp.c right..? | 12:44.48 |
| Robin_Watts | sebras: Having a core function to do this stuff would be fine too - but it shouldn't be the ONLY way it can be done. | 12:45.11 |
| sebras | Robin_Watts: and the C api should only expose fz_text_span or whatever the underlying type is called that stext device is creating. | 12:45.16 |
| Robin_Watts | I see fz_highlight_selection as being a helper function rather than a core api function. | 12:45.55 |
| sebras | Robin_Watts: hm. so we placed it together with the other helpers in source/fitz/stext-search.c instead of source/fitz/stext-device.c which contain the core parts..? | 12:47.01 |
| | Robin_Watts: /me learns what parts we consider core and which are helpers (I assumed all C-code was considered to be core) | 12:47.25 |
| Robin_Watts | sebras: In general (and I say this with my fingers crossed, cos we've not always been perfect about such things) we try and separate stuff into different files that we want to be linkable separately. | 12:48.41 |
| | It would be a shame for every app that uses the structured text device to have to have the code for fz_highlight_selection within it, even if it was never called. | 12:49.22 |
| | Hence we put fz_highlight_selection into a separate C file, so it can dropped at link time if it's not used. | 12:49.55 |
| | (Some compilers that support function level linking could manage with it in the same file, but by no means all). | 12:50.13 |
| | In general, I think of 'helper' functions as being those that could be implemented without needing to peek behind the curtain. | 12:50.45 |
| | (i.e. stuff that could be implemented entirely outside the app, using no internal magic or knowledge). | 12:51.21 |
| sebras | Robin_Watts: right. so then basically we'd need a Java-based StructuredText.iterateBlocks() which returns something that you can iterate over lines using, which returns something you can iterate over spans using. | 12:51.29 |
| Robin_Watts | We have no official distiction though. | 12:51.35 |
| | sebras: That would be one way to do it, but it would not be my favourite. | 12:51.55 |
| sebras | Robin_Watts: you'd prefer StructuredText.blocks[] ? | 12:52.20 |
| Robin_Watts | I would rather see us convert the native blocks/spans/chars information into .... yes that. | 12:52.25 |
| sebras | Robin_Watts: right. | 12:52.32 |
| Robin_Watts | more akin to Matrix. | 12:52.35 |
| | (At least, I think that's what I prefer. I'm open to arguments against that) | 12:53.01 |
| | (One argument against that would be that if we want to be able to pass the results of a structured text extraction back into a helper function, we'd really like to have the C level results available for us to pass back) | 12:53.40 |
| sebras | Robin_Watts: I'm not smart enough to make a convincing argument opposing it. :) I must try it first and fail in order to discover that this proposal doesn't hold water. :) | 12:53.45 |
| | Robin_Watts: why sould we want to push it back into some helper? pasting? | 12:54.30 |
| | Robin_Watts: that's the only thing I can come up with. | 12:54.38 |
| Robin_Watts | fz_highlight_selection for example./ | 12:54.45 |
| sebras | Robin_Watts: but that takes a single rect, not a series of them. | 12:55.06 |
| Robin_Watts | Suppose I run the stext device on a page and I get some 'Results' back. | 12:55.08 |
| | Then fz_highlight_selection has to take those 'Results' and a rectangle, and return a list of rectangles. | 12:55.39 |
| | So that would like 'Results' to be an fz_stext_page. | 12:56.04 |
| | BUT... in order for us to work nicely on it in java, we'd like the results to be an STextPage | 12:56.33 |
| sebras | 'Results' is called StructuredText today. and StructuredText.highlight(Rect area) returns Rect[] based on the rect supplied. | 12:56.50 |
| Robin_Watts | sebras: Right, and presumably a StructuredText has a secret pointer to an fz_stext_page underneath it? | 12:57.29 |
| sebras | indeed. | 12:57.47 |
| Robin_Watts | Maybe I want something like StructureText.getObjects(); which would actually return me the java version. | 12:58.19 |
| | and for completeness (if we ever need it) we could have a constructor new StructuredText(objects) that would do the reverse. | 12:59.13 |
| sebras | Robin_Watts: what if I implement a few nested classes StructuredText.Block, StructuredText.Line, StructuredText.Span and use these to create an all Java tree of objects when doing Page.toStructuredText. That way you can do StructuredText.highlight() and use fz_highlight_selection(Rect area) as today, or you can work on the underlying Java objects directly. | 12:59.52 |
| Robin_Watts | sebras: That might be what Fred is doing. We should double check that we aren't duplicating work, but yes, something like that sounds right to me. | 13:00.55 |
| sebras | Robin_Watts: doing this for PDFs will be cheap, but what about for epub where a page supposedly spans a whole chapter..? | 13:01.01 |
| Robin_Watts | A page doesn't not span a chapter with epub. | 13:01.17 |
| sebras | Robin_Watts: it might be. I didn't understand the problem he's been having (until now) so I haven't been able to help out so far. I'm awaiting the meeting to ask him about it. | 13:01.38 |
| Robin_Watts | epubs are going to be interesting... | 13:01.49 |
| | I'm going to spin the windows update roulette wheel while I get some lunch. | 13:02.02 |
| sebras | Robin_Watts: and the lucky winner is..? :) | 13:02.49 |
| Robin_Watts | me, as long as it doesn't come up with 0 :) | 13:03.03 |
| sebras | is lucky Robin is patient. | 13:09.35 |
| Robin_Watts | is notorious for being impatient, but you've not even come close to triggering it :) | 13:10.23 |
| sebras | Robin_Watts: one thing I don't feel comfortable with (and tor8 knows this) is designing interfaces. I haven't done so frequently so I feel I'm not really good at it while I know that tor8 has a lot of experience in that area. | 13:15.05 |
| | Robin_Watts: or rather... designing flexible and obviously optimal interfaces. | 13:15.55 |
| Robin_Watts | sebras: No one gets it right first time every time. | 13:19.07 |
| | You just make a stab, and then learn a bit so that hopefully it's better next time. | 13:19.27 |
| | I confidently predict that whatever we come up with won't be perfect, but if it isn't we refine it later. | 13:19.53 |
| HenryStiles | Raph's been busy: https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445#.q26yignvk | 13:43.17 |
| kens | If only font rendering were the bottleneck in average poduction..... | 13:46.28 |
| | Also, for Latin fonts, once the glyph is drawn and cached, it doesn't metter much how fast the original rendering was | 13:47.00 |
| | Its not at all obvious where the performance difference vs FreeType comes in, and I suspect that a large part of that is his code simp[ly not bothering to deal with all the edge cases, old versions of TrueType, obselete versions of the FT spec and simply badly broken fonts, which FreeType does deal wioth | 13:48.30 |
| | I'd have been more interested if he'd ported his rendering into FT, leaving the parsing in place, as a demonstration of the speed of the algorithm. If he wants to demonstrate that Rust is a better language for de4velopment than, sya, C, he needs to do the development in btoh languages and show that the Rust version is at least as good, preferably better, than the C implementation of the same algorithm | 13:50.23 |
| | We used to have someone come round the trade shows regularly touting thei PostScript 'tokeniser' because it was 'blindingly fast', which was true, but missed hte point that very little time is usually spent tokenising PostScript. | 13:51.12 |
| | I fear this is a similar exercise | 13:51.31 |
| Robin_Watts | skimmed Raphs article briefly. I can't see anything in there that would beat the SOT font renderer. | 13:59.03 |
| | And the SOT font renderer (the patented version at least) skips one of the slowest steps too. | 13:59.42 |
| | The end product is not a bitmap for caching, but rather an RLE encoded version, so plotting is faster too. | 14:00.19 |
| HenryStiles | so the RLE representation is cached? | 14:03.12 |
| Robin_Watts | HenryStiles: Yes. | 14:03.19 |
| | Possibly we should be doing this on #artifex :) | 14:03.32 |
| HenryStiles | or sorry yes | 14:03.49 |
| fredross-perry | Robin, Sebras - I have StructuredText returning an array of blocks, blocks return an array of lines, etc, down to chars. So four classes, reflecting fz_stext_block, etc. | 14:26.28 |
| | The app can figure out words (I figure). | 14:26.52 |
| Robin_Watts | fredross-perry: You mean you have a method call in StructuredText to get a pure java representation of the results? | 14:27.23 |
| fredross-perry | The type of selection I'll do is what you'd expect in any text editor, either partial or whoe lines, but not an arbitrary block in the middle. | 14:27.56 |
| Robin_Watts | fredross-perry: Sounds reasonable, yes. | 14:28.19 |
| | So that relies on the text extraction returning stuff in a sane order. | 14:28.51 |
| fredross-perry | Yes, a JNI function added to StructuredText that returns an arra of Java objects, each one representing an fz_stext_block. Then on down. | 14:29.11 |
| | I suppose. Same code as the old viewer in that regard. | 14:29.49 |
| Robin_Watts | Right, so the user calls StructuredText to get an fz_stext_page, and that is stored in the StructuredText so that we can do StructuredText.get_selection_highlight() etc. | 14:30.33 |
| | But your new code is that we can do: StructureText.getFooBar() and it'll return the pure java representation. | 14:30.55 |
| | (where getFooBar is a better name than my brain can come up with at the moment) | 14:31.10 |
| fredross-perry | It's StructuredText.blocks(), TextBlock.lines(), TextLine.spans(), TextSpan.chars() | 14:32.24 |
| Robin_Watts | StructuredText.blocks() I understand. | 14:32.56 |
| | I would have expected that to have been an array of Blocks. | 14:33.18 |
| | and for each Block to be (or have) an array of lines | 14:33.34 |
| fredross-perry | it is. | 14:33.38 |
| Robin_Watts | So why is is TextBlock.lines()? | 14:33.54 |
| | Surely it should be TextBlock.lines ? | 14:34.07 |
| fredross-perry | TextBlock.lines returns an array of TextLines. | 14:34.10 |
| sebras | reads. | 14:34.14 |
| Robin_Watts | i.e. it's a member variable, not a method function. | 14:34.24 |
| fredross-perry | I did it as functions (easier) | 14:34.27 |
| Robin_Watts | easier maybe, but less expected from a java perspective. | 14:34.45 |
| fredross-perry | eh. | 14:34.51 |
| | not sure I agree with that. | 14:35.37 |
| Robin_Watts | My gut says that a java programmer would expect an array of stuff to be a member. | 14:36.02 |
| | rather than a function to return an array. | 14:36.11 |
| sebras | Robin_Watts: java programmers are probably expecting iterators. | 14:36.37 |
| Robin_Watts | Also, a java programmer can update an member, wheras he can't update what a function returns. | 14:36.41 |
| | My gut may be wrong :) | 14:36.53 |
| fredross-perry | Not sure we want to update? | 14:36.54 |
| sebras | fredross-perry: sorry I didn't help out with the implementation. I didn't understand the problem until this evening. | 14:37.24 |
| Robin_Watts | fredross-perry: Suppose I do a text extraction on a page, and then want (in java) to filter it so that I only keep the Chinese glyphs) | 14:37.33 |
| fredross-perry | sebras - no problem. | 14:37.44 |
| Robin_Watts | For that, I'd want to be able to change the data. | 14:37.54 |
| fredross-perry | robin - for that I'd (tha app) be keeping a filtered copy of the data. | 14:38.19 |
| sebras | fredross-perry: in a app specific data structure I imagine..? | 14:38.34 |
| fredross-perry | 'cause when I want to do it again, this time filtering differently, I can. | 14:38.39 |
| | yes, app-specific. | 14:38.49 |
| Robin_Watts | It feels wrong for me to force that on people. | 14:39.06 |
| | Using iterators would be right, IMAO, if we were generating the results as we went. | 14:39.24 |
| sebras | Robin_Watts: otoh we don't know that they want to filter text, right..? | 14:39.31 |
| Robin_Watts | But we aren't. The data has been generated already, so why not have it all accessible at once? | 14:39.52 |
| fredross-perry | we don't know a priori really WHAT they want to do with the text. | 14:39.54 |
| Robin_Watts | sebras, fred: Indeed not. | 14:40.03 |
| fredross-perry | all at once - that was the approach in the old view, that I thought I was trying to avoid. | 14:40.37 |
| sebras | Robin_Watts: you don't envision the stext changes to be affecting the rendered text right..? just that the app can keep a filtered text around (e.g. using only the chinese characters). | 14:40.48 |
| Robin_Watts | But having the data all available as a pure java structure which doesn't require any iterations, and allows it to be updated if they want (or cloned into an app specfic structure if they way), is more general. | 14:40.58 |
| | sebras: Absolutely. The java representation of the data is not "live" in any sense. It's a "dead" snapshot of data. | 14:41.31 |
| | fredross-perry: I don't follow the "all-at-once" thing being what we are trying to avoid. | 14:42.11 |
| sebras | fredross-perry: if we want to do a String[blocks][lines][spans] it shouldn't be too hard to do that when creating StructuredText, right..? | 14:42.12 |
| | fredross-perry: and store that as public member inside StructuredText. | 14:42.44 |
| Robin_Watts | sebras: Right. | 14:42.46 |
| fredross-perry | No not too hard (I suppose). | 14:42.55 |
| sebras | Robin_Watts: ^^ but doing so would mean that we lose the connection to fz_stext_page and hence fz_highlight_selection() would fail to take any updated text into account. | 14:43.15 |
| Robin_Watts | sebras: Doing it freds way has the same limitation. | 14:43.36 |
| sebras | Robin_Watts: not really. | 14:43.49 |
| Robin_Watts | how so ? | 14:43.59 |
| sebras | Robin_Watts: since fred is advocating not altering that data. | 14:44.01 |
| | Robin_Watts: so fz_stext_page and whatever is stored in StructuredText is identical, just different representations. | 14:44.31 |
| Robin_Watts | sebras: But when you call TextBlock.getLines() you get a java array back. | 14:44.38 |
| | (in freds world) | 14:44.42 |
| sebras | Robin_Watts: correct. | 14:44.46 |
| Robin_Watts | changing that array will NOT change the underlying data. | 14:44.51 |
| | We *could* have a 'setLines' call that would, but no one is suggesting that, I think. | 14:45.14 |
| sebras | Robin_Watts: ah! ah! aaaah! got it! now I agree with you. :) | 14:45.16 |
| Robin_Watts | :) | 14:45.30 |
| fredross-perry | I think there the data, and there are "views" of the data. The "take out these glyps" for me is a different view. The doc is static (unless it's not?) | 14:45.53 |
| sebras | fredross-perry: the document is not necessarily static, but it would be app updating the document so it would know if it has modified any text, in which case it needs to call toStructuredText() again. | 14:46.34 |
| | so this means that there are no immutable arrays in java? | 14:47.38 |
| fredross-perry | Collections.unmodifiableList ?? | 14:48.21 |
| Robin_Watts | There are no immutable arrays. | 14:49.31 |
| | You can use "Lists" etc, but then those aren't arrays, and can't be accessed as such. | 14:49.50 |
| | (hence are "surprising") | 14:49.58 |
| sebras | right, http://stackoverflow.com/questions/16356232/unmodifiable-list-in-java mentions this. | 14:51.14 |
| | but then again, maybe this is more of a Java<tm> approach? | 14:51.34 |
| fredross-perry | So I will pursue the member variable route, and build it all up at the time that StructuredText is created. | 14:52.27 |
| Robin_Watts | fredross-perry: Urm... | 14:52.46 |
| fredross-perry | or not! | 14:52.52 |
| Robin_Watts | could I suggest a really small tweak to that? | 14:52.54 |
| fredross-perry | sure | 14:52.59 |
| Robin_Watts | StructuredText is basically a wrapper for an fz_stext_page, right? | 14:53.17 |
| fredross-perry | sure | 14:53.27 |
| Robin_Watts | so when StructuredText is made, don't make the java equivalents. | 14:53.48 |
| | Only make the java equivalents when 'blocks()' is called. | 14:54.03 |
| | and don't keep a copy of those java equivalents anywhere in StructuredText. | 14:54.21 |
| | That way the caller can modify them, chop 'em about etc without us needing to worry about us getting the modified versions when we call blocks() again. | 14:54.56 |
| fredross-perry | You do realize this is basically the same as the way the old viewer does it? | 14:55.23 |
| Robin_Watts | It does mean that the caller needs to keep the results of blocks() around for as long as he wants to avoid it being regenerated. | 14:55.52 |
| fredross-perry | That's true of my current approach as well. | 14:56.24 |
| Robin_Watts | fredross-perry: I have to apologise on that score. I thought you were wanting the processing of these blocks to be done under the JNI rather than the creation of these blocks. | 14:56.41 |
| | hence my pushing against that. | 14:56.54 |
| fredross-perry | No, just the creation. | 14:56.58 |
| Robin_Watts | my apologies if I have caused you extra work. | 14:57.02 |
| fredross-perry | accepted. | 14:57.16 |
| | ;-) | 14:57.25 |
| | to be fair, it's very hard to talk about these things in text messages, at this distance. | 14:57.59 |
| sebras | fredross-perry: indeed. I had a hard time understanding your problem, and it wasn't until I started discussing it with Robin_Watts that I truely understood your issue. sorry. :) | 14:58.53 |
| | fredross-perry: are you doing the new classes as nested classes inside StructuredText? | 15:01.30 |
| | I'm thinking that doing so would keep the namespace tidy. and I don't think it would create too much of a hassle. | 15:01.57 |
| fredross-perry | I was not. But I suppose that makes sense. | 15:02.01 |
| Robin_Watts | fredross-perry: I find I can be equally as incoherent in person. | 15:02.55 |
| | but at least via text I can re-read stuff to see what others/I said before. | 15:03.11 |
| fredross-perry | My issue is, there are three different places where I can find people, with intermingled conversations. So reading logs can be confounding sometimes. | 15:04.06 |
| sebras | fredross-perry: Robin_Watts: maybe we should settle on doing all the JNI discussions here? | 15:06.10 |
| Robin_Watts | fredross-perry: I've been working like this for 20+ years now. Actually meeting people is scary now. | 15:06.16 |
| | sebras: Sure. | 15:06.29 |
| fredross-perry | sure | 15:06.41 |
| sebras | fredross-perry: (I'm guessing that the third place is Skype? I'm not there at all) | 15:06.52 |
| fredross-perry | yes that's the third place. | 15:07.07 |
| Robin_Watts | sebras: Skype is used for SOT discussions, mainly. | 15:07.15 |
| | Originally because we didn't have #artifex, and #ghostscript isn't secure/private etc. | 15:07.43 |
| sebras | Robin_Watts: I know. | 15:07.54 |
| Robin_Watts | Skype has the advantage that Miles/Ted/Ron/Scott can use it, and I *cannot* imagine trying to get at least 3 of them onto #artifex. | 15:08.20 |
| sebras | Robin_Watts: the drawback with IRC is that it has no native logging. I can live with that, but if you're not a developer I'm sure you'd be annoyed. :) | 15:09.56 |
| Robin_Watts | sebras: Yeah, but we have logging 'solved'. | 15:10.26 |
| sebras | Robin_Watts: WORKSFORME. :) | 15:10.38 |
| | Robin_Watts: since fred will resolve the stext stuff on his own I'll spend some time attempting to do the flag thing for stext you suggested. | 15:11.52 |
| Robin_Watts | sebras: Cool. | 15:12.03 |
| fredross-perry | With Skype and other more modern chats, it is MUCH easier to search and look back just by scrolling. | 15:12.04 |
| sebras | Robin_Watts: that way we ought to be able to resolve the tab-issues fred saw. | 15:12.08 |
| Robin_Watts | yes. | 15:12.14 |
| sebras | I think IRC is the same as long as you're online (I have search in my client, and I assume yours have it too), but once you lose connection it is definitely annoying. | 15:13.49 |
| fredross-perry | sebras - I have one issue that I'll try to define bether. But it seems that when I get the text for a given selection, I'm getting an extra char at the beginning that's just outside the selection. If I select the area that contains the "ello" from "hello", I am getting the "h" as well. | 15:14.09 |
| sebras | fredross-perry: is that based on fz_highlight_selection() or your new method? | 15:15.10 |
| fredross-perry | fz_highlight_selection. | 15:15.30 |
| | but as I said, let me double-check. | 15:15.47 |
| sebras | fredross-perry: ok. I'm assuming you have an example in building.pdf readily available? :) | 15:16.10 |
| | fredross-perry: or this is true for all selection you do? | 15:16.24 |
| fredross-perry | I am just using StructuredText_highlight vs. StructuredText_copy. | 15:16.31 |
| | yes. But as I said, I need to double-check first. | 15:16.52 |
| sebras | fredross-perry: ok. I'll play around with the Java viewer and see if I can reproduce it. | 15:17.11 |
| fredross-perry | sebras - never mind, I think I've spotted my problem. | 15:28.46 |
| sebras | fredross-perry: ok, so it is resolved? was the issue in the JNI-bindings? | 16:13.58 |
| | fredross-perry: it almost sounded like a stray +1 somewhere. | 16:14.12 |
| fredross-perry | no. I used a (slightly) different rect when calling StructuredText_copy. | 16:14.47 |
| | pilot error. | 16:14.54 |
| sebras | fredross-perry: ok, at least it was easy to correct once found. :) | 16:15.19 |
| fredross-perry | yes | 16:15.29 |
| sebras | Robin_Watts: if you look at the very top of sebras/master, is this the kind of approach you are looking for? | 19:41.31 |
| | Robin_Watts: re: stext and flags. | 19:41.39 |
| Robin_Watts | urm... I don't see it. | 19:42.24 |
| | Forward 1 day (to 2016/08/03)>>> | |
IRC Logs