Reply to: Displaying East Asian characters correctlyJuly 19, 2010 at 11:23 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.