WSTech: Writing Systems Technology (formerly known as NRSI)
NRSI Update #9 – May 1998
Welcome to Issue #9 of the NRSI Update!
In this issue:
WinRend: Development Report
by Bob Hallissy
This is a longer-than-usual WinRend Update, made possible by the adaptation of a longer report given to the NRSI Field Advisory board meeting last month. Topics covered herein are:
The NRSI originally hoped to have a prototype of WinRend running by CTC 1998. Unfortunately, we were unable to staff the project at all until October 1997, and even at that the staffing has been minimal. Additionally, the project has been much more complex than anticipated. This complexity stems from two areas, the first of which is simply the complexity of the problem. The second is the changing landscape, both internal to SIL (Santa Fe, LSB, etc.) and externally (Rhapsody/Yellowbox, OpenType, Java 2D). As a result of these factors, it is not clear what we will be able to show by CTC.
Nevertheless, we are making progress and we are working closely with the Santa Fe and Cellar II project teams to ensure that their products are designed from the ground up with non-Roman issues in mind. WinRend is seen as a critical component for Santa Fe.
We were privileged to have Martin Hosken join the team from November through January. His energy and enthusiasm helped us all make progress.
Wes Cleveland and Joel Lee continue as part-time staff, working 20 hours a week each. I maintain other responsibilities within IPub and am able to work about half time on the project.
When Margaret Swauger took another assignment in February, I was asked to take over management of project.
Just this week, Alan Ward has been added to the WinRend team. He has some other ongoing development responsibilities so we won’t have him all to ourselves, but we are excited to his help and look forward to his contributions.
At this time, therefore, we have 2 FTE, including the project manager.
Research Results Review
Windows Codepages and Unicode
Martin Hosken’s research shows that due to limitations in the Windows operating system and the way Office applications work, it is not feasible to create and utilize our own code pages in Office apps. There is therefore no significant benefit to utilizing the codepage mechanism for WinRend implementation. Unicode research is still incomplete, and on hold due to the priorities of other items.
Wes Cleveland (and John Thomson) delved into the documentation on Rhapsody. If it is successful, YB could provide a dream platform: cross platform compatibility and sophisticated NR facilities built in. However, due to questions about the probability of success and the future of Apple, Academic Computing does not feel that this platform strategy is stable enough yet to utilize for SIL application development. Similarly, the WinRend team believes that SIL has been caught too often waiting for vaporous NR facilities, and we should go ahead and do what we can with the OS we have. If YB is successful, it will supersede and replace parts of the WinRend product.
OpenType Layout (formerly TrueType Open)
Since the OpenType Layout (OTL) article in NRSI Update #8, we have realized that Microsoft’s OTL technology has some severe limitations that essentially make it unusable for our needs: OTL does not support glyph reordering (such as needed by Indic scripts) or sufficient capability for class-based glyph substitution. Additionally, the long-forecast OTL Services Library has still not been released even in Beta to Windows developers.
Apple GX and World Script
The GX technology has in many ways “set the bar” for WinRend. As we consider the various problems related to display of complex NR scripts, we find ourselves asking “How does GX handle this?” and “Does WinRend need to do this the same way as GX?” We are grateful to Jonathan Kew and Victor Gaultney for providing consulting in this area.
We have a vision that someday we will have a single way of describing writing system behavior that will “compile” for use on either Windows or Macintosh platforms. As such, we have tried to keep GX capability in mind when developing WinRend script definition, although due to some constraints in GX we are not completely sure that what we have done to date does in fact meet this vision.
Occasionally we hear of some technology that promises to provide GX-class capability on Windows. Java-2D, which is in development at Sun, is the latest such. We have looked briefly at the documentation, and John Thomson has attended a Java conference at Sun. John sees good potential in this one, and recommends that SIL get involved in the effort. Ongoing improvements in Java performance, combined with the hope of sophisticated NR ability, make Java a promising technology. This could obviate a portion of the WinRend effort in that Java 2D would handle the actual rendering of NR script. However, there will still be the need for a tool that allows the field worker to express script behavior in a high level language and then to build a GX font that implements the behavior.
Phoenix, Cellar II, and Santa Fe
The restructuring of software development within International Administration has had a major impact on the WinRend project. As the Cellar II and Santa Fe projects have evolved from their predecessors, members of the WinRend team have participated in significant ways in the development of various requirements and design documents. Academic Computing has driven the process, and seems determined that everything will designed from the ground up with non-Roman needs addressed. The requirements and design documents for String, Encoding, and Rendering have been a cooperative effort between the WinRend team and Academic Computing, with input as occasion permitted from Alan Buseman and Timm Erickson.
Of primary interest to WinRend is the Rendering design. A design document, authored by John Thomson, is currently in its second revision with more to come. The intent is to create an architecture that allows for different kinds of rendering systems to be utilized. For example, simple scripts can be displayed using the built-in operating system capabilities, cursive scripts might be displayed using SDF, and other complex scripts would use WinRend.
Writing System Description language
While he worked with us in Dallas, Martin Hosken proposed a formal language to be used to describe and specify the transformations that are needed to go from an underlying data encoding to the surface glyph stream. Some of the syntax details are still in flux, but herewith is a summary of the basic ideas.
Technology Independent — One desire was to provide a language that was not based or dependent on a specific smart-font technology, and something that could outlive changes in such technologies. Thus we wanted a relatively high level language rather than one based on, for example, Apple’s GX or Microsoft’s OTL fonts.
Rule-based — It may be that the most efficient transformation engine is a Finite State Machine (FSM) such as, for example, GX uses. However, direct implementation of FSMs is complex, and requires a programmer for each script. Since we believe that WinRend technology should be configurable in the field, direct FSM manipulation is out of the question.
Conversely, our field workers are quite comfortable with transformations based on “pattern > replacement” rules. Our linguists use such rules in phonology, and our computer support people use such rules in programming Consistent Changes or Keyman/SILKey keyboard files.
We have therefore chosen a rule-based syntax for the expression of writing system behavior. When these rules are “compiled” for use by the renderer, FSMs will be used to efficiently match the patterns.
Class based — In order to simplify the writing of rules, the pattern and replacement parts of a rule can refer to individual glyphs and/or to collections of glyphs, called classes. This is equivalent to the Any() and Index() features of KeyMan or CC.
Multi-pass — It is often helpful to be able to break up a complex transformation into a sequence of simple ones. WinRend supports this by allowing the rules to be grouped into an ordered set of passes. Conceptually, a string being rendered is processed completely by the rules in the first pass, and then the result of that is processed by the rules in the second pass, etc.
Optional “features” — One of the nice things about GX fonts is the ability that the script engineer has to add features, or user-selectable optional behavior, to the font. These features can be enumerated to the application and thus be presented to the user as text attributes similar to Bold or Italic. To effect this, a WinRend description can define features and then enable or disable specific rules or complete passes based on the setting(s) of the feature(s).
Cursor tracking — Probably the most difficult problem with which we have struggled is cursor tracking. By this is meant the ability of the system to convert a screen coordinate to a position in the underlying stored text and the converse (converting a position in the underlying text to a screen coordinate). There are related problems such as highlighting a block of text, and of deciding what to do when the user presses an arrow or editing key such as Delete. Cursor tracking is relatively easy in linear scripts like roman-based systems, but is significantly more complicated in the presence of glyph insertion, deletion, and reordering, or in a mixed-direction script.
This problem is compounded by the fact that different scripts, and even different languages using the same script, may need different cursor tracking behavior. The correct behavior is partly an emic concern. For example, one language may want to treat a base glyph and its diacritic as a single character, while another may wish to treat the same base character and diacritic as two separate characters, each individually selectable & editable. Cursor tracking behavior for these two should be different.
Solving the cursor tracking problem is a cooperative effort between WinRend, the script definition author, and the application that uses WinRend, and is a major component of the project.
Guidance from Field Advisory Board
At the recent meeting of the NRSI Field Advisory Board, we asked for additional guidance in some specific areas. Discussions were prefaced by the realization that the short-term answer (i.e., for the first version of WinRend) might be different than the long-term answer (what we would eventually like to have). Clearly, if we can implement more than the minimum without significant schedule impact we will certainly do so.
Who is the WinRend client?
We originally interpreted the WinRend mandate to mean our primary clients were LinguaLinks and Shoebox. The slow progress of the project, in combination with the birth of the Santa Fe project, causes us to reconsider the question. Certainly Santa Fe is one, and in fact, probably the major, client for WinRend. But are there others? Do we need, for example, to provide a solution that integrates into current or near-term Shoebox efforts? What about entrepreneurial field-based development projects (perhaps written in VB)?
Advisory Board: For version 1, Santa Fe should be the primary client. At the time WinRend is ready, it may be that there will be a version of ShoeBox that utilizes Santa Fe rendering components, so this meets a significant need. Additionally, however, the Advisory Board expressed a felt need for the ability to access WinRend functionality from Microsoft Office applications, and this should be considered if it can be done with minimal cost.
What is the target platform?
The name of the project implies a single platform target. But is that reasonable in light of current desire (though with an unknown path to achieve it) that Santa Fe be cross platform? If WinRend is Windows only, we are not assisting in the cross-platform goal.
Advisory Board: Version 1 should be Windows only. When a viable cross-platform strategy is identified by the Santa Fe developers, consider adopting it for subsequent versions.
What Simplifying Assumptions can we make?
One way to speed up any project is to simplify the requirements. As the WinRend project has progressed, we often find ourselves asking whether certain capabilities are required or simply desirable, and whether we can make certain assumptions in order to simplify the problem domain. Here are some questions we have wrestled with.
Based on our interpretation of the WinRend mandate, we concluded that writing system behaviors that were not essential to a script, but which were for typographic finesse, could be given low priority. This philosophy assumes that WinRend will not be used as a publishing tool, and leads to giving low priority to features like kerning, line-initial and line-final contextual forms, justification, and complex hyphenation behaviors. Given that there is a Needs Statement in the project registry for a DTP application for the Santa Fe Suite, can we continue to ignore DTP requirements?
Advisory Board: Sooner is better than later. Version 1 should continue to ignore finesse issues, but the design should not prohibit the development of a more sophisticated DTP-capable implementation in the future.
Limiting scope of contextual forms and reordering?
We know that for some writing systems, the contents of one “word” (however that is defined) can affect the way a subsequent word is displayed. For example, Tai Dam has sweeping glyphs that sometimes collide with each other across word boundaries. Is it necessary that WinRend be able to handle contextual changes or other behaviors that span multiple words, or is it acceptable that such cases require manual intervention (such as the user enabling a character attribute that selects an alternate glyph or spacing)? If we can make this simplifying assumption, then the various operations needed to display or edit long strings on multiple lines of a window are considerably simplified.
Advisory Board: It is acceptable for version 1 to restrict contextual changes to operate only within words as long as a feature mechanism is available by which to implement manually controlled alternate glyph selection.
Simple hyphenation behavior?
Admittedly, we do not have a good understanding of the complete set of display behaviors that occur with hyphenation. We know that in some archaic forms, hyphenation is marked on the continuation line, either instead of or in addition to, marks on the first line. We also know that in some languages (e.g., German), the spelling of words can change if they are hyphenated. How much capability do we need to provide? For example, do we need to allow contextual forms and/or reordering around hyphenation points?
Advisory Board: Version 1 doesn’t have to implement sophisticated hyphenation behavior, but the design should not prohibit such in the future.
Irem:n the NRSI Three-Year Plan for FY1998-FY2000, the following goal was proposed in response to needs expressed by Mainland Southeast Asia Group (MSEAG):
Recent Developments in Unicode Proposals for Burmese and Khmer
by Peter Constable
There have been recent developments within the Unicode community to include Burmese and Khmer in the encoding standard.
In January of 1997, a draft proposal by Michael Everson was published for Burmese (ISO document JTC1/SC2/WG2 N1523). In December 1997, a revised proposal was prepared by Lee Collins of Apple Computer, which was based on comments from experts at the Myanmar Language Commission.
Early this year, after other proposals had been made by various parties, a proposal by Maurice Bauhahn for Khmer was accepted as a draft amendment to the ISO 10646 standard. (Maurice worked for 14 years in Cambodia and is currently studying at Grand Valley State University in Allendale, Michigan.)
In recent weeks, further work has been underway by WG2 (the ISO body responsible for the 10646 standard) on Burmese and Khmer. I have seen the most recent draft, dated March 17, 1998 (ISO document JTC1/SC2/WG2 N1729, not yet publicly available), and things are clearly moving forward.
I expect it will yet be some time before we see finalized standards for Burmese and Khmer included in Unicode and ISO 10646, but there are good indications that things are moving in that direction.
See also: Bob Hallissy’s Unicode Update in this issue.
by Bob Hallissy
Unicode 2.1 is now officially published and available as Unicode Technical Report #8.
Note: If you are interested in keeping up with changes in the Unicode standard, the Unicode Consortium supports two e-mail distribution lists open to the public:
All requests regarding subscription to these mail lists should go to , and should specify which mail list to be added to or removed from. For example, the body of your message should contain either:
subscribe <your_email_address> Unicode
subscribe <your_email_address> news
Of course, you want to substitute your own e-mail address for <your_email_address>.
All official news is posted to unicode as well as news, so if you subscribe to unicode, you don’t need to subscribe to news. If you only want to receive official information and announcements, subscribe to news only. Subscription requests are processed by hand, so they require some time to take effect.
Here is an excerpt from Unicode Technical Report #8 that documents Unicode Version 2.1:
Version 2.1 of the Unicode Standard brings together two additions to the repertoire which are expected to be in wide use in a number of implementations, errata collected since the publication of Version 2.0, and a number of updates to the character properties database. The two newly added characters are the U+FFFC OBJECT REPLACEMENT CHARACTER and the U+20AC EURO SIGN. The object replacement character is already employed in multiple implementations, and the euro sign is expected to be widely used very soon as the European Monetary Union (EMU) proceeds to phase in its use as the EMU unit of currency. This modification of the Unicode Standard is made available so that implementers can proceed with their support plans knowing that their implementation of Unicode is a well-defined, conforming version. With the additions of Version 2.1, the Unicode Standard contains 38,887 characters from the world’s scripts.
Contents of Version 2.1
Additional characters and scripts have been accepted into the Unicode Standard since the publication of The Unicode Standard, Version 2.0. These are not included in Version 2.1 but are documented on the Unicode Web site at http://www.unicode.org/unicode/alloc/Pipeline.html.
Type Design Training Directions
by Victor Gaultney
In the last year the type design resources of the NRSI have been reduced by half, while the needs are growing. In addition, more computer specialists are using type design tools (such as Fontographer) to meet the needs of the linguists they support. Our hope is to make it more possible to meet type design needs — whether simple or complex.
We are planning to formalize our existing type designer training into a Type Design Apprenticeship program. This training/mentoring experience would be for new or current personnel who could serve in a primarily type design role either in the NRSI or a field location. We are looking for people who have the right mix of gifts and talents to help meet this enormous need. We already have one apprentice identified and scheduled to work with us the first few months of 1999.
We would also like to make more type design information available to the broader range of computer specialists. The plans are to continue current avenues of support (NRSI Update articles, informal assistance, sessions at meetings such as CTC), but we need to know what information is most useful. Please let us know about your needs with regard to type design issues. What parts of your work require type design expertise? What kind of training do you need the most? What is the best avenue for that training? How can the NRSI make you more successful in handling the type design issues faced by the linguists/translators in your entity?
We recognize that SIL’s type design needs are complex and growing, and hope that with some increased planning and effort we can better meet those needs.
Hinting Research Report: Strategies, Techniques and Tools
by Victor Gaultney
This report has been revised since it was presented to our Field Advisory Board meeting on April 28, 1998.
Despite the proliferation of higher resolution laser printers, the display and printing of text at normal text sizes but at low resolutions (less than 600 dpi or on screen) is important to our script development efforts. On-screen legibility, in particular, should be a goal of our projects.
There are two ways of ensuring that on-screen text is legible: bitmaps and hinting. Traditionally, we have designed bitmap fonts for those projects where we had both the tools and personnel necessary. This can be a very time consuming task, though, and the wider range of screen resolutions in use makes it less likely that the sizes we design will match the user’s desired text size. Bitmaps remain, however, the simplest way to assure that text is readable on-screen.
Hinting involves placing “instructions” or “hints” in the font file itself that signal the font renderer to move certain points to make low resolution text more consistent and legible. Whereas bitmaps are designed for specific point sizes, hinting can improve display at all point sizes (although tweaking for individual point sizes is also possible). In addition, bitmap fonts that contain a large number of glyphs that differ only in position (such as the Nastaliq or Tai Dam) require that bitmaps be designed manually for each variant, while outline hinting need only done once for each basic glyph shape.
Strategies, Techniques & Tools There are basically three hinting strategies that we have used in past IPub/NRSI projects and two more that we are considering for future projects. Additional techniques and tools are available (such as having a commercial company hint our fonts for us), but each has significant drawbacks that make them impractical.
Automatic Hinting with Fontographer Fontographer — our main font design tool — has had automatic hinting capabilities for many years, and they have been used in IPub/NRSI projects since 1992. The idea behind autohinting is that the basic parameters of a font can be determined by analyzing the widths and shapes of specific strokes for certain preset glyphs. With that knowledge, Fontographer can then build instructions into the font to assure that all similar strokes have the same width when displayed.
For example, Fontographer measures the widths of the vertical “stems” in glyphs such as “l”, “h”, “n” and “m”. It then adds “hints” to the font so that at lower resolutions each of the stems has the same width even though the widths might actually be different in the design. The font designer may want them to be different at higher resolutions. Most hinting algorithms, however, are much more complex and have resulted in a long list of patents for their inventors.
The main advantage of this technique is that the font designer does not have to know anything about hinting other than how to turn autohinting on. The main disadvantage is that the autohinting algorithms often make poor choices, particularly for non-Roman fonts. The nature of most autohinting assumes that certain glyphs have certain features that should be compared with, and adjusted to match, certain features of other glyphs. When the glyphs are non-Roman or otherwise different from standard roman fonts, the algorithms cannot make good guesses as to what should be done.
The SIL Encore Fonts were hinted primarily with Fontographer’s autohinting feature, and the result, though not nearly as legible as we’d like, is far better than if no hints were added at all.
Manual Hinting with Fontographer Fontographer also allows the font designer to have some limited control of hints, even after autohinting has been applied. Some of the general font parameters can be manually set, and certain hints can be adjusted, added or deleted for individual glyphs. We have used this feature successfully to fix glaring, terrible errors in font display, both in the Encore Fonts and in non-roman projects such as Vai. Nevertheless, there are some fonts (for Nastaliq and possibly other calligraphic scripts) for which Fontographer’s hinting (even with manual adjustments) causes glyph shapes to be changed in an unacceptable manner that cannot be controlled by the designer.
Although certain fonts can be improved with Fontographer’s manual hinting adjustments, it is not a very comprehensive tool. Only a limited subset of possible hints is allowed and control over font-wide settings is greatly restricted. It is, however, a nice feature to have if other more powerful tools or techniques are not available or practical.
RoyalT - Assembly Language Hinting The TrueType font hinting system is actually a procedural programming language in itself, so it is possible to write specific hinting “programs” by hand. RoyalT is a tool from Apple that provides the font programmer access to the hinting instructions (programs) within a font. The programmer can then modify or replace individual instructions or change global font parameters. In this way the full power of hinting can be realized. Although RoyalT hinted fonts can work on both Macintosh and Windows, the program runs only on the Macintosh.
One difference from the Fontographer methods is that this hinting is added to the font after the font design and generation is complete. It is a strictly “post-production” technique, so if there are changes made to the font (new or modified glyphs), the hints must be reentered by hand.
The main drawback to this technique is that it is akin to assembly language programming, with some cryptic commands and procedures. Despite this, Jonathan Kew has used this strategy to manually hint the Nastaliq font with wonderful success. It was, however, a very time consuming and complex process, and one that only an expert in font technologies and programming could attempt.
Visual TrueType - A Combination of Power and Ease In October 1997, Bob Hallissy and Peter Martin traveled to Microsoft in Redmond, WA, to be briefed on OpenType and Visual TrueType (VTT). VTT is a graphical tool that provides access to the full power of TrueType hinting, but with a graphical interface that automatically displays the effect of hinting changes. Like RoyalT, it is a post-production tool and requires a significant understanding of hinting to use. VTT is available for both Macintosh and Windows, although the Macintosh version is usually the first to incorporate new features.
We have had only very limited experience using VTT. Bob and Peter worked with it in Redmond and Jonathan Kew has experimented a bit with it. The interface is somewhat clumsy and unpleasant, but the graphical interface does make it much more practical as a possible tool for our use. We have not yet used it for an actual project but are continuing our research.
FontLab Another option for hinting is FontLab, a font development tool that is generally comparable to Fontographer, but without the long history and large user base. Version 3 now adds the ability to edit TrueType curves directly and add manual hints - at a level somewhat between Fontographer and VTT. It can also do limited autohinting, although the quality has yet to be assessed. FontLab is only available for Windows, but resulting fonts can also be used on the Macintosh. We hope to be testing it with a real project sometime soon.
Summary Assuring on-screen legibility is important, and advanced hinting techniques seem to hold the most hope for accomplishing this. Bitmaps are still an option, but growing less and less so. Fontographer’s hinting can be very useful when used, but is limited in scope and best suited for roman scripts. There are even font styles and scripts where hinting may not be appropriate or helpful.
Of the remaining techniques for advanced hinting, Visual TrueType looks to be the most promising. It provides the depth of control we need, yet provides an easier graphical interface. FontLab may also be useful for certain projects.
The main roadblock in incorporating advanced hinting into our font development projects is not a lack of tools, but a lack of skilled personnel who could commit to becoming SIL’s “hinting experts”. It would require a significant time commitment to both be educated in the art of hinting and to apply that skill to our projects.
Nevertheless, we do hope to incorporate advanced hinting into some of our projects, assessing the need on a project-by-project basis and balancing that with the personnel resources available.
Symposium on Literacy and Writing Systems in Asia
by Peter Constable
On May 1 and 2, I attended this conference held at the University of Illinois at Urbana-Champaign. The conference was sponsored by the Center for Advanced Study at UIUC in conjunction with various departments at UIUC and also with the International Society for Korean Studies, Osaka, and the Institute of Language and Information, Korea University, Seoul. This conference was held in commemoration of the 600th anniversary of the birth of King Sejong, the 15th century king of Korea who oversaw the development of the Korean Hangul alphabet.
Thirteen presentations were given over the two days by invited speakers. Most of the papers focused on literacy and/or development, though several presentations gave considerable attention to writing systems, and writing systems were the entire focus of three presentations. In terms of regions, presentations were given that pertained to Korea, Japan, Micronesia, the Pacific (Micronesia, Melanesia and Polynesia), Indonesia and Malaysia, the Philippines, and India.
I found the following presentations to be of greatest interest:
I found it especially valuable to have the opportunity to meet William Bright and Peter Daniels, the co-editors of The World’s Writing Systems (published in 1996 by Oxford University Press). Both of them are keenly interested in writing systems and command a lot of knowledge about writing systems. Both appeared to be glad to meet someone from the NRSI, and both expressed interest in maintaining contact.
Mention was made during the conference of the possibility of producing a proceedings volume, though it was not clear to me whether that would happen or not. I have a copy of Bright’s complete article, which I can share with others who are interested. Kim-Renaud has recently published a volume on Korean orthography, and I can provide bibliographic information for any who are interested.
While I would have been interested in seeing more attention given to writing systems and orthographic issues, this meeting was considered quite successful by all attendees. I hope to see other such meetings in the future.
My Hong Kong Airport Experience
by Peter Constable
For something on the lighter side, we thought you might enjoy this account of flying into Hong Kong which I wrote a couple of days after that singular event in my life:
My trip to Chiang Mai was full of dubious highlights, the most memorable of which was landing in Hong Kong. There was a lot of turbulence as we made our approach, which included a bonus tour of living rooms of apartments next to the airport. Seriously. One of the approaches into HK requires a turn of some 50 degrees about a half mile from the end of the runway. As the plane banked, we were maybe 500 feet off the ground and I was literally looking straight out into windows of a complex of 4? story apartments that were about 150 yards away. (Cheap rent, but insurance premiums are off the scale.) Really, I’m not making this up. Never having experienced this approach to HK (I’m told it’s very much routine), I was seriously questioning what on earth was going on. Then, just as the plane leveled out, the pilot increased the thrust dramatically. By this time, I was convinced that we were either not in line with the runway or else were so low that we would touch down before the runway, and I came to the conclusion that the pilot was going to abort the landing. (I wasn’t so sure I wanted a second tour of those apartments.) But, no, this was all according to plan, all included in the price of admission, and the landing proceeded. When we hit (“touched down” simply is not a fitting description), we had so much momentum sideways that I was really surprised the landing gear had not collapsed.
They must pay those pilots a lot of money. I certainly wouldn’t ever want to navigate such a beast as a 747 through an apartment-complex slalom course like that. I guess some fighter pilots don’t die, they just go work for airlines based in HK.
By the way, a completely new HK airport located well outside the city is scheduled to open later this year. (Better snatch up one of those apartments while the rent is still cheap!) If you want the unique experience of landing at the current HK airport, then you’d better plan your trip soon. If you like excitement, I recommend it highly: it’s so counter to what you’d think they’re permitted to do that it’s got a certain touch of surrealism to it. [Ed: too late!]
Circulation & Distribution Information
The purpose of this periodic e-mailing is to keep you in the picture about current NRSI research, development and application activities.