| | <<<Back 1 day (to 2016/09/07) | 20160908 |
| Ray_tab | Mvrhel, I'll call you back when the first part of the meeting end so | 00:23.05 |
| sebras | tor8 (for the logs): I think MarkupAnnotation.set/getQuadPoints() should be using the Point class. quite possible other things too like InkList etc, but I'm not sure if the floats there represent points yet. :) | 02:41.02 |
| Robin_Watts | http://www.bbc.co.uk/news/business-37303066 | 09:05.31 |
| kens | Yeah it was on the radio this moprning and also the reg | 09:05.53 |
| sebras | tor8: do I need the final LGTM or has that passed already? | 10:10.08 |
| tor8 | sebras: LGTM | 10:16.01 |
| sebras | tor8: then I'll push the lot on sebras/master. | 10:16.14 |
| tor8 | sebras: creating an array of points is going to be terrible performance wise. each point needs its own object. | 10:20.40 |
| | if you want to be strictly java style, then QuadPoints should be an array of QuadPoint objects, where each QuadPoint has 4 Points | 10:21.58 |
| | class QuadPoint { Point LL, LR, UR, UL; } | 10:22.59 |
| sebras | tor8: I was just comparing with what we had for the old viewer. | 10:23.32 |
| | tor8: we did use Point objects there. | 10:23.39 |
| | but yeah, performance wise it probably sucks. | 10:23.59 |
| tor8 | java is a horrible memory pointer chasing nightmare... | 10:24.24 |
| sebras | tor8: I ran in to some issues last night though. | 10:36.25 |
| | tor8: I'm implementing PDFAnnotation_00024MarkupAnnotation_setQuadPoints() (yes, thats 00024 for $...) | 10:37.12 |
| tor8 | sebras: ah, right, inner classes :) | 10:37.46 |
| sebras | and the argument according to the java is supposed to be a MarkupAnnotation, but I'm having a hard time implementing a from_*Annotation() that does not return NULL.\ | 10:37.56 |
| | for some reason I fail to get the long pointer pointer. | 10:38.12 |
| tor8 | inner classes messing things up perhaps? | 10:38.41 |
| sebras | tor8: oh, and strangely enough all classes appear to have the same value in the fid_*_pointer-variables, 22. :) | 10:38.53 |
| | tor8: could be because of inner classes. | 10:39.04 |
| tor8 | the inner classes are subclasses of the outer class? | 10:39.28 |
| Robin_Watts | sebras: Does the use of inner classes preclude people adding more annotation types later without using inner classes? | 10:39.45 |
| sebras | tor8: but javac complains if we put all annotation classes in a single file, so the only option I know of is to create a whole slew of different files and separate public files. which may not even resolve the problem. :) | 10:39.47 |
| tor8 | fid_Annotation_pointer would be the only long pointer in use | 10:40.01 |
| | create a dozen files (maybe in a sub-package if you feel it's getting out of hand) | 10:40.17 |
| sebras | tor8: yes, I meant for non-Annotation classes. | 10:40.18 |
| Robin_Watts | My instinct would have been to use 'proper' separate classes, in separate files. | 10:40.39 |
| sebras | Robin_Watts: I don't know. they _are_ public so they ought to be inheritable, no? | 10:40.39 |
| Robin_Watts | proguard can drop the ones that aren't used in any given implementation. | 10:41.00 |
| tor8 | sebras: Robin_Watts: No, no ,no. the annotation classes are bound to the C annotation types. we can ONLY create new annotation objects using the page.createAnnotation factory method | 10:41.31 |
| | so there should be no rhyme or reason to users subclassing and creating their own annotation types in java | 10:42.27 |
| Robin_Watts | tor8: Could we not have someone want to implement an Annotation that comes from a java path? It might map to the same C type underneath. | 10:42.33 |
| | (random example pulled out of the air - haven't thought it through) | 10:42.53 |
| tor8 | then you create an Ink or PolyLine or Polygon annotation using page.createAnnotation and set the vertices from the java path? | 10:43.56 |
| Robin_Watts | tor8: yeah, ok. | 10:44.32 |
| tor8 | in order to get the java classes to match C "classes", we need to use factory methods to create everything | 10:44.40 |
| | and the annotation Subtype field must be immutable once created | 10:44.50 |
| | in order to have subclasses for each annotation type | 10:45.03 |
| | so to get an Ink annotation object, you'd have to InkAnnotation ink = (InkAnnotation) page.createAnnotation(PDFAnnotation.PDF_INK_ANNOT) | 10:45.43 |
| | or if (annot instanceof InkAnnotation) inkannot = (InkAnnotation) annot; | 10:46.07 |
| | at least this is what I understood you and fred asked for | 10:46.41 |
| sebras | tor8: right, this is actually what I do for UnderlineAnnotation (which is what I'm attempting to implement) | 10:46.45 |
| tor8 | I could well be mistaken | 10:46.46 |
| | I think having a dozen files would be less surprising | 10:49.23 |
| | I have a hard time even imagining how an inner class being a subclass of its outer class would actually work | 10:49.41 |
| | com/artifex/mupdf/fitz/annotation/*Annot.java if you want to bundle them up into a separate package | 10:50.44 |
| sebras | tor8: this is java, you should not care about how it works, the garbage collector and exceptions will resolve any problems later. | 10:50.51 |
| | here we go. | 10:59.28 |
| | tor8: I saw that mistake in mucbz. | 16:10.15 |
| | tor8: the one in murun I didn't even notice. I'm surprised I didn't see gcc complain about that. | 16:10.39 |
| | tor8: it would be nice if we could get rid of all the warnings we have so things like those stand out. | 16:11.12 |
| | anyway sorry, and please do merge the Fix typos. patch. | 16:11.22 |
| tor8 | sebras: the clang build is warning free. | 21:45.22 |
| | gcc is massively confused by the try/catch setjmp logic | 21:45.40 |
| | Forward 1 day (to 2016/09/09)>>> | |
IRC Logs