DITA and XMetaL Discussion
pmasal May 21, 2013 at 8:23 am
Strange Behavior Editing ja-JP DITA with XMetaLMay 21, 2013 at 8:23 amParticipants 3Replies 4Last Activity 9 years, 3 months ago
Using XMetaL Enterprise 6.0 with SDL Trisoft authoring bridge 9.3. When entering JP characters in ja-JP DITA objects, the characters do not enter directly when typed. Rather they enter a very small “buffer zone” near the cursor location, but with very small characters. When Enter is pressed, they appear in the right font/location in aggregate.
Is there an issue with double-byte character entry with XMetaL 6.0? This is hindering our ja-JP DITA content authoring. Thanks!
Large Company in Seattle, WADerek Read May 21, 2013 at 9:06 pm
Reply to: Strange Behavior Editing ja-JP DITA with XMetaLMay 21, 2013 at 9:06 pm
It sounds to me like you are describing the input area of a Japanese IME (either one of the standard / built-in Windows IMEs or a 3rd party add-on). Also, from the description it sounds like it is functioning like most Japanese IMEs do.
XMetaL Author itself does not provide this feature, though we do have code that specifically supports this type of input in the product (tested with the standard Windows-supplied Japanese and Chinese IMEs). If the IME supports it (there is a standard way for Windows software to communicate information) then XMetaL Author can tell Windows where the current cursor (typing) position is and the IME can then position itself nearby (but XMetaL Author doesn't directly control it). Once you have given the IME the information it needs (via keypresses) it decides what to display and when to pass the actual characters on to the software it is being used with (in this case passing the Unicode characters into XMetaL Author).
Perhaps if there is a specific issue with it you could post a screen capture and point out what it is that isn't working as expected (perhaps in comparison with use of the IME with other software). I can then compare that to what I expect to see and let you know if this is normal or not. As this will be affected directly by the particular IME, any settings it has and the Windows version please provide as much information as possible.
It might also be more efficient to do this through XMetaL Support rather than on the forum.pmasal May 22, 2013 at 7:58 am
Reply to: Strange Behavior Editing ja-JP DITA with XMetaLMay 22, 2013 at 7:58 am
Thanks Derek. We're not using a Japanese IME. We're typing Japanese characters directly into XMetaL's tags-on authoring view, using Japanese character keyboards.
Attached is a screen capture that illustrates the issue. Just let me know if I should open an XMetaL Support ticket for this one. Please note how the user is editing the first
and the small buffer of JP characters appears outside the normal context. When the user presses enter, the characters appear as expected in the , but the users should be able to see them inline as with other languages. Thanks again.
Large Company in SeattleDerek Read May 22, 2013 at 6:04 pm
Reply to: Strange Behavior Editing ja-JP DITA with XMetaLMay 22, 2013 at 6:04 pm
Your screenshot shows an IME in action, not sure which one you are using but if you aren't sure then it is probably the one that comes with Windows 7. I assume you see either a “Language Bar” floating somewhere on your screen or docked in the Windows taskbar that lets you switch from Japanese to English input (assuming you don't do everything in Japanese).
In some cases the characters you are typing will appear as hirigana (or letters, numbers, or punctuation depending on the current IME settings you have set in the Windows “Language Bar”) but in other cases when you type hirigana several hirigana characters may be replaced by one or more single kanji characters (depending on the word — see your screen shot and you will see a lot of kanji characters that I assume were entered using the IME). While things are buffered you can usually back up and change characters if a particular conversion looks weird, or depending on the IME and settings and what you have typed you might also be offered a list of similar Japanese words to choose from. The space or enter key is usually the trigger to finalize the insertion of the characters into the application.
From your screenshot it looks like it is functioning as supported in XMetaL Author 6.0. I think if you compare our 6.0 release to using the IME other software you might think it is different because it appears to float nearby (as in your screenshot) instead of in the direct context of where the characters will be inserted, and the rest of the document does not flow around it.
If you can upgrade to 7.0 or 8.0 the IME “buffer” should be positioned at the location where the content will ultimately be inserted (making it appear more like you are typing directly into the document). Essentially these versions support IMEs better by communicating more information about what's going on and XMetaL is also able to find out what the IME dimensions are so it can flow the rest of the document around it. You still need to press space or enter for the characters to really be inserted into the document but that's how the Japanese IME works.
Microsoft info about the Japanese IME in Windows 7 (starting page): http://windows.microsoft.com/en-US/windows7/Type-in-Chinese-Japanese-and-other-character-based-languages
Microsoft info about the Language Bar in Windows 7: http://windows.microsoft.com/en-US/windows7/The-Language-bar-overviewDerek Read May 22, 2013 at 7:00 pm
Reply to: Strange Behavior Editing ja-JP DITA with XMetaLMay 22, 2013 at 7:00 pm
I've just tested with 7.0 and I don't see an improvement over 6.0. There is still an overlap with the “buffer” essentially floating near the text entry position.
I recall what we improved now. In versions prior to 6.0 it wasn't this good. In those versions the “buffer” was pinned to the top left corner of the document by default (but could be manually positioned by dragging with the mouse). The improvement we made was to tell it to draw itself near the position of the insertion (the place you are typing).
So for now this is as good as it gets. I'm not sure how hard it will be to improve upon this but I will ask our developers to look into the Windows IME specs to see if it is possible and that implementing something won't cause other problems (like slowing down typing).
- You must be logged in to reply to this topic.