No XMP metadata shown in properties

Bug #2045472 reported by Yves Roggeman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qpdfview
Triaged
Wishlist
Unassigned

Bug Description

In PDF-2.0 standard, the current one, /Info metadata are depreciated and no more generated by (some) software, like LuaTex.
Instead, XMP metadata are used to store Author, Title, Subject, Keywords, a.s.o.
Most PDF viewers actually show these parameters, together with the remaining /Info ones. See evince for example in Gnome world.
But sadly not qpdfview (version 0.5.0+ds-2, as in Ubuntu Mantic repositories) in its Properties dock…
I hope this will be soon corrected (or enhanced).
Thank you

Revision history for this message
Adam Reichold (adamreichold) wrote :

Hello Yves,

thank you for taking the time to report this! Do you happen to know if the integration of XMP metadata in Evince is done via the glib frontend of the Poppler library or if Evince accesses the XMP metadata directly itself? Maybe you even have a link to the corresponding source code? Thanks.

Regards,
Adam

Changed in qpdfview:
status: New → Triaged
milestone: none → 0.5.1
importance: Undecided → Wishlist
importance: Wishlist → Critical
importance: Critical → Wishlist
Revision history for this message
Adam Reichold (adamreichold) wrote :

From a quick glance, it seems like this would entail fetching the XML data via `poppler::Document::metadata` and then parsing it using either a third-party library or code similar to that used in https://gitlab.gnome.org/GNOME/evince/-/blob/main/libdocument/ev-xmp.c

Revision history for this message
Yves Roggeman (yrogge) wrote :

Yes.
It seems that Evince uses its own code "ev-xmp.c" to retrieve XMP metatdata directly, parsing the PDF file into some internal struct.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.