Return-Path: X-Original-To: apmail-pdfbox-users-archive@www.apache.org Delivered-To: apmail-pdfbox-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 43988183CC for ; Fri, 5 Feb 2016 09:35:56 +0000 (UTC) Received: (qmail 85175 invoked by uid 500); 5 Feb 2016 09:35:49 -0000 Delivered-To: apmail-pdfbox-users-archive@pdfbox.apache.org Received: (qmail 85144 invoked by uid 500); 5 Feb 2016 09:35:49 -0000 Mailing-List: contact users-help@pdfbox.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@pdfbox.apache.org Delivered-To: mailing list users@pdfbox.apache.org Received: (qmail 85133 invoked by uid 99); 5 Feb 2016 09:35:49 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2016 09:35:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id F34F21805D1 for ; Fri, 5 Feb 2016 09:35:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.68 X-Spam-Level: X-Spam-Status: No, score=0.68 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id OKu3x9ifCb2W for ; Fri, 5 Feb 2016 09:35:47 +0000 (UTC) Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 23CF42050D for ; Fri, 5 Feb 2016 09:35:47 +0000 (UTC) Received: from G4W9121.americas.hpqcorp.net (g4w9121.houston.hp.com [16.210.21.16]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 6F7CB69 for ; Fri, 5 Feb 2016 09:35:40 +0000 (UTC) Received: from G4W9121.americas.hpqcorp.net (16.210.21.16) by G4W9121.americas.hpqcorp.net (16.210.21.16) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 5 Feb 2016 09:35:23 +0000 Received: from G9W3612.americas.hpqcorp.net (16.216.186.47) by G4W9121.americas.hpqcorp.net (16.210.21.16) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Fri, 5 Feb 2016 09:35:23 +0000 Received: from G4W3233.americas.hpqcorp.net ([169.254.5.127]) by G9W3612.americas.hpqcorp.net ([16.216.186.47]) with mapi id 14.03.0169.001; Fri, 5 Feb 2016 09:35:23 +0000 From: "Mehlhose, Frank (HP Enterprise Information Solutions)" To: "users@pdfbox.apache.org" Subject: PDFBOX-2896 - Problem in DublinCoreSchema title element occurs when deployed to Application Server, but is fine in Unit Tests Thread-Topic: PDFBOX-2896 - Problem in DublinCoreSchema title element occurs when deployed to Application Server, but is fine in Unit Tests Thread-Index: AdFf+G1BIFGABKtdRCC3rzSN+TWAsw== Date: Fri, 5 Feb 2016 09:35:22 +0000 Message-ID: <413A3FD7F5C7F245802A11E9E05A74162495A96D@G4W3233.americas.hpqcorp.net> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [16.210.48.22] Content-Type: multipart/related; boundary="_004_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_"; type="multipart/alternative" MIME-Version: 1.0 --_004_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_ Content-Type: multipart/alternative; boundary="_000_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_" --_000_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I'm trying to upgrade from pdfbox 1.8.10 to 2.0.0-RC3. We try to create valid PDF/A documents with pdfbox. I took the following example from trunk and recreated it in our application= : pdfbox\examples\src\main\java\org\apache\pdfbox\examples\pdmodel\CreatePDFA= .java I created a unit test similar to CreatePDFA.java and pdfbox creates valid P= DF/A document in our unit tests. But when I start to package the code into a WAR File and deploy it to a Wil= dfly 9.0.1-Final, pdfbox starts to create slightly different XMP Metadata. The XMP Metadata seems to be incorrect, just as described in https://issues= .apache.org/jira/browse/PDFBOX-2896 : PDF/A Rendition 1 B The list element for the Dublin Core title should have a xml:lang=3D"" attr= ibute instead of lang=3D"". The problem only occurs when the application is deployed to the application= server. If I manually adjust the Dublin Core title element, the resulting PDF is re= cognized as PDF/A by the Adobe Reader. What can cause the different results in the XMP Metadata between Unit Test = and Application Server Runtime? With kind regards Frank Mehlhose Application Business Services - Public Sector +49 152 0165 0812 Mobile +49 7031 4502 958 Office Herrenberger Strasse 140, 71034 B=F6blingen [HPE_logoemail] Gesch=E4ftsf=FChrer: Heiko Meyer (Vorsitzender), Thomas B=E4ssler, Volkhard= Bregulla, Michael Eberhardt, Angelika Gifford, Ernst Reichart. Vorsitzender des Aufsichtsrats: J=F6rg Me= nno Harms Sitz der Gesellschaft: B=F6blingen, Amtsgericht Stuttgart HRB 244081 WEEE-Reg.-Nr. DE 30409072 --_000_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I'm trying to upgrade from pdfb= ox 1.8.10 to 2.0.0-RC3.

We try to create valid PDF/A do= cuments with pdfbox.

 

I took the following example fr= om trunk and recreated it in our application:

pdfbox\examples\src\main\java\o= rg\apache\pdfbox\examples\pdmodel\CreatePDFA.java

 

I created a unit test similar t= o CreatePDFA.java and pdfbox creates valid PDF/A document in our unit tests= .

But when I start to package the= code into a WAR File and deploy it to a Wildfly 9.0.1-Final, pdfbox starts= to create slightly different XMP Metadata.

The XMP Metadata seems to be in= correct, just as described in https://issues.apache.org/jira/browse/PDFBOX-= 2896 :

<x:xmpmeta xmlns:x=3D"a= dobe:ns:meta/">

  <rdf:RDF xmlns:rdf=3D= "http://www.w3.org/1999/02/22-rdf-syntax-ns#">

    <rdf:Desc= ription xmlns:dc=3D"http://purl.org/dc/elements/1.1/" rdf:about= =3D"">

      = <dc:title>

     &= nbsp;  <rdf:Alt>

     &= nbsp;    <rdf:li lang=3D"x-default">PDF/A Re= ndition</rdf:li>

     &= nbsp;  </rdf:Alt>

      = </dc:title>

    </rdf:Des= cription>

    <rdf:Desc= ription xmlns:pdfaid=3D"http://www.aiim.org/pdfa/ns/id/" rdf:abou= t=3D"">

      = <pdfaid:part>1</pdfaid:part>

      = <pdfaid:conformance>B</pdfaid:conformance>

    </rdf:Des= cription>

  </rdf:RDF>

</x:xmpmeta>

 

The list element for the Dublin= Core title should have a xml:lang=3D"" attribute instead of lang= =3D"".

The problem only occurs when th= e application is deployed to the application server.

 

If I manually adjust the Dublin= Core title element, the resulting PDF is recognized as PDF/A by the Adobe = Reader.

What can cause the different re= sults in the XMP Metadata between Unit Test and Application Server Runtime?=

 

With kind regards

 

= Frank Mehlhose<= o:p>

A= pplication Business Services – Public Sector

+49 152 0165= 0812  Mobile

+49 7031 450= 2 958 Office
Herrenberger Strasse 140, 71034 B=F6blingen

 

3D"HPE_logoemail"

Gesch=E4ftsf=FChrer: Heiko Meyer= (Vorsitzender), Thomas B=E4ssler, Volkhard Bregulla, Michael Ebe= rhardt,
Angelika Gifford, Ernst Reichart. Vorsitzender des Aufsichtsrats: J=F6rg Me= nno Harms
Sitz der Gesellschaft: B=F6blingen, Amtsgericht Stuttgart HRB 244081
WEEE-Reg.-Nr. DE 30409072

 

--_000_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_-- --_004_413A3FD7F5C7F245802A11E9E05A74162495A96DG4W3233americas_--