by Michael S. Kaplan, published on 2008/02/24 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/24/7876678.aspx
Last week, over on the Volt Users Community, azhary asked:
Hi every one,
We are designing a meroetic font ( not supported yet by Unicode). The letters (about 25 letters) should display from right to left (rtl). At the same time they are isolated (not cursive).
We have used Coreldraw to create the outlines of the font.
The questions I have:
-- How to use Volt (or otherwise) to make it an rtl font?
-- What Unicode range should we use?
Thanks.
John Hudson swooped in to provide a solid, immediate answer:
This is a difficult situation, because normally one should avoid using defined Unicode ranges for things other than what they are, and you should avoid using reserved Unicode codepoints. The Private Use Area of Unicode is available, but it has the limitation that all PUA codepoints have a presumed left-to-right direction (directionality is a character property, not something that you set in the font).
If your goal is simply to be facilitate Meroetic text entry and display, while awaiting an eventual Unicode encoding of this script (or even as part of the process of getting the script standardised), then I think you could make use of codepoints for a script with similar features. From your description of the script, the closest match is probably Hebrew.
And Lorna Priest pointed out some important additional information:
John's reply brings up the issue that with OpenType you are not able to assign right-to-left behavior for PUA characters. However, you can be perfectly Unicode compliant (ie using PUA codepoints) and use the Graphite Description Language (http://scripts.sil.org/RenderingGraphite) which allows you to indicate RTL behavior in the PUA area. The main problem with Graphite is that there aren't a lot of applications that can use it. So, it kind of depends on what your purpose is. There is a version of OpenOffice that uses Graphite. There's a TeX publishing system (XeTeX) that use Graphite.
This truly is a limitation in both OpenType and rendering in general on Microsoft-provided text rendering platforms (by which I principally mean Uniscribe, because even though WPF exposes the most features in easily accessible ways like optional ligatures and such, Uniscribe still provides the most support overall, including support for those features WPF exposes).
I find myself torn in situations like this, especially since I have spent so much time assisting with tools with significant components involving "do whatever the hell you want rather than what Microsoft specifically provides itself" like
and so on. Fonts are some of the most customizable items on the platform, in some ways -- but limitations involving the frameworks surrounding fonts are, while perhaps less common or even uncommon edge cases, the hardest limitations to overcome without either violating rules within Unicode, or using someone else's platform and technologies.
I am able to console myself a bit with the fact that these are not only edge cases but also temporary ones since the obvious intent in the bulk of these cases is to work with scripts that will eventually be in Unicode (like Meroitic, currently on the roadmap for the Supplemental Multilingual Plane).
But on the other hand, the fact that there are many ancient scripts on their way in like Carian and Lydian that Microsoft has not necessarily been quick to support but which need right-to-left character processing semantics in some or even most cases. the fact the behavior cannot be overridden/customized either in Win32's GetStringTypeW or in Uniscribe's own internal tables. If this is not changed in the future then whether languages that do not have modern use but which do have special processing needs may not be best served by Microsoft-provided solutions, an issue likely to become more obvious as more and more of the ancient script proposals become ancient script Unicode subranges....
And then I wonder whether (as Microsoft did with Adobe's Type 1 fonts) whether support for other technologies should become part of the platform as well, though obviously doing so in a way that lets components like Office that use Uniscribe get their work done would have some truly significant challenges -- it would probably be easier on the whole to open up for customization the data and shaping engines of Uniscribe and the character data of Win32.
One could say that is the principal limitation of some of the platforms Microsoft provides -- those with requirements that are not part of the strategic investments of the platform find themselves much less ably supported....
This blog brought to you by 𐤎 (U+1090e, PHOENICIAN LETTER SEMK)
# Erzengel on 26 Feb 2008 2:48 AM:
Isn't there a particularly unusual ancient language that is neither LTR or RTL? Rongorongo, for example, which flips over and goes the other way each line. And of course you have 日本語 and other asian languages, which ought to be top-to-bottom, right-to-left, rather the left-to-right, top-to-bottom.
Granted trying to think about how you would make these languages work together, from both a programmatic standpoint and a reading standpoint, makes my head hurt...
One that I've toyed with is what about completely artificial languages? I have one that writes more or less like rongorongo, but I can only write it in a program specifically written to write it, then export it as a bitmap. Weren't there proposals to put Klingon into the Unicode standard?
# Mikkin on 26 Feb 2008 6:16 PM:
How would you handle a language that is neither LTR, RTL, top down, or otherwise, but works by gestalt?
Silly question, but I mention it because I want to recommend Stories of Your Life and Others by Ted Chiang (ISBN-10: 0765304198, ISBN-13: 978-0765304193). The title story features a language with just such a script. If you haven't seen it, I judge you would find it interesting. (Nothing technical here, feel free to just move along....)
# Michael S. Kaplan on 26 Feb 2008 7:45 PM:
I don't think there would be specific directionality rules that would apply here, right? Though I doubt Windows would support logical layout for an illogical language anyway. :-)