Pages: « 1 2 3 4 5 6 7 8 9 10 »
 on: April 04, 2017, 01:13:21 PM 
Started by Fa - Last post by Derek Read
Your issue with missing glyphs (Chinese appearing as white space in the PDF when viewed, or possibly question marks) when using the Book via RenderX deliverable would be a font embedding issue. You must have made changes to the DITA OT to get any PDF output to embed the correct fonts into the PDF file so that Unicode characters above code point 255 have the proper glyphs embedded into the PDF (including Chinese and Russian). That is a requirement of the PDF format (as outlined by Adobe) and a limitation of how the DITA OT and RenderX are configured. Out of the box they are not configured to embed any fonts (that is discussed in various other threads on this forum that talk about getting to embed fonts into the PDF for various languages including Russian, Chinese and Greek -- bring up your forum profile and click on "Show Posts").

As to your main issue with "XMetaL Enhanced PDF via RenderX XEP" failing, until this is looked into in depth by someone to see if this is a failure with that deliverable, or due to changes in newer versions of the DITA Open Toolkit, I would suggest trying an older version of the DITA OT. XMetaL Author Enterprise 12 includes three versions of the DITA OT (2.4, 2.2 and 2.0). To switch to an older version:

1. Launch XMetaL Author Enterprise 12.
2. From the Tools menu select Configure Output.
3. On the Advanced tab locate the following and add an underscore to the front to disable it:


4. On the Advanced tab locate the following and remove the underscores to enable it:


5. If 2.2 doesn't work then you can enable 2.0. On the Advanced tab locate both of the following and add underscores to disable them:



With version 12, when neither version 2.4 or 2.2 of the DITA OT is enabled (using those overrides) then DITA OT version 2.0 is run. On most systems all three DITA OT versions will be located here:

Before trying XMetaL Author Enterprise 11 which version of the software were you using to successfully produce PDF output?

If it was quite old I suspect some changes you made to the DITA OT are no longer compatible with newer versions of the DITA OT. You may need to adjust both the files being altered and the changes. Significant architectural changes were made to the DITA OT around versions 1.5 / 1.6 / 1.7 as well as many feature additions and bug fixes since then. If you are just dropping files you previously modified onto a newer copy of the DITA OT without testing and debugging those changes they might be ignored (at best) or they might break (worst case) the DITA OT.

If you suspect that is the case and you do not have a systematic record of what was altered (which files were altered and why) you would have to do a diff comparison between your altered files and the equivalent new files in the current version of the DITA OT and try to figure out if each change is needed, whether the altered file still exists, or has been subsequently modified to add a new feature or fix some bug (perhaps a bug you fixed in a different way), or other things.

 on: April 04, 2017, 06:55:00 AM 
Started by Fa - Last post by Fa

Using XMetaL 11 (and I get the same result with v.12), I am able to produce pdf output of my manuals for various languages (including Russian, as far as I can tell), but I am unable to produce the Chinese output.

I can open every single file in XMetaL without getting an error, but I just get the "deliverable could not be created..." message.

At first I thought it was because of changes I have made to files in the DITA_OT and Renderx folders, but I have tried it on my colleague's machine, that has a clean install, and I get the same result.

I have also tried to produce older documents for which I could successfully generate pdfs with XMetaL 6 in all languages, and same result: Chinese won't work.

So to be clear, I choose the "XMetaL enhanced pdf via RenderX XEP" option.

Just out of curiosity, I tried the "Book via RenderX" option, and I get an output, but without Chinese characters (i.e. all the Chinese characters are replaced with a white space. So I only get the few latin characters that are left in the Chinese text and the pictures. That's it. That could be a font option, since I don't know where the font (and other settings) for the book output are stored. But I haven't investigated further since this isn't what I need.

Has anyone ran into this issue or found an easy solution to the problem?

I attach a copy of the log, in case there is something there that can help.

Any hint will be very appreciated!

Best regards,

 on: March 28, 2017, 12:25:40 PM 
Started by IBashar - Last post by Derek Read
If Visual Studio doesn't offer to automatically convert the files to whatever new format 2017 uses then you will probably have to stick with 2015. Solution files are something that Visual Studio creates (not XMetaL Developer). Or you might check on the Microsoft support pages for help.

The new version of XMetaL Developer (version 12) will be tested on current releases of Visual Studio but development on 12 has not begun yet.

 on: March 28, 2017, 02:00:48 AM 
Started by IBashar - Last post by IBashar

When I run the XMetal Developer 11 installer it works fine (except for the help modules) but Visual Studio Community 2017 can't open my Solution files ("incompatible").

It used to run fine with Visual Studio Community 2015. Can you help me with that ?


 on: March 27, 2017, 05:59:47 PM 
Started by 55 - Last post by Derek Read
Are you referring to the Assets tab?

That feature was designed to function with its files stored in Program Files (in the installation path) long before Windows implemented an increased security policy with XP SP2 that made it non-functional. The feature was deprecated in version 5, became unsupported in version 6 and then was disabled starting with version 7.

 on: March 20, 2017, 10:27:01 PM 
Started by 55 - Last post by C4
We need a setting to show assets by default which we cannot locate on the new ini file. Do you know where this would be set?

 on: March 20, 2017, 08:11:19 AM 
Started by Fa - Last post by Fa
Thank you very much Dereck for your detailed answers. You raise some very good points in them.

I have already looked at the possibility to create our own DTD, but as you will have noticed, I have no experience with it at all and very limited knowledge and understanding of DITA in general. And I don't think the company is willing to purchase custom-made DTDs, so that's kind of out of the question. Also the point you raised of no longer having standard DITA raises a red flag.

I will try to understand better why they need these and how they are converted.

Right now your second suggestion really seems the best (where we would use valid DITA elements and modify the xslt to convert those elements to whatever they want in the html output). So thank you again for taking the time of posting a second reply with this suggestion!

I will follow up on this as soon I get something new to tell.

Best regards,

 on: March 15, 2017, 07:30:24 PM 
Started by Fa - Last post by Derek Read
One more point of clarification, you say "They need this to be included in the htm files that are generated when building their software".

It sounds like this element ends up in the final output, meaning that it does not necessarily need to be in the DITA content itself. I suspect what might have occurred with the older version of the DITA Open Toolkit is that it did not recognize the element as being DITA, and it had some form of bug that caused it to pass this element through to the HTML output unmodified. Either newer versions of the DITA OT have corrected this bug or they are simply validating the document properly (stopping all output).

If that is the case then replacing it with a valid DITA element and then altering the DITA Open Toolkit (its XSLT) so that it inserts <Help_anchor> into the HTML output when it sees that element (and possibly element + specific attribute value) is probably what you would want to do.

I'm not even clear on that point though, because <Help_anchor> doesn't exist as part of any HTML spec that I'm aware of, so adding it to an HTML file would make that HTML invalid as well. Perhaps the HTML is custom as well? And it is being displayed with some custom browser or other software (so not really HTML, but perhaps based on HTML)?

 on: March 15, 2017, 07:24:24 PM 
Started by Derek Read - Last post by Derek Read
This topic has been moved to DITA and XMetaL Discussion.

 on: March 15, 2017, 12:30:53 PM 
Started by ChrisTMH - Last post by Derek Read
I think you should submit everything you have done to XMetaL Support with a good description of where everything needs to be installed. They they can try to set up a similar system to understand what your issue is, what you are trying to solve, and how that might be done. Most of this sounds like something that can be supported. Include a sample XML document that is representative of something that causes issues.

No guarantees, but it is possible that some kind of solution could be created.

The "custom toolbar" has me a bit concerned though as extending the DITA authoring functionality in this way is not something that is supported, but I guess we will know once they see everything.

Perhaps throwing a faster computer at this issue might be the easiest solution for people that need to work with files that have very large tables?

Pages: « 1 2 3 4 5 6 7 8 9 10 »
email us