| <<<Back 1 day (to 2017/07/24) | 20170725 |
mvrhel_laptop | Robin_Watts: for the logs. That fixed it | 04:16.16 |
malc_ | Robin_Watts: https://bugs.ghostscript.com/show_bug.cgi?id=698286 | 06:01.23 |
vtorri | hey | 07:00.38 |
mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 07:00.38 |
vtorri | I use fz_search_stext_page() to search text in a pdf document | 07:01.24 |
| it iterates over the needle and calls match_stext() | 07:01.50 |
| is that function the one which retrieves the number of occurences of the needle ? | 07:02.19 |
kens | sebras (for the logs) the Appearance streams should be used in preference (IMO) to generating one in all cases, but Acrobat doesn't always do that. The /N appeance is for the 'normal' state, there can be others. Its not a fallback... If the viewer doesn't know how to draw an annotation it can ignore it entirely or draw anything it feels like to indicate that it doesn't understand the annotation | 07:06.14 |
tor8 | vtorri: match_stext returns the number of characters matching the needle, not the number of occurences | 10:34.14 |
| fz_search_stext_page then computes a number of rectangles to cover the characters match, and returns the number of such rectangles | 10:34.59 |
| it does not return the number of matches, it returns the number of rectangles needed to highlight the matches | 10:35.22 |
vtorri | tor8: thank you | 10:40.11 |
| tor8: and is there a way to (easily ?) retrieve the previuos and next word before and after the match ? | 10:40.47 |
| tor8: i want to do something like what evince does when searching some text | 10:41.05 |
tor8 | vtorri: what does evince do? | 10:41.31 |
vtorri | it is listing all the occurences and displays for each something like | 10:42.38 |
| word_previous occurence word after | 10:42.55 |
tor8 | not really. you could do your own string matching on the fz_stext_page structure and implement that yourself. the stext structure is not based on 'words' though, it's based on paragraphs, lines, and spans of characters using the same font | 10:44.24 |
| our current search helper functions don't allow for what you ask | 10:45.02 |
vtorri | tor8: and do you plan to add options like : case sensitive searching or word only ? | 10:45.24 |
| case sensitive is something easy to implement | 10:45.53 |
tor8 | case sensitivity would be trivial to add | 10:46.03 |
vtorri | word only is just searching after a 'space' | 10:46.35 |
tor8 | we could also run into the possible nightmare case of unicode normalization, which we currently ignore completely | 10:46.36 |
| words are not so easily distinguished in non-latin scripts | 10:47.01 |
| chinese and thai for instance, don't use spaces to separate words | 10:47.53 |
vtorri | ha | 10:49.56 |
| ok | 10:49.58 |
| thank you | 10:50.20 |
sebras | tor8: I apologise before because of what I left on sebras/master. that is a set of ugly patches. | 11:19.06 |
| tor8: they do get the job done though. | 11:19.13 |
tor8 | sebras: you could make pdf_annot_is_open return true for annotation types that don't have an /Open field | 11:20.21 |
| s/check_allowed_subtypes/annotation_has_property/? | 11:21.56 |
| though I do prefer the last commit with an explicit has_open && is_open to the try/catch variant | 11:23.38 |
sebras | tor8: I think we reasoned us into having the check_allowed_subtypes() because we expose this API to java. | 11:24.10 |
| tor8: but having an exception thrown for every "incorrect" annotation type is just not a good idea. | 11:25.00 |
| tor8: I guess your response means I should add corresponding has_*()/is_*() for all properties. | 11:25.23 |
tor8 | sebras: do you want to keep the exceptions for java only? | 11:25.33 |
sebras | tor8: yes I think they make more sense there..? | 11:25.59 |
tor8 | expose pdf_annot_has_property(ctx, annot, PDF_NAME_Open) | 11:26.02 |
sebras | tor8: I guess we should also have it for js though. | 11:26.35 |
tor8 | I think the check_allow_subtypes calls in pdf_set_annot_quad_points etc make senes | 11:26.49 |
sebras | tor8: because they are setters? | 11:27.03 |
tor8 | and the getters | 11:27.15 |
| because it makes no sense to set/get quad points on non-quadpoint-owning annotations | 11:27.29 |
sebras | tor8: isn't that true for Open as well? only Popup and TextNote (or whatever it is called) may be open/closed. | 11:28.04 |
tor8 | but as you did, adding a 'annot has this property' function that doesn't throw exceptions makes sense for defensive programming like your "is open" commit | 11:28.13 |
sebras | tor8: annoylingly this is not controlled through the normal AP << /Open << >> /Closed << >> >> dictionary as you might expect. | 11:28.37 |
tor8 | I don't follow your last sentence | 11:29.49 |
| what is not controlled where and how? | 11:30.03 |
sebras | tor8: annotations have /AP << >> in which there might be an /N entry giving the appearance of the annotation in normal state. | 11:30.31 |
tor8 | the property/subtype checks are for the high level annotation editing api | 11:30.37 |
sebras | tor8: but /AS might specify other names for other states. | 11:30.45 |
| tor8: I wish how to draw the Open/Closed state were keys in /AP << >> just like /N and /D and... | 11:31.28 |
tor8 | yes, that's part of rendering the annotations and a completely different story. there we should never throw exceptions (because that's stuff that comes from a source file and errors there are not the user of mupdf's fault | 11:31.46 |
| or are you talking about how we select which appeareance stream to render? | 11:32.20 |
sebras | tor8: I know, what I'm saying is that the open/closed state is independent of its appearance. | 11:32.32 |
tor8 | (I'm still in the 'do we throw exceptions or not' question) | 11:32.37 |
sebras | tor8: I'm in both. :) | 11:32.47 |
| tor8: sorry for the confusion. | 11:32.54 |
tor8 | I haven't looked into that enough to have a good answer for you | 11:33.10 |
| and popup annotations are confusing at best | 11:33.37 |
sebras | tor8: indeed. | 11:33.47 |
tor8 | IIRC (and I could *easily* be mistaken) the Popup annotation is just the button you click to toggle another hidden annotation | 11:34.20 |
sebras | tor8: so if we expose pdf_annot_has_property() of course jni/js could both call it, but it seems better to push that check back down into the library. | 11:34.21 |
tor8 | sebras: I don't see any reason to change the current functions (pdf_(set_)annot_[property] | 11:35.05 |
sebras | tor8: I think they are always connected to a parent annotation. when the parent is clicked the popup opens up an lets you edit the contents. | 11:35.05 |
tor8 | but we *could* add a bunch of "int pdf_annot_has_[property]()" functions to go along with them | 11:35.34 |
| sebras: oh yeah, so the other way around? | 11:35.56 |
sebras | tor8: yes, that's how I read the spec anyway. | 11:36.12 |
tor8 | but the Parent is optional | 11:36.22 |
| and if it exists the Parent's Contents override the popup annotation's contents | 11:36.37 |
| all very confusing without reading some good examples, which I haven't done | 11:36.48 |
| so color me confused :) | 11:36.59 |
sebras | tor8: like me. | 11:38.09 |
tor8 | I was planning on ignoring popup annotations till we got everything else working :) | 11:38.30 |
sebras | tor8: yeah, the bug I'm assigned to didn't know of that plan. ;) | 11:39.52 |
tor8 | sebras: yeah. well, let's ignore editing them in the java code until everything else is working at least! | 11:40.37 |
| sebras: which bug#? | 11:40.53 |
sebras | tor8: 697951 | 11:42.17 |
tor8 | error: object is not a stream | 11:43.26 |
| warning: unrecoverable error; ignoring rest of page oops | 11:43.27 |
| sebras: so it looks like we match gs with everything now (except the bowing line caps on text highlights) | 11:44.44 |
| or did I miss something? | 11:44.51 |
| or should we be matching evince and not drawing the cyan titled square thingy | 11:45.46 |
| sebras: if you squash the 5 top commits on sebras/master I think they're LGTM | 11:46.52 |
| oh, there's an extra blank line introduced above pdf_annot_has_open | 11:47.08 |
Robin_Watts | tor8: When you get free, the commits on robin/spots are ready for your comments, I think. | 11:47.15 |
| no hurry. | 11:47.20 |
sebras | tor8: sure, I can do that and I'll also populate the remaining has_property() functions. | 11:47.36 |
| tor8: I think with that squashed commit this entire bug is fixed. | 11:48.00 |
tor8 | Robin_Watts: so we can only do spots with cmyk pixmaps? | 11:48.16 |
sebras | tor8: the highlight rendering doesn't have end caps, but I don't think that is necessary at all. | 11:48.30 |
tor8 | sebras: sounds good. | 11:48.47 |
Robin_Watts | tor8: yes. | 11:50.15 |
| overprint only works for cmyk+spots. | 11:50.27 |
tor8 | what if we want rgb+spots (with no overprint)? | 11:50.43 |
| or gray+spots | 11:50.49 |
Robin_Watts | so if you ask for rgb+spots, the draw device will render to cmyk+spots internally, and will convert down. | 11:50.52 |
tor8 | okay | 11:50.57 |
| so with +spots we always get cmyk and overprint simulation | 11:51.08 |
Robin_Watts | Yes. | 11:51.27 |
| unless we can think of a nice way to signal that. | 11:51.59 |
| We could have an option to the draw device I guess. | 11:52.24 |
sebras | tor8: so sebras/master is prepared bug I see lots of diff, hopefully these are all due to /Open false now being observed, but I need to check...every...document... :-/ | 16:59.53 |
ubone | o/ will mupdf-gl have invert bg/fg colors? | 17:53.20 |
knielsen | ubone: I actually made a patch for this: https://github.com/knielsen/mupdf/commit/ebf978d5f89bf95fbc6129645c185c925fdd3275 | 19:07.28 |
| was going to ask the mupdf developers shortly if they would be interested in merging this and some other patches | 19:08.10 |
ubone | you saved our eyes | 19:29.43 |
| Forward 1 day (to 2017/07/26)>>> | |