Russian info from map topicmeta to PDF properties

[Yuliya]

Hello!
I need to insert information from map\topicmeta to PDF properties (for example, title).
I customize template "createMetadata".
For example:

Code: Select all

xsl:template name="createMetadata">

        <fo:declarations >

            <x:xmpmeta>

                <rdf:RDF>

                    <rdf:Description rdf:about="">

                       <dc:title>

                             <xsl:value-of select="//*[contains(@class, ' map/map ')]/@title"/>

                       </dc:title>                 

                        <dc:creator>Document author</dc:creator>

                        <dc:description>Document subject</dc:description>

                    </rdf:Description>

                 </rdf:RDF>

            </x:xmpmeta>

        </fo:declarations>

    </xsl:template>

When I publish document in English, doc is fine and PDF properties are inserted correctly.
For the purpose of publishing documents in Russian I add locale info:

Code: Select all

<dc:title xml:lang="ru-RU">

 <xsl:value-of select="//*[contains(@class, ' map/map ')]/@title"/>

</dc:title>

But it doesn't help - document is OK, but there is no information in PDF properties.
I tried to analize topic.fo file and comapare Russian and English "versions" of fo-files.
I found out the following: DITA OT makes additional fo:inline block for Russian title.
But I have no idea what should I do with it.
Help, please
Thank U!

[radu_pisoi]

Hi,

Apache FOP uses XMP (eXtensible Metadata Platform, specified by Adobe) for representing the document metadata. Conforming with this specification, if you want to specify alternative languages for the publication title you have to write something like that:

Code: Select all

<xmp:Title>

  <rdf:Alt>

<rdf:li xml:lang="x-default">XMP - Extensible Metadata Platform</rdf:li>

<rdf:li xml:lang="en-us">XMP - Extensible Metadata Platform</rdf:li>

<rdf:li xml:lang="fr-fr">XMP - Une Platforme Extensible pour les Métadonnées</rdf:li>

    <rdf:li xml:lang="it-it">XMP - Piattaforma Estendibile di Metadata</rdf:li>

  </rdf:Alt>

</xmp:Title>

The xml:lang qualifier is written as an attribute of the XML element whose character data is the value (in this case, the rdf:li elements).
Note also the special language value "x-default", which specifies the default title to be used.

See more details in the Language Alternatives section from XML Specification:
http://partners.adobe.com/public/develo ... cation.pdf

If the above information is not enough to resolve your problem, could you give us more details about your configuration and use case?
* what version of oXygen do you use?
* do you use a custom DITA-OT or the one that comes embedded with oXygen?
* I understand that you want to publish your DITA map in different languages. Could you tell us how your DITA map is organized for this purpose?
* Also, could you tell us what you want to obtain? A single PDF with multiple languages or a PDF for each language?

[Yuliya]

Hi, Radu!
Thank U for the quick answer and for your adviсe. Unfortunately, id doesn't help.
I wrote the following xsl-expression:

Code: Select all

<xsl:template name="createMetadata">

        <fo:declarations >

            <x:xmpmeta>

                <rdf:RDF>

                    <rdf:Description>

                        <dc:title>

                            <rdf:Alt>

                                <rdf:li xml:lang="ru-ru">Bercut ЮЮЮ</rdf:li>

                            </rdf:Alt>

                        </dc:title>

                    </rdf:Description>

               </rdf:RDF>

            </x:xmpmeta>

        </fo:declarations>

</xsl:template>

Where ЮЮЮ - Russian letters.
Transformation failed with NullPointerException error.
When I put an English text as the value of <rdf:li>, everything is OK.

Inside the fo-file I see the additional fo:inline block before Russian letters ЮЮЮ (I guess, that is the problem):

Code: Select all

<fo:declarations>

 <x:xmpmeta>

   <rdf:RDF>

      <rdf:Description>

           <dc:title>

                <rdf:Alt>

                   <rdf:li xml:lang="ru-ru" line-height-shift-adjustment="disregard-shifts">Bercut 

                        [b]<fo:inline line-height="100%" font-family="Times New Roman, Times, Arial Unicode MS, Tahoma, Batang">ЮЮЮ</fo:inline>[/b]

                    </rdf:li>

                </rdf:Alt>

           </dc:title>

      </rdf:Description>

   </rdf:RDF>

  </x:xmpmeta>

</fo:declarations>

When there is no rissian letters in <rdf:li>, no additional fo:block is inserted.

Regarding your questions:
* We use <oXygen/> XML Author 16.1, build 2015012213
* We use embedded DITA-OT and customized xsl-file with several templates
* Basically we publish documents in Russian (since 2010 ). The idea of getting metadata in PDF output is new one
We set xml:lang properties as ru-ru in all topics and maps.
*Now I want to obtain a PDF in Russian language.

Thank U!

[radu_pisoi]

Hi,

Inside the fo-file I see the additional fo:inline block before Russian letters ЮЮЮ (I guess, that is the problem):

Yes, you are right. This is the main problem because the Apache FOP processor is not expected to encounter these elements inside the XMP metadata language.

These elements are produced by the transform.topic2fo.i18n.filter DITA-OT step. I've added an issue to the DITA-OT project, see https://github.com/dita-ot/dita-ot/issues/2154.

Meanwhile, a possible workaround could be to skip these elements from the i18n-postprocess.xsl stylesheet which loads the stage3.fo and produces the topic.fo file. This stylesheet is located here: {oXygen}\frameworks\dita\DITA-OT\plugins\org.dita.pdf2\xsl\fo\i18n-postprocess.xsl.

To do this, you have to add the following template:

Code: Select all

<xsl:template match="x:xmpmeta//opentopic-i18n:text-fragment" priority="+10" xmlns:x="adobe:ns:meta/">

    <xsl:apply-templates/>

  </xsl:template>

However, after you apply the above patch, I think you can discard your PDF customization that adds the title metadata in PDF. The title should be loaded automatically from the DITA Map without any customization.

[Yuliya]

Hi,
Thank you very-very much! It works! I'm very happy

[ckabstein]

Hello,

We have almost the same issue, or the same, I don't know.
Unfortunately, the work-around doesn't work for us. I even tried out the fix from Jarno in Github, but to no avail.
I presume, something else needs to be done in our case.
Our code works fine for standard European languages (en, de, fr, it, es), but we're having issues with Japanese and Russian.
For the title, XMP structure: 1 is inserted, and the "Additional Metadata" button in the PDF properties can no longer be clicked, so that our copyright information gets lost.

Code: Select all

<xsl:template name="createMetadata">

    <fo:declarations>

      <x:xmpmeta>

        <rdf:RDF>

          <rdf:Description rdf:about="" xmlns:xmpRights="http://ns.adobe.com/xap/1.0/rights/">

            <xsl:variable name="title" as="xs:string?">

              <xsl:apply-templates select="." mode="dita-ot:title-metadata"/>

            </xsl:variable>

              <dc:title>

               <xsl:value-of select="//*[contains(@class, ' map/map ')]/@title"/>

              </dc:title>

            <!-- ck-2017-05-24: Added publisher instead of authorinformation -->

            <xsl:variable name="publisher" as="xs:string?">

              <xsl:apply-templates select="." mode="dita-ot:publisher-metadata"/>

            </xsl:variable>

            <xsl:if test="exists($publisher)">

              <dc:creator>

                <xsl:value-of select="$publisher"/>

              </dc:creator>

            </xsl:if>

            <pdf:Keywords>

              <xsl:value-of select="$myProductName[1]"/>

              <xsl:value-of select="'_'"/>

              <xsl:value-of select="$myProductVersion[1]"/>

              <xsl:value-of select="'_'"/>

              <xsl:value-of select="/map/@xml:lang"/>

              <xsl:value-of select="'_'"/>

              <xsl:value-of select="$myPublishingDate[1]"/>

            </pdf:Keywords>

            <!-- ck-2017-05-24: Copied also the following variable in case it is needed for future purposes -->

            <xsl:variable name="subject" as="xs:string?">

              <xsl:apply-templates select="." mode="dita-ot:subject-metadata"/>

            </xsl:variable>

            <xsl:if test="exists($subject)">

              <dc:description>

                <rdf:Alt>

                  <rdf:li xml:lang="x-default">

                    <xsl:value-of select="$subject"/>

                  </rdf:li>

                </rdf:Alt>

              </dc:description>

            </xsl:if>

            <!-- ck-2017-05-24: Added Copyrighted, company name and year to Additional Metadata in PDF Properties.

            Also added language selection to Advanced Tab in PDF Properties-->

            <xmpRights:Marked>True</xmpRights:Marked>

            <dc:rights><xsl:value-of select="concat($publisher,' ',year-from-date(current-date()))"/></dc:rights>

            <dc:language><xsl:value-of select="/map/@xml:lang"/></dc:language>

            <xmp:CreatorTool>DITA Open Toolkit</xmp:CreatorTool>

          </rdf:Description>

        </rdf:RDF>

      </x:xmpmeta>

    </fo:declarations>

  </xsl:template>

* We use oXygen 19.0, build build 2017042020
* We use a customized DITA OT, based on version 2.0.1, using our own plug-in.
* We publish our maps individually, each xml:lang is set in the map. Our main map structure follows the DITA standard and includes some adjustments that shouldn't cause the issue. Maybe it makes sense to send you a sample map.
* We create a PDF for each language. In very rare cases, we create a single PDF with multiple languages, but I would like to have this issue solved for individual PDFs.

Thanks,
Christina

[Radu]

Hi Christina,

Sorry for the delay.
We do not have much experience with this, for the languages where this does not work for you maybe you should set the "clean.temp="no"" parameter and look at the generated XSL-FO file, see how that generated section looks like...
Also maybe try to publish with a commercial FO processor like Antenna House, see if the generated PDF has the same problem. If it does, then probably it's a problem in the XSL-FO content, if not then it's maybe a bug in the Apache FOP processor.

Regards,
Radu