| | <<<Back 1 day (to 2017/10/04) | 20171005 |
| nomanr | hi, does MuPDF support image (.jpeg or any other format) signatures? | 10:31.48 |
| | I can find builds for Android version but I am unable to find source code for Android in Downloads section :/ | 10:32.18 |
| kens | Wehn you say 'signatures' do you mean digitally signing a PDF file, or something else ? | 10:32.45 |
| tor8 | nomanr: the android viewer only supports creating Ink, Highlight, Underline and Strike-out annotations. | 10:32.58 |
| nomanr | Yeah digitally signing a PDF, but now it ask for a digital signature (.sig) file. In my use-case I want to popup a canvas that I can store as a jpeg and paste it on signature field. | 10:34.50 |
| tor8 | nomanr: the source code for the android version was split out into a separate project in version 1.11 | 10:34.53 |
| | if you want that source is part of a release, you need to download version 1.10 | 10:35.07 |
| nomanr | I download version 1.9, it has fillable PDF feature as well, but 1.11 is just viewer. | 10:35.41 |
| tor8 | nomanr: sorry, none of that will work out of the box with mupdf. the digital signature support in mupdf only supports verifying that the file has not been modified after signing. | 10:36.02 |
| | and that is also broken at the moment, since openssl has changed their API and we haven't had time to update that code. | 10:36.23 |
| | so if you want to use that feature you must build with an out of date openssl which may have several known vulnerabilities, so I don't recommend trying it. | 10:37.12 |
| nomanr | right, I don't want digital signing feature and even after signing a PDF (just INK signature), I'll still want to edit it. | 10:39.44 |
| | Okay last thing, which exact version should I download to make changes for Android version. | 10:40.07 |
| | mupdf-1.10-source.tar.gz2016-11-21 14:4740M [ ]mupdf-1.10-windows.zip2016-11-21 16:0175M [ ]mupdf-1.10a-source.tar.gz2016-11-28 13:3740M [ ]mupdf-1.10a-windows.zip | 10:40.26 |
| tor8 | nomanr: before you spend too much time on this, I hope that you are aware of the licensing restrictions. | 10:47.56 |
| | Is your app open source? | 10:48.02 |
| nomanr | Tor, no its not. :grin: | 10:48.16 |
| tor8 | nomanr: then do you have a commercial license? | 10:48.27 |
| | If your project is not open source, you will have a hard time complying with the AGPL3 terms and conditions. | 10:49.07 |
| nomanr | not yet. I haven't implement it in the yet app. I need to see if it works then I'll think about commercial license. | 10:49.29 |
| sebras | tor8: a few small patches on sebras/master | 11:08.33 |
| | tor8: resurrected from old local branches. | 11:08.47 |
| | tor8: clustering as I write. | 11:08.57 |
| | tor8: clustered successfully, do you mind taking a quick look? | 11:19.57 |
| | tor8: oh, and concerning tor/master: | 11:20.24 |
| | "Fix pdf_widget/pdf_annot typedefs...", "Add 'mutool sign' tool...", "Purge out of date..." all look ok to me. | 11:20.52 |
| | tor8: you mentioned yourself that you need to look further into the GLFW one (and it does indeed not update glfw) | 11:21.12 |
| tor8 | yes, I want to chat to upstream GLFW about getting Ctl+A to be actually sent as character events | 11:23.37 |
| | haven't had time to do that yet | 11:23.44 |
| | sebras: I'll look at that if you'll help me look at why annotation creation in mupdf-old doesn't work afterwards. deal? | 11:24.13 |
| | sebras: sebras/master LGTM | 11:25.53 |
| sebras | tor8: sure. | 11:26.05 |
| tor8 | the code on mupdf-old:tor/master should build with new libmupdf | 11:26.30 |
| | lots of stuff disabled | 11:26.35 |
| | but annotation creation makes wrong appearance streams | 11:26.45 |
| | as if the coords are off | 11:26.50 |
| | and selection is wonky. ink annotations can not be reliably selected if other annotations are on the page. | 11:28.17 |
| | if I create two highlight and then an ink, I can't select the ink | 11:29.40 |
| | but if I navigate off the page so the page is uncached, and then go back, I can select all of the annotations | 11:29.41 |
| | IMO we should make this work for the release | 11:29.56 |
| | even if we intend to replace it eventually | 11:30.06 |
| sebras | I'm still building it. | 11:30.49 |
| | so for some reason gradle decides not to include libmupdf_java32.so in my build. | 11:38.56 |
| | libmupdf_java32.so are only included in the x86 and armeabi-v7a debug apks. | 11:40.07 |
| | but gradle decided to install the x86_64 version of the apk. | 11:40.47 |
| tor8 | did you make clean nuke distclean | 11:42.10 |
| | gradle cleanBuildCache etc | 11:42.17 |
| sebras | the cleanBuildCache was new... | 11:42.26 |
| | if I installed the built x86 version it starts. | 11:43.11 |
| | I'm at the top of tor/master, and with that source I see no wonky behaviour. | 11:46.21 |
| | I can create text annotations without issues, the visuals matching the selected text. | 11:46.37 |
| tor8 | create an ink annotation and try to select it | 11:46.38 |
| sebras | for ink annotations I can create them and if I click on the red ink itself it will be selected. | 11:46.57 |
| | or rather, the toolbar changes and I can remove it. | 11:47.06 |
| | though, when I create an annotation in the corner of a page I can't select it. | 11:47.42 |
| | we choose to flip the page instead... | 11:47.55 |
| tor8 | I can't select Ink annotations that I create | 11:48.24 |
| | unless I first change page a few times | 11:48.32 |
| sebras | hm.. I think I know. | 11:48.49 |
| | I created an ink annotation, and immediately after I cannot select it. | 11:49.03 |
| | but if I then create a text annotation that I remove | 11:49.15 |
| | _Then_ I can select the ink annotation. | 11:49.21 |
| | I actually don't have to remove the text annotation, I just need to create another annotation. | 11:49.53 |
| | so my steps are: 1) create ink annotation 2) create text annotation 3) select ink annotation 4) remove ink annotation | 11:50.49 |
| tor8 | yes. | 11:50.51 |
| | but text annotations I can select directly | 11:51.00 |
| | after creating them | 11:51.04 |
| | so something is fishy with the annotation tracking | 11:51.13 |
| sebras | in my emulator the blueish selection box is only partially visible | 11:58.00 |
| | I can only see one side of the box, the other three are invisible. | 11:58.16 |
| tor8 | which selection box? | 11:58.39 |
| sebras | there's a blue selection box encompassing the selected annotation. | 12:03.10 |
| | if you do a text annotation, you might see it more clearly. | 12:03.26 |
| tor8 | you mean the blue rectangle denoting a selected annotation | 12:03.52 |
| | might be your emulator doing screen scaling? | 12:04.00 |
| sebras | that would certainly explain it. | 12:04.28 |
| | but I don't know if it is. | 12:04.31 |
| tor8 | what's the screen resolution of your emulated phone, and does it fit? | 12:04.45 |
| | there's a setting somewhere in the AVD manager whether to scale the pixels | 12:05.18 |
| sebras | oh, this is a gigantic screen apparently. so yeah, it's got to be the scaling. | 12:05.56 |
| | 1440 x 2560, bigger than the 1080 pixels I have on my laptop. | 12:06.25 |
| tor8 | yeah, certainly sounds like it | 12:13.51 |
| sebras | works now. | 12:14.29 |
| | created a smaller avd. | 12:14.37 |
| tor8 | okay. so you're saying the created annotations match the selected text for you? | 12:51.11 |
| | they don't for me... | 12:51.14 |
| sebras | I have found something. | 12:51.27 |
| tor8 | the selection bbox matches | 12:51.29 |
| | but the appearance is awy off | 12:51.32 |
| sebras | when the first ink annot is created its coordinates in my case are 0,1190,0,1190 | 12:51.58 |
| | but when create the second ink annotation the first one's coordinates change. | 12:52.07 |
| | I don't know why yet. | 12:52.13 |
| | for me the text annotations highlights reside within the bounding box. | 12:52.34 |
| | though the words' highlights overlap. | 12:52.48 |
| | it seems to me that when I create the 2nd ink annot it reloads the 1st ink annot from the pdf and then the coords are refreshed. | 12:53.22 |
| | but I haven't proven that yet. | 12:53.26 |
| tor8 | okay, the different markup annotations are creating the same QuadPoints struct at least | 13:06.15 |
| | but then they appear completely different when rendered | 13:06.25 |
| sebras | where is the QuadPoints struct? inside libmupdf? | 13:07.39 |
| | or in the JNI-bindings? or in the java code? | 13:07.46 |
| tor8 | pdf_set_annot_quad_points gets called with the same array coords | 13:07.54 |
| | that's as far as I've debugged yet | 13:08.00 |
| | when the same text is selected | 13:08.11 |
| | as expected | 13:08.12 |
| sebras | I can only find a quadpoints struct for the text annots, for the ink annots I see a list of paths. | 13:08.13 |
| tor8 | but after that ... I have no idea | 13:08.17 |
| | yes, I'm still stuck on text annots not drawing correctly | 13:08.31 |
| | I haven't even started looking into the weird selection behavior with ink annots seeing as you're investigating that :) | 13:08.51 |
| sebras | I instrumented src/com/artifex/mupdfdemo/Annotation.java in the constructor and started printing the coordinates when it is created, and also in the contains() member when hits are checked. | 13:09.15 |
| tor8 | I wuoldn't be surprised if the annotation appearance synthesis code doesn't work properly at all | 13:09.24 |
| sebras | I'm seeing that the annotation is at first created with bogus coordinates, but when the 2nd one is added it gets recreated correctly. | 13:09.40 |
| | at least the coordinates seem sane in that case. | 13:09.56 |
| | ok, so I think I might be a step closer now. | 13:27.38 |
| | when getting the annotations from the page /Rect will be queried for each annotation | 13:28.07 |
| | when creating text annotations it first calls pdf_set_annot_quad_points() to set the points | 13:28.44 |
| | then calls pdf_set_markup_appearance() | 13:28.50 |
| | the latter call will update /Rect in the underlying PDF object | 13:29.04 |
| | for ink annotations a call pdf_set_annot_ink_list() is made (corresopnding to pdf_set_annot_quad_points()), but after that there are no other calls to set /Rect | 13:29.36 |
| | instead there is a comment in pdf_set_annot_ink_list() stating: TODO: update Rect (in update appearance perhaps?) | 13:29.53 |
| | now... why does /Rect eventually get updated? I don't know yet. | 13:30.06 |
| | but I'm sensing that we're querying /Rect before the data is updated. | 13:30.21 |
| tor8 | is the /Rect updated, or is there a cached bbox in the java Annotation object that isn't updated? | 13:34.15 |
| | right. could be a "race" condition then, where we query the /Rect to update the annot.bbox before the appearance synthesis has created a new Rect | 13:34.53 |
| sebras | it looks like the java getAnnotations() calls the JNI which interacts directly with the PDF objects | 13:35.06 |
| | pdf_update_ink_appearance() does the updating of /Rect for ink annotations, but I don't know when it is called. | 13:35.56 |
| tor8 | yup. I can get the same bad annotation creation with mutool run. | 13:40.47 |
| sebras | sweet. how? | 13:41.06 |
| | I'd like to escape Android while debugging this if I can. | 13:41.23 |
| tor8 | https://pastebin.com/raw/p0J8CNmV | 13:42.02 |
| sebras | tor8: ah, but that's not the bug I'm chasing. | 13:53.12 |
| | tor8: but, yeah, those highlights ought to overlap... :) | 13:53.22 |
| | tor8: I have fixed my problem now, it is indeed releated /Rect and I'm not able to immediately select an ink annotation! | 13:53.48 |
| tor8 | yeah, this is the 'up' vector being diagonal again | 13:57.38 |
| | wrong quadpoints order | 13:57.56 |
| sebras | ah. | 13:58.40 |
| | oh, and now i know something more. | 13:59.36 |
| | for text markup annotations libmupdf decides color, alpha, line thickness and line height for highlights, underline and strike out annotations. | 14:00.13 |
| | for ink annotations libmupdf makes no such decidsion | 14:00.22 |
| | instead this is decided in jni/mupdf.c | 14:00.28 |
| | why do we do it like this? | 14:00.39 |
| tor8 | the spec says the quadpoint order is [BottomLeft BottomRight TopRight TopLeft] | 14:00.42 |
| | we used to follow the spec but ran afoul of the fact that Acrobat doesn't actually follow the spec | 14:00.57 |
| | all software actually treats quadpoints as being in the order [TopLeft TopRight BottomLeft BottomRight] | 14:01.18 |
| sebras | oh... so we might have messed up the markup annotations when we fixed the other order? | 14:01.24 |
| tor8 | we've updated our appearance synthesis | 14:01.25 |
| | but not the android code that calls it | 14:01.30 |
| sebras | ah, how silly of us. | 14:01.39 |
| tor8 | yes. now the only question remains, is it [TL TR BL BR] or [BL BR TL TR] | 14:03.01 |
| | kens: do you know off hand which one it is? | 14:03.07 |
| kens | SOrry wasn't paying attention, which what ? | 14:03.21 |
| | Oh Quadpoints ? | 14:03.29 |
| tor8 | yes, quadpoints, sorry | 14:03.37 |
| kens | I seem to recall that the order Acrobat uses is not the one defined in the spec | 14:03.51 |
| | Which is a little sad | 14:03.55 |
| tor8 | I think it's [BL BR TL TR] | 14:04.00 |
| sebras | tor8: I trust you've read your own commit message from 2bd66c263ec4514b31966495924ed386413d8327 ? | 14:04.04 |
| tor8 | yeah, we tackled this a month or so ago... | 14:04.07 |
| kens | Sounds plausible, I'd have to go read the PDF interpreer to be sure | 14:04.17 |
| tor8 | sebras: thanks! | 14:04.24 |
| | that's exactly what I was looking for :) | 14:04.29 |
| sebras | tor8: a month? in July!!1 :) | 14:04.32 |
| kens | Maybe a grep in the #mupdf logs would help ? | 14:04.33 |
| sebras | kens: I think tor8's own commit message answered his question. | 14:04.55 |
| kens | LOL | 14:05.07 |
| sebras | kens: he just wanted someone else to find it for him. :) | 14:05.11 |
| sebras | is the janitor. | 14:05.19 |
| kens | I'll remember to ask sebras next time I need something finding | 14:05.40 |
| tor8 | yay! it works! :) | 14:06.56 |
| sebras | tor8: excellent! | 14:07.02 |
| tor8 | sebras: okay, so the /Rect update thing for the ink annots? | 14:07.37 |
| sebras | tor8: yes, I'm working on it. | 14:08.38 |
| | tor8: I have a question: does /C affect markup annots | 14:08.50 |
| | ? | 14:08.51 |
| tor8 | so, saveDraw does addInkAnnotation followed by a loadAnnotations() | 14:08.54 |
| sebras | tor8: no, that's not it. | 14:09.18 |
| | basically we need to call pdf_update_ink_annotation() after pdf_set_annot_ink_list() in MuPDFCore_addInkAnnotationInternal() | 14:09.49 |
| tor8 | and that means all annotations are reloaded when you add an ink annotation, IIRC | 14:09.49 |
| sebras | that's not what is needed. | 14:10.14 |
| tor8 | I'm starting from the top to see what is being called | 14:10.28 |
| | and that calls getAnnotationsInternal in jni/mupdf.c | 14:10.44 |
| | which loops through the loaded annotations in the pdf_page and wraps them up in new java objects | 14:11.13 |
| | so they're not actually reloaded from file if the page is found in the page cache | 14:11.40 |
| | and that calls pdf_bound_annot to get the bbox | 14:12.17 |
| | which it then stuffs into a java Annot object | 14:12.33 |
| | so if that call doesn't get the correct rect then we're hosed | 14:12.44 |
| | neither of MuPDFCore_addInkAnnotationInternal and MuPDFCore_addMarkupAnnotationInternal call pdf_update_annot() | 14:13.43 |
| | however the latter calls pdf_set_markup_appearance, which updates the appearance stream directly | 14:14.51 |
| | pdf_set_annot_ink_list does not do it directly | 14:15.14 |
| | so I think adding a call to update the appearance after pdf_set_annot_ink_list should do the trick | 14:15.55 |
| | ro just pdf_update_ink_appearance, which seems to be done for the task | 14:16.04 |
| | pdf_set_annot_ink_list(ctx, annot, n, counts, pts); | 14:16.56 |
| | + pdf_update_ink_appearance(ctx, idoc, annot); | 14:16.56 |
| | sebras (for the logs): more commits on mupdf-old:tor/master | 14:18.34 |
| sebras | tor8: I know that calling pdf_update_ink_appearance() is the solution. I wrote that 6 minutes before you did. | 14:33.30 |
| tor8 | sebras: welcome back :) | 14:33.35 |
| | aha! | 14:33.36 |
| sebras | after that I git reset --hard and logged out. | 14:33.44 |
| | have you figured out why text appearance is updated too? | 14:34.11 |
| | and why the JNI can control the colors of ink annots but not of text markup annots? | 14:34.41 |
| tor8 | pdf_update_ink_appearance is called when update_changed_rects is calling pdf_update_page | 14:35.32 |
| sebras | there is a set_markup_appearance() for which there is no corresponding function for ink annots. | 14:35.34 |
| | why is that? | 14:35.38 |
| | and what is the purpose of the set_markup_appearnce() function? | 14:35.57 |
| tor8 | that's paul's code. he hardwired the colors for set_markup_appearance | 14:36.02 |
| | that function should IMO not even exist | 14:36.08 |
| sebras | that what was I was looking into, i.e. shouldn't /C control the color of highlight annotations too..? | 14:36.33 |
| tor8 | it should. rewriting this code to not use the pdfwrite device and doing general cleanup has been on my todo list a while now. | 14:36.59 |
| sebras | not sure if line thickness, line height and alpha can or should be controlled from the PDF though. | 14:37.39 |
| | those things are probably better off hardcoded, but perhaps in the JNI or Java, and not in libmupdf. | 14:37.58 |
| tor8 | those variables are all hacks to reuse the same function to do highlights, strikeouts and underlines with the same code | 14:38.15 |
| | not sure, but I suspect the border width should be used for strikeout and underline | 14:38.39 |
| sebras | I'm thinking that the JNI code ought to call pdf_annot_color() for text markup annotations too. | 14:39.45 |
| tor8 | yup. it should. | 14:39.52 |
| sebras | pdf_set_annot_color(). | 14:39.57 |
| tor8 | but that will have to wait until post release | 14:40.53 |
| sebras | when is the release due? | 14:41.13 |
| tor8 | I believe mupdf-old as on tor/master is polished up enough for the release | 14:41.18 |
| | a couple of weeks; when the SDK is done and documented and I've reviewed and merged the rest of the spots branch | 14:41.40 |
| | and given it some time for the dust to settle | 14:41.48 |
| | release is delayed until october in order for the android sdk things to be in it | 14:42.15 |
| | otherwise we should've released along with gs | 14:42.28 |
| sebras | right. | 14:42.45 |
| tor8 | sebras: ugh, this 'updating' code in the old android viewer is hairy | 14:43.49 |
| | I think it's time to hack in annotation editing in mupdf-mini instead :) | 14:44.07 |
| sebras | tor8: that's probably a better idea. | 14:44.40 |
| tor8 | and add a HQ patch rendering to it | 14:46.45 |
| | or maybe do an infinite scroll version too | 14:47.35 |
| | based on a ListView | 14:47.43 |
| | anyway, time for me to eat | 14:47.48 |
| | talk to you tomorrow | 14:47.51 |
| sebras | it' is able to do the same for ink annotations | 14:49.48 |
| | in annots /C does control color of text markup annotations in acroread if asked to synthesize when an appearance stream is missing. | 14:50.12 |
| | evince only managed to synthesize ink annots though, and mupdf failed to synthesize both with the error message "no appearance stream for annotation" | 14:51.10 |
| | Forward 1 day (to 2017/10/06)>>> | |
Log of #mupdf at irc.freenode.net.