DITA and XMetaL Discussion

XMetaL Community Forum DITA and XMetaL Discussion XMetal 7.0: Auto-generated text in PDF not inheriting xml:lang from map

  • nlpharrison

    XMetal 7.0: Auto-generated text in PDF not inheriting xml:lang from map

    Participants 0
    Replies 1
    Last Activity 8 years ago

    I'm using the PDF generation using Renderx on a Chinese source document, with xml:lang=”zh-tw” set at the map level.  It's clear, from the way my defined fonts show up, that the @xml:lang value is being read, and the document content itself shows up in the correct Chinese.  But the strings for 'Table', 'Figure', 'Note' etc. are all being read from the cfg/fo/vars/en.xml file instead of the zh_TW.xml file.  I tried renaming the Chinese version of the variables file to zh-tw.xml and/or zh_tw.xml, in case the '_TW' string was a problem, but nothing changed.  Where in the PDF2 stylesheets does the xml:lang value get propagated from the map to the topics?  I'd like to put in some messages to see if I can debug this, but don't know where to start.

    Reply

    Derek Read

    Reply to: XMetal 7.0: Auto-generated text in PDF not inheriting xml:lang from map

    I seem to recall in older versions of the DITA Open Toolkit there were issues with capitalization, so that even though the DITA OT is running on Windows some parts of the DITA OT might not read in files with uppercase names (or it might have been lowercase). Not sure if those were addressed with the release you would have, which I think is probably 1.5.4. In newer versions the DITA OT (I'm looking at the version included with XMetaL Author Enterprise 9, which is 1.8) it seems to have code to accept both – and _ in these xml:lang values. The code replaces “_” with “-” so that all file names should be able to follow the standard values for xml:lang but allow non-standard values for the xml:lang attribute itself (values that use underscore instead of hyphen). That might be your issue?

    Whatever the character or casing issue might be I would make sure the file names use the same style as the files included with the DITA OT. Hopefully, that should avoid you having to change any XSLT.

    Other than that I cannot think of anything that might help unless the files you are modifying are in the wrong location. With XMetaL Author Enterprise versions 6 through 8 the DITA OT is installed in one location but deployed to and run from a copy in your %appdata% folder. Obviously if you've got fonts working though, you must be working with the deployed version of the DITA OT.

    Searching for “xml:lang” in the PDF2 folders (I use Notepad++ for this stuff in case you need a text editor that incorporates file searching) in the current release shows me that for PDF2 it is set up in DITA_OTpluginsorg.dita.pdf2xslcommonvars.xsl Your location will be different since the version of the DITA OT you have predates a bunch of work they did to reorganize the plug-ins folder to identify plug-ins based on the creating organization, but the last two folders will probably be the same.

    That file creates an XSLT variable named $locale, which is created based on another variable named $localeFiles which doesn't appear elsewhere in the PDF2 files. It must be created as part of the more generic portion of the DITA OT processing. It would make most sense to me if it was done in the map merge code so it would only need to be written once and inherited by all plug-ins.

    Reply

  • You must be logged in to reply to this topic.

Lost Your Password?

Products
Downloads
Support