TRON Association Secretariat (hereafter Secretariat): This year we are welcoming in the 14th year since the TRON Project was launched. Your company has been involved with TRON from early on; could you tell us about that?
Mr. Matsui (hereafter Matsui): The reason our company (Personal Media) became involved in TRON, in particular the BTRON subproject, was because first of all we were fascinated by the technical aspects.
Our company is a software maker that was established in 1980. In the first half of the 1980s, the development and marketing of package software for business use, such as the card-type database software of the "Airisu " series, formed the pillar of our business. The original Airisu was written with BASIC from the PC-8001 to the PC-9800 series [of NEC Corp.]. Afterward, it was ported to C language and [Microsoft Corp.'s] MS-DOS, and it became possible to run on other personal computers. In addition, about 1985, we also carried out multiple windowing within the Airisu application.
On the other hand, at about this time, together with the marketing of Airisu, we began marketing word processing software, scheduling software, and the like. Among the engineers at our company, a debate was raging over what kind of operation specification we should draw up for end users to skillfully combine and command these software applications--if we use the current term, I think we would say "seamlessly." This was also exactly about the time the first Macintosh was put on sale (1984), and I 'm certain the influence of this was also felt.
Although the performance of personal computers at that time was, of course, poor by far compared to today, there was little dissatisfaction about calculation and other basic functions, and it was recognized that improving the quality of data to be handled and improving ease of use will probably be items for future improvement. Concerning "quality of data," I believe the first half of the 1980s was roughly when personal computer printer output began to change from katakana to kanji (Chinese characters), and it was an age in which there were arguments, such as whether or not the JIS level 2 [character set] would fit into memory or on disk. Also, concerning "ease of use," in contrast to the IBM-PC put on sale at the beginning of the 1980s, which was loaded with the character-based MS-DOS, the Macintosh put on sale in 1984 was based on a Graphical User Interface (GUI) that used a mouse, and so it was roughly about the time the foundation was set for the present golden age of Windows.
The recognition that "quality of data" and "ease of use" are important hasn't changed even up to the present, which is more than 10 years later. At present, even among Personal Digital Assistants (PDAs), there is nothing into which JIS level 2 won't fit, but in the sense of making progress in creating multimedia, "quality of data" is as important as ever. Moreover, due to circumstances in which it is being recognized that in the end there is still great room for Windows 95--which was marketed by greatly propagandizing ease of use, ease of use--to improve in the area of "ease of use," these two themes may be eternal subjects in the world of personal computing.
In this manner, in our company we held the realization from early on that improving the "quality of data" and the "ease of use" would become the key to software development in the future, and we carried out a study for that purpose. One conceivable method was the method of adopting Microsoft Corporation's Windows, which was being announced from that time. If we think of this as an extension of MS-DOS that had been used up to that point, then it was the natural answer, but in the Windows of this period there were still many points about which the future wasn't clear, and there was anxiety as to when Microsoft would be able to put out a proper product. Actually, it has been since we entered the 1990s, since Windows 3.1 appeared, that Windows has become a major [operating system], so when looked at from that time, we are talking about five years or more earlier.
Another great element of anxiety was the anxiety of relying on a single enterprise in a foreign country for the most important part called the OS. Our company had developed various software on top of MS-DOS by that time. Although MS-DOS seems like it has been standardized, there are also many aspects of it that aren't. Specifically, there are functions that one cannot understand if one cannot view quite special documentation, so-called hidden functions and the like. There have been more than a few cases in which it has been impossible to develop a product if one doesn't use those hidden functions with specific models and statuses. I believe it wasn't a case in which there was originally ill intent at the development source, but it seems like the results of repeated Japanizations, bug fixes, expansions of the models on which to run it, and so on, led to fine version differences of the OS becoming complicated and impossible to manage, and that probably grew into hidden functions. Furthermore, because MS-DOS and Windows are imports from America, even if bugs were reported and requests for fixes were sent out, it was impossible to respond inside Japan or the response was late, and consequently there were more than a few cases of being ignored. On top of there being many hidden functions, support is incomplete. Moreover, because there was also the possibility that this could become a factor in political transactions, in other words since it could be used for maliciousness such as not informing a rival maker of the hidden functions, even from the technicians the opinion opposing adoption was strong, and so in the end we withdrew from Windows-related software development excluding software for special purposes. To put it simply, I suppose you could say we were reluctant to do technical development and business on the palm of the hand of a single enterprise overseas.
Incidentally, even though we are presently in the age of Windows, the problems of hidden functions are either only now being fixed or they are growing worse. I have heard that people developing Windows applications, in particular people developing software for layers close to the OS, such as an FEP [front end processor] or an IME [kana -to-kanji conversion input processor] are having an awful time.
The introduction has become very long, but from the realization that the "quality of data" and "ease of use" are important for future personal computer software, plus the realization that there are problems in utilizing the MS-DOS~Windows lineage, what the technicians in our company set their eyes on was the TRON Project.
The reasons for adopting TRON are exactly the inside of out of the above-mentioned problem points. It is none other than because of the advocacy of "standardization of data formats" and "standardization of the operation methods," plus the political idea of an "open architecture" that the TRON Project advocates throughout, conformed with what our company was looking for.
Well then, although the TRON Project was greatly welcomed like this by our company's technical staff, the journey up to the present wasn't level. Afterward, it seemed like the BTRON specification would be adopted as the standard specification of education computers the Center for Educational Computing (CEC) foundation was to decide, and there was a great boom. Major software houses, such as ASCII and Lotus, intended to develop a BTRON OS and applications; and in 1989, 22 software makers gathered together and created the "BTRON Independent Software Vendors Group." Since our company is rather old in the world of personal computer software, and because we endorsed the aim of the TRON Project based on the aforementioned reason, our company of course also participated in this association. I think the companies that were not doing TRON at that time were rare.
However, as you know, because TRON was raised as a candidate on the non-tariff barrier product list under the Super 301 section [of U.S. trade law] by America's USTR, it first came about that export centered enterprises, which felt anxiety, took their hands off of BTRON. Moreover, there was also the fact that this exactly overlapped with the period in which the bubble [economy] collapsed, and a mood a retrenchment drifted in the general public. Among the software houses concerned with BTRON, there were also some that were either bought out or that went bankrupt. Eventually, when we entered the first half of the 1990s, it came down to a situation in which Matsushita Communication Industrial Co., which was marketing a BTRON computer for educational use, and our company were the only makers involved in BTRON.
Having said that, there is no room for doubt that BTRON is a technically outstanding thing. Our company has made great efforts to spread BTRON by beginning the marketing in 1991 of "1B/note," which was the first BTRON personal computer marketed to the general public, and through the marketing of of such things as the "TK1" TRON-specification keyboard, which was put on sale in the same year, and the "1B/V1" series BTRON software package for use with DOS/V [IBM-PC/AT compatible] personal computers, which was put on sale in 1994.
After repeating version upgrades of the "1B/V1" series several times, we have arrived at the "1B/V3" series in the present. We have shipped a total of over 100,000 copies of BTRON up to now. Furthermore, next year we are planning to market "3B/V (tentative name)," which is the next generation BTRON [-specification operating system].
Secretariat: Your company is attempting to positively develop TRON beginning with the development of TRON-related products centering on BTRON. Please tell us about the circumstances of that involvement and the present state of affairs. Also, please tell us about your company's your future involvement, such as plans for future product development.
Matsui: Our company announced "3B/V (tentative name)," which is the next generation BTRON [-specification operating system], at TRONSHOW '97 at the end of last year. In addition, we are also developing "Genkoo purosessa " as one application to run on top of it. A big objective here for two or three years is to search out the new possibilities of BTRON through the sale and improvement of these products. "3B/V" is the next generation BTRON in which we carried out a great compilation and substantial strengthening of functions of the BTRON architecture that has passed through six years since sale to general public. Compared to the 1B/V3 series of the past, it has been strengthened to deal with high-resolution and full color graphics, an outline font function, a LAN function, and so on. Moreover, we have implemented a true multilingual function at the OS level that can 100,000 kanji plus multiple languages mixed together, and thus it is possible to handle from both the OS and all of the applications all the kanji in circulation in Japan without using user defined characters. There are things elsewhere in which multiple languages can be mixed inside special applications, such as editors and the like, but this 3B/V is the first product in the world that can handle 100,000 characters, which are in excess of 2 bytes, plus a multilingual environment with the OS and all the applications on top of it (word processor software, figure [graphics] editor software, spreadsheet, databases, communications, etc.).
While I also have the feeling that the TRON Project served as the instigator, it seems that only recently discussion about kanji that can be processed with computers has increased. It is a fact that there is much dissatisfaction with the kanji that can be processed with conventional computers. The kanji that can be used with a conventional OS are generally to the extent of the 6,355 characters of JIS levels 1 and 2. This range is sufficient for writing ordinary text, but when it comes to simple personal names, place names, technical terms, and so on, kanji not included in this range are not rare. For example, for the character "be " of [the Japanese family name] "Watanabe" (Table, Ex. A-1) used in family registers more than 30 variants exist, but in JIS only three character codes--cell 53 of row 42 (Table, Ex. A-2), cell 20 of row 78 (Ex. A-3), and cell 21 of row 78 (Ex. A-4)--are allotted for these alternate character forms, so it is impossible to distinguish and deal with 30 variant characters. In addition, other frequently mentioned examples are characters that cannot be expressed with JIS although there is a big demand for them with personal names, such as "yoshi " [of the Japanese family name Yoshida (Table, Ex. B-1)] in which the top part of "yoshi " is not "shi " (Table, Ex. B-4) but "do " (Table, Ex. B-3; the lower part is longer) and "taka " (Table, Ex. C-1) in which both sides of the "ku " (Table, Ex. C-2) of the upper part of "taka " (Table, Ex. C-3) protrude vertically. In a situation such as making out a savings passbook at a bank, changing the kanji a customer specified is similar to a rudeness, so it seems like the people in charge at banks are also suffering in regard to customers who have kanji names that cannot be handled with ordinary systems.
A portion of the kanji used in personal names and technical terms is included in JIS auxiliary kanji . Although there are also cases when we are saved by this, characters such as the ones given in these examples are not included there either, and both OSs and systems that can use auxiliary kanji are still not popular. Even if we use Unicode, Unicode is essentially a two-byte code, and because all the kanji of Chinese, Japan, and Korea are crammed in here, it is completely impossible to include all 100,000 kanji demanded inside Japan. In contrast to this, if we utilize the true multilingual function to be implemented in 3B/V, the limit on the number of kanji characters that can be used disappears. Including even the characters give in the above examples, it becomes possible to handle 100,000 characters, 1,000,000 characters, in fact an unlimited number of kanji .
The 3B/V merit of handling true multilingual [functions] and 100,000 kanji is something that considers such broad needs as those of administrative organs, banks, libraries, and humanities researchers who have suffered up to now with the kanji in personal and place names that are not included JIS, plus writers who are particular about kanji --it's an extremely unique function not in other OSs that we are proud of.
Another large-scale project related to BTRON is the development of "Genkoo purosessa ." This is something that is close to a so-called word processor, but it is software specialized to the last for manuscript writing, in other words text input functions, which pushes off to another application functions for neatly printing out documents, such as layout and the like.
The forte of "Genkoo purosessa " is that it places the main point on faithfully reproducing the original rules for expressing the Japanese language in writing. When one correctly writes Japanese on manuscript paper, there are rules such as a dash uses two boxes (Figure, [a]) of the manuscript paper, or that when the punctuation marks "period" and "quotation closed" occur in succession (Figure, [c]), they are inserted in one box; Genkoo purosessa is made up so that these rules are accurately reproduced, which makes it possible to carry out accurate representation in writing and calculation of the number of characters. Also, when mixing alphanumerics with vertically written Japanese (Figure, [d]), there is the (symbol handling) method in which one character is inserted per box as in vertical writing, and the (word handling) method in which the entire word is rotated sideways and written in without regard to number of box places on the manuscript paper. With Genkoo purosessa either of these can be realized.
In Genkoo purosessa, we adopted the form of displaying Japanese manuscript paper for either vertical or horizontal writing, and then filling in characters on top of that. This wasn't for the simplistic reason of matching the atmosphere of the appearance with Japanese manuscript paper, but rather it is something that reflects the opinions of authors who said they wanted to revive the rhythm of writing in which one writes text on page after page of Japanese manuscript paper. By managing and displaying the amount of writing in units of the number of pages and number of lines of manuscript paper, it is possible to visually grasp the status of progress. In electronic publishing form of late in which Web pages and electronic mail are used, writing as much as you want without any limit to the amount of text may be the norm, but with text that is to become printed matter in magazines and books, there are also many cases in which the amount of text that is to be written is is strictly decided in units of the number of pages of Japanese manuscript paper, and thus it is important to mange the amount of writing based on the metaphor of Japanese manuscript paper.
Another great feature of Genkoo purosessa is the correction function. When you run Genkoo purosessa in the correction mode, the revisions thereafter are performed in a form in which the original manuscript is preserved, thus making it possible to display very clearly the differences with the precorrection original. In the sense of understanding the parts to be revised, up to now handwriting has been overwhelmingly advantageous, and there has also been knowhow for correctly transmitting the contents of corrections from the author to the editor ("delete [toru ],"let it stand [iki ]," etc.). One could say that this Genkoo purosessa is something in which we have electronified without modification the advantages of handwriting plus the knowhow of the corrections [process]. In addition, Genkoo purosessa also possesses footnote and ruby functions.
However, the most important point of Genkoo purosessa is the point that it can use the 100,000 kanji supported by 3B/V, and that that will become the motive power for bringing forth colorful literary expressions. I believe porting Genkoo purosessa to another OS is also possible, but I think Genkoo purosessa is something that can show its true value just in combination with 3B/V, and that it's software that should become a killer application of 3B/V.
Secretariat: With your help, it has been possible for our association to greet in its 10th year. There have been various incidents from our founding up to today for us also at the association. What would you give as the thing that left the most lasting impression for your company during the last 10 years? Also, what is your company's appraisal of this association's activities?
Matsui: The TRON Association has attained its 10th anniversary. That the TRON Project was also able to grow up to here is, I think, thanks to the efforts of the association's staff. We are deeply thankful for this.
The thing that left the most lasting impression over these 10 years was probably the size of the reaction when we announced the first BTRON personal computer "1B/note" in the summer of 1991. At this time, not only trade journals, but also many general publications carried the story with picture inserts, and there were incessant inquiries by telephone. Although notebook personal computers at the time had compared to today a vastly different specification of an iAPX386, 4 megabytes of [main] memory, and a 20 megabyte hard disk, they were still rather high priced (400,000 yen), but with your help, they sold swiftly--I have a recollection that is overwhelmed at number of people and the thickness of the layer of people who were waiting for TRON to be put on sale. There were all sorts of people, from diplomats to Buddhist monks. Also, after the announcement, it was decided to hold a hurried BTRON symposium. We prepared demo software and a machine, which was to some avail. And then on the day of the symposium the hall on the fourth floor of TEPIA Hall was packed. Even at this point in time I fondly remember that there was an onslaught of questions from all the users.
In addition, this year of 1991 was also the year in which the notebook version of Macintosh was announced for the first time at the fall COMDEX [trade show]. Up to that point, there was no notebook personal computer that could use a multiple window system. 1B/note was the world's first, and on top of that it was a multiple window notebook personal computer that could use Japanese from the beginning. Incidentally, Windows 3.1 at around this time was something that had achieved a level of name recognition but was still only operating at the demo level, and the situation was that it would require another year or two to spread in earnest. To that I might add, running Windows with the notebook personal computers at that time, which had a small [main] memory and hard disk drive, was impossible. Looked at from [the point of view of] Windows, Windows was in a situation where it was necessary to wait for progress in hardware.
Secretariat: How does your company evaluate the TRON Project? In particular, we would appreciate it if you would explain in detail about BTRON in which you are actively involved. Also, please tell us about your wishes and expectations for the TRON Project in the future.
Matsui: I think the greatest attraction of the TRON Project is probably the point that software development engineers themselves take part in planning the design of specifications, and that they can apply knowhow from the time of specification design also to the development of products.
Simultaneously developing specifications and products is taken for granted in other industrial products. There is room for free competition there, and I think it is also a place where engineers can show their abilities. However, the world of software is not a world in which this taking things for granted is in circulation. In other words, it has become unrealistic in that a single maker creates a specification of its own pleasing by using the walls of an overly complex and large-scale system configuration plus "compatibility." If one doesn't think much of that and then moves ahead with a plan of joining up with Windows, which is the de facto standard in the world of personal computers, then there are the above-mentioned problems. Specifically, these are the technical problem that the kanji required in Japan cannot be accurately handled and problems concerning reliability, such hidden functions and instability of operation. Furthermore, there is no room in which we can fix these using our own strength, so after all there is the political anxiety in that one cannot but do business on the palm of the hand of another enterprise. Of course, there are also applications and uses through which it is possible to avoid these types of problems. Here, I am thinking about software that is highly general purpose, such as the OS.
In the end, in order for engineers to develop software products while displaying autonomy, there is no way other than for them to proceed with standardization by their own hand and product development simultaneously. I think the TRON Project is something that is extremely important as a place in which we can realize this.
Secretariat: Thank you for your valuable opinions today. We believe they will serve as a reference in advancing the association's activities in the future.
The above interview appeared in a special edition of Toron kyookai nyu--su [TRON Association News] published on March 13, 1998, to commemorate the 10th anniversary of the association's founding.
Copyright © 1998 TRON Association
Copyright © 1998 Sakamura Laboratory, University Museum, University of Tokyo