Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve XMP #12270

Open
2 of 6 tasks
koppor opened this issue Apr 12, 2018 · 8 comments
Open
2 of 6 tasks

Improve XMP #12270

koppor opened this issue Apr 12, 2018 · 8 comments
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty.

Comments

@koppor
Copy link
Member

koppor commented Apr 12, 2018

Follow up of #3895

  • Why does the order of XML elements change at a second export? This IMHO should not happen.
    grafik
  • In non-BibTeX fields, There should a be a cleanup made. latex2unicode at each field.
    "Proceedings of the 10\textsuperscript{th} Central European Workshop on Services and their Composition ({ZEUS} 2018" should become "Proceedings of the 10th Central European Workshop on Services and their Composition ({ZEUS} 2018)"
  • In non-BibTeX fields, a latex cleanup should be executed. - Maybe this is done by the latex2unicode thing: "{CEUR} Workshop Proceeding" <-- Please no {} in the XMP.
  • I am not sure whether <rdf:li>bibtex/url/https://adr.github.io/madr/</rdf:li> is the correct RDF searlization for an URL. According to https://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-list-elements, it should be <rdf:li rdf:resource="https://adr.github.io/madr"/> - this affects export and import
  • Keywords should be saved differently
        <dc:subject>
          <rdf:Bag>
            <rdf:li>ADR</rdf:li>
            <rdf:li>MADR</rdf:li>
            <rdf:li>architecture decision records</rdf:li>
            <rdf:li>architectural decision records</rdf:li>
            <rdf:li>Nygard</rdf:li>
          </rdf:Bag>
        </dc:subject>
    
    becomes ; ADR; MADR; architecture decision records; architectural decision records; Nygard, which is good enough. (See Ctrl+D in Acrobat Reader)

Test entry:

@InProceedings{KoppAZ-MADR-ZEUS-2018,
  author    = {Kopp, Oliver and Armbruster, Anita and Zimmermann, Olaf},
  title     = {Markdown Architectural Decision Records: Format and Tool Support},
  booktitle = {Proceedings of the 10\textsuperscript{th} Central European Workshop on Services and their Composition ({ZEUS} 2018)},
  year      = {2018},
  volume    = {2072},
  series    = {{CEUR} Workshop Proceedings},
  pages     = {55--62},
  publisher = {CEUR-WS.org},
  keywords  = {ADR; MADR; architecture decision records; architectural decision records; Nygard},
  url       = {https://adr.github.io/madr/},
}

Test setting now at https://github.com/JabRef/jabref/tree/feature/xmp-provement/src/test/resources/pdfs/KoppAZ-MADR-ZEUS-2018

@johannes-manner
Copy link
Collaborator

johannes-manner commented Apr 24, 2018

Point 4: url rdf serialization. I am also unsure how to serialize urls right.. I found no clear description, but I found an example on the dublin core home page (point 4.15) http://www.dublincore.org/documents/2000/07/16/usageguide/generic/#rights
It is a hint, that serializing the url in the way we do in dublin core is ok. What's your opinion?

Point 5: "Keywords should be saved differently" - why to save the keywords differently? All other fields are also stored as lists in the xmp metadata. Maybe the interoperability to other schemas is influenced by a single item list with a custom separator.

@koppor
Copy link
Member Author

koppor commented Apr 24, 2018

Point 4: I thought about seeAlso (see https://www.w3.org/wiki/UsingSeeAlso), but it seems to be more complicated. See that bibtex/url can only be read by JabRef and not by other tools. Storing XMP should be interoperable with other tools, too.

Point 5: Keywords should appear as follows:

grafik

With the current export:

grafik

So, other tools will have difficulties to parse the information correctly.

@koppor
Copy link
Member Author

koppor commented Nov 7, 2020

Another library for XMP: https://github.com/drewnoakes/metadata-extractor

@Marathon2112
Copy link

I'm linking #7925 here as well.

@koppor koppor added the good first issue An issue intended for project-newcomers. Varies in difficulty. label Aug 29, 2021
@koppor
Copy link
Member Author

koppor commented Sep 22, 2021

This task needs a proper requirements engineering, test cases and trial (because of the other available library). One has to test with Acrobat Reader and other PDF tools.

@Siedlerchr
Copy link
Member

Refs #8789

@Priyanshi-1001
Copy link

@koppor I tried to reproduce this Error,
Added Test Entry in Entitles and tried to export XMP meta data to PDF but its not succeeded, Am I Doing correct?

@koppor
Copy link
Member Author

koppor commented Jan 31, 2024

@Priyanshi-1001 I don't understand. You should provide detailed steps what you are doing. Do you use the test PDF linked at https://github.com/JabRef/jabref/tree/feature/xmp-provement/src/test/resources/pdfs/KoppAZ-MADR-ZEUS-2018?rgh-link-date=2018-04-12T15%3A02%3A56Z? What do you see in your PDF program? What do you mean by "not succeeded"?

@koppor koppor transferred this issue from JabRef/jabref-koppor Dec 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue An issue intended for project-newcomers. Varies in difficulty.
Projects
Status: Free to take
Status: Free to take
Development

No branches or pull requests

5 participants