| | <<<Back 1 day (to 2018/09/17) | 20180918 |
| fredross-perry | tor8, sebras - I'd love some feedback on this: http://git.ghostscript.com/?p=user/fred/mupdf.git;a=commit;h=dc4d01aabe7d15954b685e20208253e075924f54 | 00:20.55 |
| sebras | fredross-perry: tapAt() is not enough to provide the javascript implementation with enough info to detect hovering which adove js api seems to allow for. | 05:48.08 |
| | fredross-perry: and I believe you use setValue() to set a form field..? I think the characters in the string must be indvidual keyDown events so that the js implementation is allowed to reject them. | 05:48.56 |
| | it seems to me that some of this is not available in the C implementation yet. | 05:49.21 |
| | I haven't discussed any of this with tor8 so I don't know what his plan for this is. | 05:51.16 |
| | e.g. is there any part of the js api that we will not implement? | 05:52.14 |
| | as I read adobe's js api they assume a single button pointer with x/y and modifiers (ctrl/option/shift) and a keyboard that sends keystroke events with modifiers (ctrl/option/shift). however I'm not really aquainted with the js api spec. | 05:57.51 |
| | as for the findUsableFormFields() filtering the complete list of widgets, perhaps we could send in a mask of PDF_ANNOT_IS_ and have it return whatever is desired? that way they decision like isWidgetVisible() wouldn't be hardcoded in JNI. | 05:59.48 |
| | why is defocusWidget() needed? isn't PDFDocument supposed to keep track of that itself? | 06:01.45 |
| | oh and the FindClass() stuff seems to normally be done in find_fids()/lose_fids( | 06:05.33 |
| | I don't know enough about this, but is there a chance that the number of options changes in Widget_getOptions() between the two calls to pdf_choice_widget_options()? | 06:07.22 |
| | seems to me like this would be better implemented by pdf_choice_widget_options() doing the allocation and the caller freeing afterwards. | 06:08.08 |
| | the widget kinds should probably have constants in the Widget class. | 06:12.27 |
| | if we want to expose the PDF_ANNOT_IS_* states through JNI there should probably be constnats for that in PDFAnnotation. | 06:13.13 |
| | and both have corresponding checks in check_enums() (I recently learned myself during code review) | 06:13.33 |
| | but it seems to me like the C interface needs to be amended. | 06:14.47 |
| jrun | mupdf: source/fitz/colorspace.c:1486: fast_rgb_to_cmyk: Assertion `"This should never happen" == NULL' failed. | 15:41.47 |
| | here is the file: https://i.mt.lv/cdn/routerboard/hEX__S-180529163507.pdf | 15:42.10 |
| tor8 | jrun: have you tried the latest git? | 15:55.20 |
| | jrun: I can't reproduce with 1.13.0 either. you'll need to give us a command line to run. | 15:56.46 |
| jrun | it happened with 1.13.0 and 1.13.0-r1 (r1 is probably from gentoo) | 16:16.51 |
| | tor8: i passed no flags on cli. | 16:17.06 |
| | mupdf /tmp/hEX__S-180529163507.pdf | 16:17.20 |
| | oh, lcms is not builtin, does that explain? | 16:17.38 |
| | trying with lcms | 16:18.26 |
| tor8 | jrun: yes. you need our fork of lcms. stock lcms causes this error. | 16:44.58 |
| | Forward 1 day (to 2018/09/19)>>> | |
Log of #mupdf at irc.freenode.net.