| | <<<Back 1 day (to 2017/07/23) | 20170724 |
| sebras | tor8: do you mind helping me with some annotation matrices gone wrong? | 13:44.34 |
| kens | runs away in horror | 13:44.47 |
| tor8 | sebras: oh dear... | 13:45.08 |
| | sebras: which file? | 13:45.28 |
| sebras | tor8: out2.pdf on my casper | 13:45.38 |
| | tor8: page 1 | 13:45.41 |
| tor8 | at, still on that one | 13:46.11 |
| sebras | tor8: yes, this file highlights different amounts of the line depending on the viewer. | 13:47.03 |
| | tor8: and that just seems off to me. | 13:47.12 |
| tor8 | yes. the appearance synthesis. | 13:47.17 |
| sebras | tor8: I think we only highlight about half as much horizontally that we should. | 13:47.44 |
| | tor8: as far as I can tell that means we parse out the QuadPoints, but do not handle them correctly. | 13:50.21 |
| tor8 | sebras: yes, like I mentioned last week I think the appearance synthesis code is doing the wrong thing with the quadpoints | 13:50.50 |
| | up -505 -56 | 13:50.56 |
| | annot line -207.5 600 -> 297.5 600 | 13:50.56 |
| | page ctm [1 0 0 -1 0 792] | 13:50.56 |
| | the 'up' vector is WAY off | 13:51.01 |
| | paul's code assumes qp1 and qp2 are the lower left and lower right corners, as per the illustration | 13:51.29 |
| | and as you mentioned in implementation note 92(?) that's not true | 13:51.41 |
| sebras | tor8: yes, and even when I manipulated the qp vector to reorder the points the illustation was the same. | 13:52.11 |
| | tor8: because of the x-coordinates of the left most and right most points. | 13:52.27 |
| tor8 | and qp2 and qp3 should define the 'up' vector (being the right edge of the quad) | 13:52.44 |
| | the QP in your example file goes ll, lr, ul, ur | 13:53.01 |
| | but really they should be wound clockwise | 13:53.07 |
| | for our code to work | 13:53.12 |
| sebras | wait... clockwise? anticlockwise, right? | 13:53.24 |
| tor8 | whichever :) | 13:53.44 |
| | if I edit the QuadPoints to QuadPoints [ 45 628 550 628 550 572 45 572 ] it looks good in mupdf | 13:54.06 |
| | yes, it should be CCW | 13:55.15 |
| | of course now gs gets it all wrong instead... | 13:56.31 |
| | and evince :) | 13:56.47 |
| sebras | tor8: though I guess it really should be QuadPoints [ 45 572 45 628 550 628 550 572 ] | 14:04.48 |
| kens | Hmm I thought GS rearranged QuadPoints | 14:05.17 |
| tor8 | sebras: that one makes a fish in gs :) | 14:05.33 |
| kens | What does Acrobat make of it ? | 14:05.57 |
| tor8 | gs and evince do different things here | 14:05.58 |
| sebras | kens: it does, but I wasn't able to determine how. | 14:06.02 |
| tor8 | kens: don't have Acrobat readily available on my linux machine | 14:06.07 |
| kens | sebras, PostScript so its black magic | 14:06.14 |
| | tor8 where's the file, I'll try it | 14:06.25 |
| sebras | kens: I tried to understand it last week! | 14:06.26 |
| tor8 | kens: ghostscript.com:/home/sebras/out2.pdf | 14:06.42 |
| kens | I'm sure I've fiddled with ti before | 14:06.43 |
| | one minute then | 14:06.53 |
| tor8 | brb | 14:06.59 |
| sebras | kens: I think it attempts to reorder each pair of points first and then reorder the pairs. | 14:07.01 |
| kens | Umm is that casper ? | 14:07.13 |
| | OK I see it | 14:07.34 |
| | Hmm Acrobat shows a green highlight, line with round end caps | 14:08.26 |
| | So does GS | 14:08.48 |
| | Am I missing something ? | 14:09.12 |
| sebras | kens: if you edit the file to replace QuadPoints with [ 45 572 45 628 550 628 550 572 ]..? | 14:10.21 |
| kens | Oh I have to edit it ? OK thne wait a minute | 14:10.34 |
| sebras | kens: I believe this to be the correct ordering of the coordinates in a ccw fashion. | 14:10.38 |
| | kens: yeah, tor8 forgot to mention that. :) | 14:10.58 |
| kens | THat's a fish shape in Acrobat too | 14:11.48 |
| | Same as GS | 14:11.59 |
| sebras | kens: but the ordering of the coordinates in QuadPoints can basically be arbitrary as long as they are CCW, right? | 14:13.27 |
| kens | Not sure, I'd have to read the spec | 14:13.45 |
| sebras | kens: and so the order I gave shouldn't really result in a fish, but in a rect...? | 14:13.53 |
| kens | But if GS matches Acrobat then its 'correct' | 14:13.59 |
| sebras | kens: maybe I read implementaiton note 92 on page 1115 in pdfref17.pdf wrong. | 14:14.14 |
| kens | give me a second I just opened the reference | 14:14.26 |
| | AFAICS note 92 isn't relevant | 14:15.14 |
| | That's referencing the text orientation, not the highlight | 14:15.23 |
| | So the starting vertex is important if you have a text markup which involves text. FOr a highlight its unimportant, provided the vertices are CCW | 14:17.28 |
| sebras | hm... | 14:17.41 |
| | kens: well, do the coordinates look more CCW to you after editing it? | 14:18.14 |
| | kens: they do to me. | 14:18.20 |
| | kens: hence I'm puzzled by the fish. | 14:18.31 |
| kens | Your quadpoints are a rectangle described clockwise | 14:18.32 |
| sebras | kens: right, so it should be /QuadPoints[045 572 550 572 550 628 045 628] ? | 14:20.29 |
| kens | I think your QP ends up reassigning the 4th point as the initial vertex and going CCW from there | 14:20.31 |
| | yes that sounds correct | 14:20.49 |
| sebras | that looks ok in mupdf actually! | 14:21.08 |
| | kens: but wrong in gs..?! :-/ | 14:21.15 |
| kens | Wrong in Acrobat also | 14:22.01 |
| | hard to describe, like two bowls | 14:22.20 |
| | GS is the same though | 14:22.35 |
| tor8 | yeah, gs looks like it's taking the endcaps on the horizontal sections | 14:22.56 |
| sebras | tor8: exactly, the curves end up at the wrong edge. | 14:23.19 |
| kens | Give me a minute and I'll see what GS is actually up to with the points | 14:23.36 |
| | According to the comment, you should start with the vertex with the smallest y value, or if there are two with the same smallest y value, the one with the lowest x value | 14:24.53 |
| | Which is indeed note 92 | 14:25.04 |
| tor8 | the only way gs looks good is with the points in a cross-wise fashion | 14:26.46 |
| | ul, ur, ll, lr | 14:27.03 |
| | if I put them in ll, lr, ul, ur fashion it looks the same but with the caps bulging inward | 14:27.25 |
| | and in non-crosswise orders we get fishes or bowls or domes | 14:27.45 |
| kens | OK GS does not rearrange teh quadpoints for a highlight | 14:28.52 |
| | We just use them as is directly | 14:28.59 |
| tor8 | lr, ll, ur, ul also works out looking good | 14:29.05 |
| | which is what I would expect if it does no rearrangement (it's just mirrored) | 14:29.32 |
| kens | GS does a moveto for the first point, then an 'arc' to the second point, a lineto the thrid point an arc to the fourth point then a closepath | 14:29.58 |
| | Since this matches Acrobat, I'd have to say this is what Acrobat is doing | 14:30.20 |
| tor8 | kens: could some other part of code be rearranging the order before the synthesis? | 14:30.51 |
| | with /QuadPoints [ 550 572 | 14:31.08 |
| | 45 572 | 14:31.08 |
| | 550 628 | 14:31.08 |
| | 45 628 | 14:31.08 |
| | ] | 14:31.08 |
| | it looks good in gs | 14:31.13 |
| kens | I don't believe so, we grab the points directly from the dictionary, I can print them out though if you give me a second | 14:31.15 |
| tor8 | but those are *not* in any way or form in my understanding clockwise or counterclockwise ordered | 14:31.30 |
| kens | I had added print code, but to the wrong place thinking it was rearranged. | 14:31.32 |
| tor8 | and if I change the mupdf synthesis code to just do moveto, lineto, lineto, lineto, closepath, fill we get cross shaped thing | 14:32.27 |
| kens | our 'arc' isn't a simple arc | 14:32.56 |
| | Its a procedure in its own right | 14:33.05 |
| | OTOH I'm having some trouble getting any debugf out at the moment.... | 14:33.26 |
| | OK the QuadPoints array I get is the same as the one in the PDF file. | 14:42.08 |
| tor8 | sebras: kens: looking at how poppler draws it (numbering the quadpoints 1, 2, 3, and 4), it's: "x3 y3 m ... x1 y1 c x2 y2 m ... x4 y4 c" | 14:42.23 |
| | so curves between poins 3 and 1, and 2 and 4 | 14:42.56 |
| | which strongly suggests NO-ONE is following the goddamn spec and putting the coords in clockwise order | 14:43.22 |
| | or counterclockwise | 14:43.27 |
| | or any winding at all | 14:43.31 |
| kens | I htink its clear that Acrobat isn't, and GS is matching Acrobat in my tests | 14:43.56 |
| tor8 | kens: yeah, so we should match behavior and put a BIG FAT NOTICE that the spec is wrong | 14:44.11 |
| | the quadpoints are NOT ordered circularly | 14:44.21 |
| kens | :-) | 14:44.25 |
| tor8 | do we have an in to the ISO group in charge of the spec? might be worth mentioning that the pdf 2.0 draft is WRONG | 14:44.50 |
| kens | OK so we definitely start by picking the *2nd* co-orindate pair for the first opint and do a moveto that | 14:45.20 |
| | Starting with a QP = 45, 572 550,572 550,628 45,628 | 14:46.34 |
| | We do 550 572 moveto | 14:46.44 |
| | Umm, that can't be right, just a moment | 14:46.55 |
| | Oh I see | 14:47.08 |
| | so 550, 572 moveto, then an arcto 45,628, then a lineto 550,628 an arcto 572,45 and a closepath (back to 550,572) | 14:49.37 |
| sebras | tor8: well, it wouldn't be too difficult to determine the coordinate mentioned in implementation note 92 and then reorder the coordinates depending on dot and crossproducts. | 14:49.42 |
| kens | I must admit that doesn't look entirely correct, but I think tor8 is correct anyway | 14:50.04 |
| tor8 | sebras: yes, but matching acrobat's behavior is better... | 14:50.34 |
| kens | Unfortunately, if you don't, people will complain | 14:50.46 |
| tor8 | sebras: using cross products to find the vector's that are at right angles would be too easy :) | 14:50.51 |
| | agh, how did that grocer's apostrophe end up in there?L | 14:51.13 |
| | I blame my keyboard! | 14:51.17 |
| | sebras: at the tip of tor/master is a fix for highlight annotation synthesis | 14:51.41 |
| | it's a matter of computing the 'up' vector from another coordinate pair (not the diagonal one) | 14:51.59 |
| sebras | tor8: maybe mention in the commit message that we do this to match Acrobat? | 14:53.02 |
| tor8 | sebras: for maximum robustness, we could be looking at the cross product for the two candidates (vector 1-3 or vector 1-4) | 14:53.04 |
| | and pick the one at a right angle to vector 1-2 | 14:53.11 |
| | but not even acrobat does that, so I think it's a waste of effort to do it | 14:53.31 |
| sebras | tor8: yes, because we would need the cross product to be positive to ensure the winding. | 14:54.27 |
| tor8 | sebras: my commit has a comment (in case it turns out we were wrong all along) | 14:55.05 |
| kens | Or Adobe changes.... | 14:55.20 |
| sebras | tor8: yes, I know, but the comment doesn't specifically state why we diverge from the spec. | 14:55.54 |
| | tor8: if we didn't have acrobat to refer to then we'd adhere to the spec I imagine... | 14:56.11 |
| | tor8: there are more puzzling things in the implementation though. | 14:57.34 |
| tor8 | sebras: updated commit | 14:57.40 |
| sebras | tor8: that commit I like. | 14:58.29 |
| | tor8: I wonder why we accept a quadpoints array which consists of 16 coordinates though. | 14:58.49 |
| | tor8: does acrobat even support that? | 14:59.24 |
| tor8 | sebras: multiple quads in a single array | 14:59.33 |
| | one for each chunk of contiguous words | 14:59.39 |
| | for example one quad per line | 14:59.49 |
| sebras | ah, 8 x n in the spec, now I see it. | 14:59.56 |
| tor8 | sebras: going AFK now, unless you need me for something more? | 15:02.44 |
| sebras | tor8: no, thanks for helping out. | 15:03.01 |
| tor8 | np. | 15:04.09 |
| sebras | kens: popup annotations are also fun. | 16:09.43 |
| | kens: according to spec they have no appearance stream, yet they have a normal appearance stream in the /AP dictionary. | 16:10.14 |
| | kens: also the /Open entry does not necessarily correspond to any of the states mentioned in /AP. | 16:10.46 |
| kens | Umm, I seem to remember there were some other provlems with the file, I don't recall what exactly | 16:11.27 |
| sebras | kens: found your commit. | 16:13.05 |
| kens | Presumably a GS one | 16:13.18 |
| sebras | kens: yes. | 16:13.23 |
| kens | No idea if that helps for MuPDF | 16:13.34 |
| sebras | kens: basically iff /Open true draw the popup, otherwise not. | 16:13.37 |
| kens | Ah, I sort of remember that now | 16:13.51 |
| sebras | kens: is the /AP << /N ... >> a fallback for when the viewer does not know how to draw the annotation? I guess so. | 16:15.33 |
| | tor8 (for the logs): ugh... the patches on sebras/master are really ugly. but they get the bug fixed. | 16:49.37 |
| | tor8 (for the logs): it might be that the better approach is to alter annot->ap. but if that is the case then we'd need to run pdf_update_appearance() not only to synthesize appearances but also when state changes. I'm not sure that is how it is intended to work. | 16:50.37 |
| | tor8 (for the logs): also there seems to be a multitude of reasons as to why an annotation should not be drawn, maybe these checks should be done in the annotation code and not in pdf_process_annot() in source/pdf/pdf-interpret.c | 16:53.17 |
| | Forward 1 day (to 2017/07/25)>>> | |
Log of #mupdf at irc.freenode.net.