Handle overlapping links and widgets.

Handle overlapping links and widgets.

Only one of FPDPage_HasFormFieldAtPoint() and FPDFLink_GetLinkAtPoint()
should return true for a given point.

Also delete some unused code.

BUG=chromium:434064

[Lei Zhang, 2015-02-28 02:13:57]

thestig@chromium.org changed reviewers:
+ jun_fang@foxitsoftware.com

[Lei Zhang, 2015-02-28 02:13:58]

I'm worried about this case, but maybe my understanding is wrong. Please let me
know what you think.

[jun_fang, 2015-03-05 20:06:02]

On 2015/02/28 02:13:58, Lei Zhang wrote:
> I'm worried about this case, but maybe my understanding is wrong. Please let
me
> know what you think.

Hi Lei,

I think it's not a good idea to change the current design. There is one rule to
design APIs in pdf sdk. It's that APIs shall return raw information so that
applications can handle some complicated cases by themselves. PDF SDK tries not
to do somethings that should be handed in application level. For this case, if
there are both form field and links at one point, we change the current
implementation and only return true in one of FPDPage_HasFormFieldAtPoint() and
FPDFLink_GetLinkAtPoint(). Some applications may have other requirements
conflicting with this change. 

Regards,
Jun

[Lei Zhang, 2015-03-05 21:19:00]

On 2015/03/05 20:06:02, jun_fang wrote:
> On 2015/02/28 02:13:58, Lei Zhang wrote:
> > I'm worried about this case, but maybe my understanding is wrong. Please let
> me
> > know what you think.
> 
> Hi Lei,
> 
> I think it's not a good idea to change the current design. There is one rule
to
> design APIs in pdf sdk. It's that APIs shall return raw information so that
> applications can handle some complicated cases by themselves. PDF SDK tries
not
> to do somethings that should be handed in application level. For this case, if
> there are both form field and links at one point, we change the current
> implementation and only return true in one of FPDPage_HasFormFieldAtPoint()
and
> FPDFLink_GetLinkAtPoint(). Some applications may have other requirements
> conflicting with this change. 
> 
> Regards,
> Jun

With the current APIs, how can an application resolve the overlapping case? It
sounds we'll need another API, so applications can make the decision:

int FPDFPage_AnnotationPosition(FPDF_PAGE page, double x, double y,
FPDF_WIDESTRING type) {
  // if |page| is NULL, return -1
  // for i in annotation-in-reverse order:
  //   if annotations[i] contains (|x|, |y|) and is |type|:
  //     return i
  // return -1
}

[jun_fang, 2015-03-05 21:37:09]

On 2015/03/05 21:19:00, Lei Zhang wrote:
> On 2015/03/05 20:06:02, jun_fang wrote:
> > On 2015/02/28 02:13:58, Lei Zhang wrote:
> > > I'm worried about this case, but maybe my understanding is wrong. Please
let
> > me
> > > know what you think.
> > 
> > Hi Lei,
> > 
> > I think it's not a good idea to change the current design. There is one rule
> to
> > design APIs in pdf sdk. It's that APIs shall return raw information so that
> > applications can handle some complicated cases by themselves. PDF SDK tries
> not
> > to do somethings that should be handed in application level. For this case,
if
> > there are both form field and links at one point, we change the current
> > implementation and only return true in one of FPDPage_HasFormFieldAtPoint()
> and
> > FPDFLink_GetLinkAtPoint(). Some applications may have other requirements
> > conflicting with this change. 
> > 
> > Regards,
> > Jun
> 
> With the current APIs, how can an application resolve the overlapping case? It
> sounds we'll need another API, so applications can make the decision:
> 
> int FPDFPage_AnnotationPosition(FPDF_PAGE page, double x, double y,
> FPDF_WIDESTRING type) {
>   // if |page| is NULL, return -1
>   // for i in annotation-in-reverse order:
>   //   if annotations[i] contains (|x|, |y|) and is |type|:
>   //     return i
>   // return -1
> }

I think applications can set some rules to choose annotations or forms at the
same position to respond to some given events.
For example, the position is far from the center of the annotations (you can get
the outer rectangle of annotations), applications 
can pass the event to form.

[Lei Zhang, 2015-03-06 00:37:31]

On 2015/03/05 21:37:09, jun_fang wrote:
> I think applications can set some rules to choose annotations or forms at the
> same position to respond to some given events.
> For example, the position is far from the center of the annotations (you can
get
> the outer rectangle of annotations), applications 
> can pass the event to form.

What if the two annotations have the exact same size and position? I know it's a
contrived example, but if the app has the z-order information, it would be able
to make better decisions.

[Lei Zhang, 2015-08-07 07:41:38]

On 2015/03/06 00:37:31, Lei Zhang wrote:
> On 2015/03/05 21:37:09, jun_fang wrote:
> > I think applications can set some rules to choose annotations or forms at
the
> > same position to respond to some given events.
> > For example, the position is far from the center of the annotations (you can
> get
> > the outer rectangle of annotations), applications 
> > can pass the event to form.
> 
> What if the two annotations have the exact same size and position? I know it's
a
> contrived example, but if the app has the z-order information, it would be
able
> to make better decisions.

I think apps need the z-order information. See
https://codereview.chromium.org/1278053004 and its associated bug.