jsPDF icon indicating copy to clipboard operation
jsPDF copied to clipboard

dropping namespace argument to addMetadata and remove the rdf:Description and jspdf:metadata elements

Open stefan123t opened this issue 4 years ago • 4 comments

Dear Lukas,

I have been dropping namespace argument to addMetadata and removed the rdf:Description and jspdf:metadata elements as discussed in XMP metadata inclusion not supported #763

I do not know how to make it backwards compatible, but I am feeling lucky, you may sort it out, as this is my first pull request =^/

Kind regards, Stefan

stefan123t avatar Dec 04 '20 08:12 stefan123t

Dear Lukas,

sorry for not answering your questions earlier, it somehow slipped my attention being in the PR and not the original issue #763.

I just had a cursory look at https://www.w3.org/TR/rdf-syntax-grammar/

The following document describes XMP as being "based on the W3C standard [ie. RDF, my assumption]. The Adobe metadata framework constitutes the first ever wide-scale, comprehensive, and practical use of RDF (Resource Description Format)." and where "RDF specifies IDs in XML sequences, structured by source, property, and value(or alternatively subject, predicate, and object). RDF schemas define vocabu-lary. Adobe designed the standard XMP schemas. The XMP framework permitsthe integration of any schema that is structured in accordance with the specifi-cation. Area-specific schemas (such as IPTC and NewsML) can also be de-scribed in XMP data packages."

It is basically here where I would like to add basic Adobe XMP metadata, Adobe PDF Schema, but also Dublin Core Metadata Initiative – dublincore.org, xmpMM etc. They are all encoded / written inside of the enclosing rdf:RDF tag and will open & close their own rdf:Description as exemplified in the #763 code example I have given for our code.

See the pages 5-10 in the following pdf document. https://www.pdfa.org/wp-content/until2016_uploads/2011/08/pdfa_metadata-2b.pdf

I have basically reverse engineered the fields shown and filled in a distilled PDF compared to one generated by jsPDF and changed the rdf:RDF content accordingly.

I am no expert on XML but for me the jspdf:metadata element seems fairly superfluous and should simply be dropped. While the rdf:Description elements should sport the correct namespace depending on whether you are trying to convey Dublin Core, Adobe PDF, Adobe XMP or Adobe XMPmm metadata elements.

For our usage it works using the workaround described, though it is truly very hackish and produces not really well-formed documents with empty tags above and below the actual rdf:Description elements with the content.

So:

  1. yes, rdf:RDF is IMHO always required.
  2. it is debateable which rdf:Description's each user wants to pass into the generated document. I myself can come up with the following:
  • Basic XMP (default)
  • Adobe PDF (basic default as well)
  • Dublin Core (important!)
  • Media Management (I believe this is XMPmm)
  • Rights Management (haven't used, probably needs some crypto too)
  1. I have no use for the jspdf:metadata, maybe we can ignore / remove this ? IMHO We should ask @jutunen Jussi who did the initial implementation what the use of this is.

Kind regards, Stefan

stefan123t avatar Nov 23 '21 11:11 stefan123t

Thanks for the research. So, if I understand correctly, what we should do now in this PR is

  • Drop the jspdf:metadata tag (already done)
  • Drop rdf:Description so users can choose the namespace (already done)
  • Address backwards compatibility: would you say the feature was unusable before with the jspdf:metadata and rdf:Description tags? Then I think we don't need to care about backwards compatibility. Otherwise, we need to make it backwards compatible.

HackbrettXXX avatar Dec 02 '21 08:12 HackbrettXXX

Hi Lukas, I could not make use of the feature without these changes as mentioned in the Issue report. Though I do not know how @jutunen uses it. Him having implemented the original support he may require some backwards compatibility. Kind regards, Stefan

stefan123t avatar Dec 02 '21 15:12 stefan123t

Alright, since @jutunen isn't replying, I think we should go the save route and implement it backwards compatible. I suggest this: we add a hotfix "rdf_metadata". When it's enabled, the addMetadata function ignores its second argument and doesn't add the rdf:Description and jspdf:metadata tags. If it's not enabled, we keep the old functionality. It should be disabled by default for compatibility. With the next major release, we will make the hotfix the default behavior.

Could you implement it this way? Please also add the new hotfix to the HOTFIX_README.

HackbrettXXX avatar Dec 16 '21 09:12 HackbrettXXX