Pages: 1
Print
Author Topic: Displaying East Asian characters correctly  (Read 2391 times)
joepairman
Member

Posts: 7


« on: July 11, 2010, 08:31:30 AM »

Product: XMetaL Author Enterprise 5.5.0.266

I'm having problems displaying East Asian characters. Specifically, when I open a Korean file as a partial document or in Plain Text View, the characters are shown as squares, meaning that XMetaL isn't using an appropriate font. I've read this thread so I understand the issues involved, but I have a few related questions.
  • How can I get Arial Unicode MS to show up as a choice in the options for Plain Text View?
  • What's the CSS file that controls display when I edit as a partial document in Tags On and Normal views?
  • Why, when I paste Korean characters directly into XMetaL, and save the file, close it then open it again, do the characters still display correctly? What's the difference between that and opening a file that was in Korean in the first place?

Thanks for any tips or information.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2507



WWW
« Reply #1 on: July 19, 2010, 05:23:49 PM »

1) The drop down list that controls which font is used for Plain Text view list only those fonts installed on your system that declare themselves as "monospace" (Courier New is one example). Arial Unicode MS is not monospaced and so will not show up in that list (Tools > Options > Plain Text View). Plain Text View does this because it is a "code view" and designed to work properly with monospaced fonts. If a non-monospaced font is used the cursor position and other rendering may not work correctly. If you wish to get the product to use a font not listed in this Options dialog you can set it manually in the xmetal60.ini file. The setting is: default_font_name = font name. Most Korean fonts should be "monospaced" in theory (as with most CJK fonts in general) though they may not actually identify themselves as such. This may be because although large portions of the font are monospaced (the Korean glyphs and perhaps CJK glyphs if present) the font may actually contain some variable width glyphs as well, or the designer may have not identified the font as monospace even if it is fully monospaced.

2) If you open a document from disk and the DTD cannot be found (because the SYSTEM id path is incorrect and the file either contains no PUBLIC id or a catalog file with corresponding PUBLIC id entries is unavailable) you are prompted to locate the DTD. At this point you can opt to "Edit as a partial document". If you select this option AND select "Choose auxiliary DTD / Rules File" then the customization associated with that DTD or RLX file will be used (basically CSS, CTM and MCR files with the same filename in the same folder as the DTD). If you do not choose this second option then no customization files will be loaded and a "stub" DTD will be generated for you with the same name as the XML document. You could place a CSS file in the same location as this DTD and it will be loaded.

If you are opening a file referenced as an external entity from within a file that has a customization loaded by double clicking on the entity reference (a little white box) then the same customization will be loaded for the file that is opened. However, this only works to one level. If the referenced file (external entity) itself contains a reference to another external entity then the customization is not loaded (for the second external file entity).

If this is a common need it should be possible to work around this. It should be possible to create a customization that would assume files opened this way are meant to always use a specific customization, or by prompting the user with a list of options, or if something else in the file uniquely identifies them such as a root element name or other content. The script would then create a new temporary document (from string or template) containing a full and proper DOCTYPE declaration and inject the content of the partial document into it before the document is opened thereby allowing XMetaL to automatically locate. A similar process would then be done when saving these types of partial documents if desired. Some CMS integrations support similar functionality (Documentum for example has a "chunking" feature) but this is typically performed inside the CMS and is completely transparent to XMetaL Author (ie: Author only ever sees a full and complete document though it may be composed of various "chunks" stored in the CMS).

3) We do not know what might be occurring here. When you paste from the clipboard XMetaL should be accepting the dataformat called "Text" or "Unicode Text". I've never seen the issue described so suspect that what is occurring here is actually that a font is incorrectly set in the XMetaL customization being used (or if Plain Text then an appropriate font set in the Options dialog). I think we would need to see some sample files and obtain information about exactly where you are copying from (product and version number) so we can try to reproduce the issue. In this case if you can reproduce the issue with the Journalist or DITA customizations that would be best, otherwise we will also wish to obtain a copy of your own customization (DTD/XSD, CSS, CTM and MCR files at minimum). You may submit those as a response to the support case you recently filed.
Logged
joepairman
Member

Posts: 7


« Reply #2 on: July 24, 2010, 07:19:05 AM »

Thanks for the detailed information, Derek, and sorry to take a while to get back to you. A few quick replies:

1) BatangChe, a Korean font, shows up OK in the Plain Text View options. I'd thought it would make more sense to get Arial Unicode MS in there to cover everything without having to switch fonts. But after your explanation I'll proceed with caution.

2) That's enough information to go on for now, thanks.

3) We don't currently have any customizations to the DTD, CSS, etc. We have a CMS bridge but this shouldn't be affecting the default templates as far as I know. This question was really due to curiosity -- why does pasting/saving/opening Korean text work when it shouldn't, according to the description in the other thread I linked (if I understood it correctly). We don't actually need this functionality at the moment, but if you are also interested you could try the following:
i) Create a new DITA concept.
ii) From the Wikipedia Korean Language page, copy 인천/仁川 (the characters for Incheon).
iii) Paste the characters into the empty paragraph in the concept, then save and close the file, and close XMetaL.
iv) Open the file in XMetaL again. The characters should display OK.

Thanks,
Joe
Logged
Pages: 1
Print
Jump to:  

email us