Bug 53586 - [PATCH] Unify parsing of 'AA' dictionary entries in screen and widget annotations
Summary: [PATCH] Unify parsing of 'AA' dictionary entries in screen and widget annotat...
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 53589
  Show dependency treegraph
 
Reported: 2012-08-16 11:26 UTC by Tobias Koenig
Modified: 2012-08-24 17:16 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Patch that moves 'AA' parsing code to Annot base class (3.42 KB, application/octet-stream)
2012-08-16 11:26 UTC, Tobias Koenig
Details
Unifies the parsing of AA entries (2.93 KB, patch)
2012-08-16 13:48 UTC, Tobias Koenig
Details | Splinter Review
Provide 'AA' dictionary entries as LinkAction objects (6.41 KB, patch)
2012-08-17 14:30 UTC, Tobias Koenig
Details | Splinter Review
Updated patch (6.42 KB, patch)
2012-08-19 10:16 UTC, Tobias Koenig
Details | Splinter Review
Unify parsing of additional actions entries (6.38 KB, patch)
2012-08-20 07:23 UTC, Tobias Koenig
Details | Splinter Review

Description Tobias Koenig 2012-08-16 11:26:07 UTC
Created attachment 65647 [details]
Patch that moves 'AA' parsing code to Annot base class

The attached patch moves the parsing code for the 'AA' dictionary entry of the ScreenAnnotation and WidgetAnnotation to the Annot base class, since all annotations can have such an entry according to the PDF spec.
Comment 1 Tobias Koenig 2012-08-16 13:48:45 UTC
Created attachment 65651 [details] [review]
Unifies the parsing of AA entries
Comment 2 Tobias Koenig 2012-08-16 13:51:02 UTC
Since PDF spec 1.7 (in opposite to 1.6) defines the 'AA' dictionary entries only for Screen and Widget annotations, I have modified the patch to at least parse the entries in a unified way.
Comment 3 Carlos Garcia Campos 2012-08-16 15:41:52 UTC
Comment on attachment 65651 [details] [review]
Unifies the parsing of AA entries

Review of attachment 65651 [details] [review]:
-----------------------------------------------------------------

Instead of returning the internal object, AA should be parsed and a list of action objects should be returned.
Comment 4 Tobias Koenig 2012-08-17 07:08:38 UTC
(In reply to comment #3)
Hej Carlos,

> Instead of returning the internal object, AA should be parsed and a list of
> action objects should be returned.
I tried to stay consistent with the Page::getActions() implementation, which does it the same way. Converting the dictionaries into action objects inside the Annot/Page implementation seems to be the wrong place.
Comment 5 Tobias Koenig 2012-08-17 14:30:13 UTC
Created attachment 65697 [details] [review]
Provide 'AA' dictionary entries as LinkAction objects

This new patch moves the parsing of the 'AA' dictionary from the Qt4 frontend to the Annot class, so that all frontends can benefit from it.
The getAdditionalAction() methods return LinkAction objects now.
Comment 6 Carlos Garcia Campos 2012-08-18 16:58:42 UTC
Comment on attachment 65697 [details] [review]
Provide 'AA' dictionary entries as LinkAction objects

Review of attachment 65697 [details] [review]:
-----------------------------------------------------------------

Patch looks good to me, I've just a few minor comments.

::: poppler/Annot.cc
@@ +198,5 @@
> +static LinkAction* getAdditionalAction(Annot::AdditionalActionsType type, Object *additionalActions, PDFDoc *doc) {
> +
> +  Object additionalActionsObject;
> +
> +  additionalActions->fetch(doc->getXRef(), &additionalActionsObject);

in poppler we usually do something like:

if (additionalActions->fetch(doc->getXRef(), &additionalActionsObject)->isDict()) {
 .....
}
additionalActionsObject.free();

@@ +202,5 @@
> +  additionalActions->fetch(doc->getXRef(), &additionalActionsObject);
> +
> +  if (!additionalActionsObject.isDict()) {
> +    additionalActionsObject.free();
> +    return 0;

Use NULL instead of 0

@@ +216,5 @@
> +                     type == Annot::actionFocusOut ?      "BI" :
> +                     type == Annot::actionPageOpening ?   "PO" :
> +                     type == Annot::actionPageClosing ?   "PC" :
> +                     type == Annot::actionPageVisible ?   "PV" :
> +                     type == Annot::actionPageInvisible ? "PI" : 0);

Ditto.

@@ +220,5 @@
> +                     type == Annot::actionPageInvisible ? "PI" : 0);
> +
> +  Object actionObject;
> +  dict->lookup(key, &actionObject);
> +  LinkAction *linkAction = LinkAction::parseAction(&actionObject, doc->getCatalog()->getBaseURI());

LinkAction::parseAction() expects a dict, you could do something like this:

LinkAction *linkAction = NULL;
if (additionalActionsObject.dictLookup(key, &actionObject)->isDict()) {
  linkAction = LinkAction::parseAction(&actionObject, doc->getCatalog()->getBaseURI());
}

and you don't need the Dict variable.

@@ +5171,5 @@
> +
> +LinkAction* AnnotScreen::getAdditionalAction(AdditionalActionsType type)
> +{
> +  if (type == actionFocusIn || type == actionFocusOut) // not defined for screen annotation
> +    return 0;

Use NULL instead of 0.
Comment 7 Tobias Koenig 2012-08-19 10:16:15 UTC
Created attachment 65765 [details] [review]
Updated patch

Changed the '0' to NULL. Didn't integrated the other changes, they made the code more complex and difficult to read afaics.

Can somebody commit the patch, please? My account seems not to work anymore.
Comment 8 Tobias Koenig 2012-08-20 07:23:37 UTC
Created attachment 65817 [details] [review]
Unify parsing of additional actions entries

Integrate missing review comments
Comment 9 Carlos Garcia Campos 2012-08-20 15:17:50 UTC
Comment on attachment 65817 [details] [review]
Unify parsing of additional actions entries

Review of attachment 65817 [details] [review]:
-----------------------------------------------------------------

Patch looks good to me, if Albert and Pino have no objections, I'll commit it.
Comment 10 Carlos Garcia Campos 2012-08-24 17:16:11 UTC
Pushed to git master, thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.