 Okay, thanks everyone for joining the session here. It's, I see a few Asian face, so I'm a bit nervous about talking about this topic, typesetting with Kanji, because of course, it's not my native way of writing and reading. Yeah, so what I want to report about today is, what's the current, well, first of all, about specialities of typesetting with Kanji. I excuse me and myself, I mean, I know I'm in Taiwan, where they use traditional Hansi. I come from Japan. I'm used to Japanese typesetting rules. I will mostly talk about Japanese typesetting rules. I will mention Chinese rules. There's one reason for this, if you check the W3C consortium rules, the Japanese, the rules for Japanese typesetting the most specific compared to the others. So they are most strict and very detailed. And also one reason is because there's the biggest mixture of writing systems. Okay, so typesetting with Kanji, I will talk about these peculiarities with typesetting with Kanji, and then about integration of, as a tech, as a Japanese, well, CJK typesetting into tech life, and how tech life, and then, well, that means also in Debian because tech life is as is in Debian. Yeah, just to introduce myself, my company's, I'm working on completely different things. It's a CDN network in CDN company in Tokyo, but I'm also tech life maintainer of tech life and since many years now, and since I moved to Japan nine years ago, I was a member of the Japanese tech development community trying to improve the experience for users of CJK languages. Okay, what's the layout for today? It's like, first, as I said, I will discuss specialities of Japanese typesetting, especially, I mean, this applies not only for Japanese, I will, excuse myself, as I said, I will speak mostly about this, but in the same way applies to other systems, especially with mixing different writing systems like Roman letters and non-Roman letters, and grid typesetting, something which is very important in this system. Then I will go through the history of the P-tech family, probably most of you, unless you are somehow a typesetting aficionado from Japan, you will have never heard about this, is a tech engine that was developed already more than 20 years ago by Japanese company and then independently just to support the specific requirements of Japanese typesetting, and it recently became integrated into tech life. And then I will report just quickly on about the current status, what can actually be done. So, okay, that's the ideal. If you have an idea about what this is, this is one of the example of first moving letters, moveable types, long before Gutenberg in China, set perfect aligned, nice, I mean, of course, perfect aligned, but this would be the ideal in setting kanji, this is possible because every different kanji has the same dimension, so they are all set on the same dimension, that means all the line lengths are the same, but lines here are typically vertically, this is something, yeah, and so it would be a very nice grid. Reality looks much different. If you look into a typical Japanese text, you have a mixture of three writing, three to four writing systems, spacing is definitely not on a grid. There are lots of reasons why this happens and we will discuss this here, so we here see running Latin text in there, we see spacing marks, we have spaces up here, we have, here we don't have hanging punctuation, but we'll see examples later. So, it's also what you see is that Japanese is like traditional Chinese is set in two directions, so it's some, it comes later anyway. So, what are the reasons for this, that doesn't really work, unalignedness here, the reasons are why these letters here, if you look at the same, the first letter is true, and but other letters, they are not like on a nice grid as we have seen before, so what are the reasons for all this while there are lots of them? One is that, well, we have different writing systems, nowadays at least as we in Japanese four are used permanently, they are punctuation system that haven't been in the old times, punctuation system changed layout completely, then there are special rules that we also have in Latin type setting, it's like widows and orphans, it's like, just that it applies not to words, but to single characters, well, and then different type of development like hanging punctuation indentation, so there are a lot of reasons. So in Japan what is happening is we have four writing styles, so the normal ideographic symbols, kanji or hanji here, my favorite kanji actually one of the first I learned, all the Japanese have to know it, it's standardized in six years, it's the depression, it means because if you have to learn to write it, you get depressed, actually it's one of my favorite. Anyway, then this hiragana which is nowadays used for grammatical variants, so the main words, the main set up of words, also of the text is kanji and grammatical variants I expressed or well, with hiragana, katakana is used for, mostly for foreign words, often for scientific expressions and then we have romaji, so roman letters just mixed into the text, so these are mixed, actually for those just a bit interested in the history, it was not always like this, so when I read old mathematical papers in Japanese, it's the other way around, so in old papers, katakana was used for the running text and hiragana for foreign words, which looks nowadays completely strange, but well, that's reality and it's funny to read and so it has changed considerably over time. So what I mentioned before, there is also typesetting directions, I think, I don't know, as a mainland China, I know that there's practically no vertical typesetting anymore besides advertisement in some places, what I've seen in Taiwan, there are a lot of books that still set vertically, so there are two typical ways of typesetting text, the one is like what we western people are used to with roman is just from left to right, top to bottom and a book would be just like a normal book, but this is not the only way, actually, there's vertical typesetting and in Japan, most of the novels or everything that is not related to technically is set vertically and also from right to left, so you start here and you write in this direction and also books start from, well, in this direction. This extends also to, if you're e-book readers or something, then also there, you just tap on the other side just to block, so that's, since that is very common in Japan, I don't know how far this is in Taiwan, I just know from several trips to mainland China that there was a, that there it is hardly used anymore. Okay, so you have seen already examples of mixing Latin letters into the text, so there are a lot of ways to do this, actually I think on the first day already someone asked me, so how do you do this? So there are a lot of ways, so one way is if there are like three letter or a few letters, then you just place them when they are vertically, well, if it's horizontally, then it's easy, well, there's nothing to discuss when it's vertically, you just place them in the same line and standing upright and right in this direction. This is used for short abbreviation, but, sorry, for short abbreviation, but too long that they can fit horizontally. So this is one way that is commonly used. For longer words, this is the standard way, so you just turn the word to the right. Why is this possible? Because as in Japanese, as in any Western language, Roman letters, we don't, we read words, not letter by letter, but we read words by their appearance. Actually if you study a bit, you read words by one of the recognizing thing is the rhythm of up, so over, so the parts going above the part, so here and below the baseline. So this sim, so this makes it very easy to read short parts or short words or one, two, three words in this kind of type setting. For longer text, it would be completely impossible to, well, you have to turn, but well, for single words. There's another thing for very short, like distances is used for years, is that you put the numbers into like the frame of a kanji and fit it in, so this is very common writing style. So this is heisei when you just write the year in this style. I just mentioned here, so many of the information here, and this is also for those. Yeah, but it enters in my mouse, sorry. What should I do? Should I eat it? Why is this bad? So for those interested, the W3 has a very nice description of most of the problems here, and very detailed. This is not also for Japanese, also for Chinese, traditional and modern Japanese, traditional Chinese and simplified Chinese. There are three descriptions here that are very helpful for reading. If you want more details about this. So as I said, mixing the Roman letters, so the default, as I said before, in vertical typesetting is that you just turn it around. You see this is quite common stuff, and then while there is the spacing around this, if you're really into nice typesetting, then you care for what are the spaces here and there, at least in Japanese, there are clear rules. They are even standardized. How much space you should enter here between kanji and roman letter. So in tech vocabulary, this would be the size of a kanji letter, and here you put the so-called x kanji skip. I don't discuss now the internals of it, but yeah, for the tech implementation, there are a few more options here. If you want to stay to the grid type setting, then well, the idea is that this, you just fit the space around in the full kanji width in a way that, well, the number often fits exactly into the width. Normal Japanese fonts have, for example, numbers, but also all the letters in two variants in proportional, so that for normal roman and in this form that they are exactly the size of the kanji so that it can be used in this way without breaking the grid type setting. So what are the rules for punctuation? I mean, I just don't want you to remember all this. I just want to give you a feeling, okay, there is a lot of, so to say, well, knowledge and requirements if you want to do proper type setting with this. So for example, the typical thing is after comma here or after punctuation marks, they are set on a half kanji width and then there should be another half width space. So there should be some opening and it should not be a full width, which often happens in type setting. So we see here and here and here and here. So these are the typical examples for after full stocks and commas half kanji width. Then, for example, if you mix in quotation marks, so these are typically roman quotation marks, these are not normed. So, okay, here, this is, for example, a roman quotation mark. This is not very common, this is not very common anyway. It's not very common in Japanese, but used, especially nowadays, Japanese have their own quotation marks. So also in this case, you add half a space between the surrounding kanji to just achieve proper spacing. And then there are things which are not common in Western type setting is a center dot, which should be set into the middle of the page. Okay, so what happens if it is not done, right? So in a text editor, most of the text editors don't support proper spacing. So what you would see, you would see a comma here and then like an opening bracket in Japanese. And then you have here a big wide open gap. The rules actually say that it should be only half a width and here we would have one half and another half so a full width open. So the correct output would be that. That is job of the type setting. So for example, for the Libre office, we hope that this somehow gets implemented. So how would this look like here? So that would be 10 kanjis in proper type setting, so in the full length. And if we add just parentheses, or the equivalent of parentheses here, then well, they have the same width. That is nice for grid type setting, but it's not what we expect in Japanese type setting. We don't want to see this because it's just too open. This is just incoherent. So if you have an idea about Roman typography, what you would see if you have a very uneven spacing on the page, you would see what is called in typography rivers going through the page because you have wide open between words, too wide open space, and that creates rivers of wide going through the page. This is also very, very as something that typographers book setters dislike a lot. And so they try to get rid of this. And this is a very similar reason here that we don't want this A open space here. So the rules is just here, half and here, a half in between of this, and that is definitely the proper way. About cliff widows and orphans. So if I come sample here, this character is just one overhang from a word that followed by a parenthesis. This is not really beautiful. So what normally is that here, we just shift one word further on or just put the whole next. So I mean, here, this is an opening bracket. This is very nice. It's all on the right, and here it's just hanging over. This is, if you know orphans and widows in Roman, this is the same just with single characters. You don't want a single word on the last line of a paragraph, or you don't want just one line of a paragraph hanging over to the next page. So these are very, very similar requirements to what there is in Japanese type setting. Line adjustments, well, it's like setting in block type, in Roman letters, it's a bit easier because we can't, well, it's not so easy, but we have the spacing between the words. It's a bit flexible in Latin type setting. So normally people don't recognize up to 5% of fluctuation between the spacing in the white words. In Japanese, because there is no space between words. So you have rather low flexibility. There is nothing you can really push. You cannot open up the space between two words easily to come on. So that would be a nice line that just finishes here because, yeah, well, that worked out. But for example here, because we have two punctuation marks, well, and that means one half space here and here, that we have an overhang here. So that is something which is not very recommendable. So you cannot print. It's the same like you will not see anything like this in a Latin book, in a book typed in a Latin script, unless it is by, right, it's not. So what is normally done that, for example, this space is a bit compressed and this space is compressed, this is one way that can be done. Here's another example that is very typically, you don't want the opening bracket here lonely on the line at the end, so you shift it over, but then you have too much space before. So well, then what is normally done that actually the space between the countries is a bit opened up. So in tech terms, for those who know though, there is a bit of glue that is extendable. It's very low because it just, it doesn't look right if it's too much extended. So if you move two characters over, this is already out. That doesn't look good anymore. Another line example here, so we had, for example here, we have two quotation marks and then you have, for example, these small characters, I don't explain them now what the meaning of these small characters is some catacana. They are a bit smaller, they are a bit subset and so they change also the spacing again and that means that things are quite complicated here. Here some space is extended actually that the line works out nicely here on this length side. Again, here we have two quotation marks, consecutive and here the space can be compressed. So there are a lot of tricks where type setting system, if they are really good, can get really high quality. So this is the ideal reality is unfortunately not completely. Just to mention a bit, the Chinese type setting rules. So yes, if you look at the W3C consortium recommendations for Chinese type setting, they are much, if you compare the Japanese and the Chinese, it's they are much more unspecific. They just say, yeah, well, they have the problem with this ever and something should be done. I was surprised that the Chinese rules are so lax I would say. So they are not very strict in this sense compared to the Japanese rules, which are actually ISO standards also. Okay, so that was a bit about what are the problems in type setting with Chinese. So this is standard what we have. So next is I want to history of the Pitech family. So this is part of the Pitech code, whatever the Pitech code is. Just for giving you all an idea about, so Pitech was an engine that was more than 25 years developed, an independent Pitech engine. And for the Japanese here, probably most of them remember the incantations here. I just tell you that every Japanese Pitech user patched the source code of Pitech, compiled its own Pitech engine, compiled all the font matrix and all the stuff and installed all this, each and every Pitech user up till 2010. It was when I came in October 2009 and in October 2009 I moved to Japan and in November 2009 I attended the first tech conference in Japan. I was like, no, no. That cannot, I mean this was like, I mean, I was like, how much pain do they take? I mean if you compile Pitech of a normal machine, it takes probably an hour or something. And I guess there were so many compilation errors and problems so it was impressive. So what is this Pitech I'm talking about? So it was in 87, it was developed originally by entity called J-Tech. For those with a bit of history, we had J-Tech in Debian till I requested removal for five years ago or something. So that was the first support where they tried to, well, what was the problem? A Japanese font, like a Chinese font has on average like 20,000 characters, well, 10,000, whatever, and that doesn't work with the normal tech engine where the limit now, this is 256, so yeah, that was a bit of a problem, long before the introduction of Xetek and Luwatech. So they developed this independent in the same year, so Ascii Nihong as a company in Tokyo did the multi-pipe extension so that you can actually use Japanese encodings, so it was Shift-GIS from the beginning. Nowadays, most of them work also with UTF-8. In 90, the vertical type setting extension was added and it was named Pitech. The reason is what's called from publishing tech, so for publishing in Japan. In 93, the GIS standard came out, the Japan Industrial Standard for type setting. This is very close to what I mentioned before on the W3C page, but I cannot get the GIS standard because it costs too much money. Pitech was in 95, then re-based on tech 3.0 and there is also Pitech, so the late-tech format based on Japanese phones all kind of formats, so there is a long development history there. In 2003, I think one of the most commonly used package UTF to access arbitrary seed key glyphs in a font, which is common because there's this hand unification, many people don't like, and then there are many code points that are not easily accessible, so you want into a seed key font, you want this, especially for names in Japan that use sometimes quite complicated kanji. In 2006, Tsuchimura Sensei developed this Pitech, so based on Thomas Essertech, which was also a long time in Debian, he made all these patches that users can just patch the stuff to himself and then build all this. He switched later to Pitech Live after Thomas Essert stopped developing it anymore. Well, further steps, I think 2007, Tanaka Sensei introduced uptech, which is a unique code because Pitech was solely based on shift-chis encoding. There are further developments in 2008 and something, so what we have seen already most parts of it, it's a 16-bit extension, the first tech engine that supported this long before Xitech and Luretech. Nowadays, it supports various internal and output encodings. It has support for special kanji font metrics, so large number of screws on different layers, kerning all these kind of problems, inter-cliff spacing between Japanese and non-Japanese, so all these types, I presented before, so these problems with spacing, they were implemented in this engine. And line spacing, something like that. Okay, that was, as I said, till 2009, when I attended the Japanese Tech Conference, and I was, till then, already, since several years maintaining tech life upstream, also developing with CalBerry, and I said, no, that cannot be the future, that's forbidden. And I think it was, yeah, so 2009 at the Tech Conference, I heard this the first time, was shocked completely, and I said, no, that cannot be, and so 2010 in April, that was the start, I pushed with Kakuto Sensei Akira, so all the, not all the PTEC stuff, initially the basic engines into the tech life subversion, and that started quite some development. So, upcoming to Tech Life 2010, that was the first release that included PTEC, the engine, and JS Glasses from Okamura Sensei, so was released in June 2010, included most basic tech, Japanese tech support, that was not perfect, but okay, it was, people could just install tech life on like 15 different architecture and operating system combination from Windows, Mac, Solaris, iX, Alpha, whatever, with all kind of operating systems, without compiling themselves. 2011, I have, well, I have overslept somehow, in 2012, together with the Japanese Tech Group, we pushed up tech, so the Unicode version and EPE up tech, which includes the eTech extension, including other packages, all these main packages for, that are important for typesetting, yet OTF package, that's for the Accessing Arbitrary Cluth and Lua Tech GA, so like, which is the future, so in 2012, I would say it was the first time that there was complete support for CJK typesetting in Tech Life, so I will talk about CJK options later on, but that was the first time, and I just speak about upstream, but I'm also the package of the Debian packages, and we had, since 2009, we have Tech Life packages in Debian, first in parallel with T-Tech and now only Tech Life, so practically, no, practically everything that is discussed here is also one to one available in Debian. Later on, so in the following years, there's just normal package updates, we improved over the years a lot, especially for the fund support, fund support for not only Japanese funds, Chinese funds, so traditional and simplified, and Korean funds, integration with Ghoststrip, that we can set up Ghoststrip automatically, we integrated, well, a Japanese version of Metapost, that was in 2015, so it's nowadays, it has come down a lot, so it's normal development nowadays. So what are the status in other countries outside of China? So from my experience, and I hope that the non-Japanese CK here in the room can correct me, talking to them, most of people use Xitech and don't use anything else. Xitech is nice, it works nice, it relies on the fund providing the proper type setting, which is not necessarily available. If you use, for example, Japanese with Xitech, and you get the standard of normally, most people get the IPA funds, there would be, it would be not up to a standard, I would expect, I don't know enough about Chinese, I have to say, but I know that most Chinese, at least in mainland China, use Xitech just as is. Well, as I said, if you want specific layout features in with the Xitech engine, you need the proper support of the OTF funds, which is nowadays with the libraries we have, not so bad, but the problem is that the information in the OTF funds are not necessarily good. Over the last few years, actually, ABTECH, especially ABTECH, the Unicode variant has been picked up not only in Japan, well, Japan was, it was very common already, but also in Korea, China, in many places, because the problems are the same, and so it was picked up, and we have nowadays, for example, a lot of independent development support from the Korean side, and there is also a new development, just it was called Asian PTECH or PTECH-NG, unfortunately the Chinese developer has stopped doing anything, actually, I was just re-backing it, anyway. So generally the support from, it was originally everything Japanese, the support from non-Japanese languages has changed completely, so this is an example of a document in tech written without any common sequences, everything is typed as you see it here, with Russian, with Greek, check with all these languages, with umlauts in German, everything is typed as is in the tech source code, you just switch language with bubble and you get the output properly, so ABTECH is nowadays able to do all these kind of things plus vertical type setting, plus proper type setting for Japanese stuff. So what about the font support? So we have the first, it was called Jfonts, Japanese fonts, a package I started, and now it is developed together with all the other Japanese developers, it was just because PTECH, ABTECH, they don't go direct to PDF, they use, they go to DVI, and then use DVI, PDF, M, X, whatever, it's all the same nowadays, to import, to include your OTF fonts, true type fonts, OTF fonts, so what's the current status in, within Debian, within tech life, and that's also Debian because it's the same, so we have for Japanese, the IPN, the IPX fonts are both included in tech life and also in Debian, so they can be used straight ahead for type setting Japanese, we have support for these other fonts, Moga, Ume, they are free, you can install them, they are not included in tech life, and we have support for various commercial fonts, the Microsoft fonts, we have the U, Hiragino, Topampunkka, Kozaka, so for the Japanese, they will know all these names, these are all commercial fonts, or are provided, for example, like the U fonts are provided with Apple, with MacOS, so that's a great request for supporting these fonts. For simplified Chinese, we have the African Thunder fonts, both are included in tech life and installed, so you can, if you use XZX, XZX, XZXK, whatever you can types it immediately, simplified Chinese or traditional Chinese, the CJK uniforms are as far as, they are not included in tech life, so not in the packages, I'm not sure if they are packaged for Debian, they are free, and we have support for several other, again, the Microsoft fonts, Foundry, Founder, Commercial fonts, which, wow. Traditional Chinese, the situation is very similar to simplified, there are more commercial options from Adobe also, and for Korean, the Bekmong and Unfonts are included in tech life, and also in Debian, and we have support for the usual commercial fonts from Microsoft, Apple and Adobe, so all these, the commercial support is not included in tech life, well, actually we merged it, even out of tech life, tech life has in principle the policy to follow the SFS guidelines, or even the DFSG guidelines with a few exceptions, where I always punch again the fundamentalists in Debian, but anyway, so we removed, so the support for the fonts is free, it's open source, but we don't include it in tech life because it's only support for commercial products, we don't include it in tech life, and so it's also not included in Debian, but can be easily installed, it's just a few list of files to be installed. Okay, very short, because most people don't know this, so font embedding is configured in a certain program, it's called Update Map, and there are nowadays that it's a long time that has changed now since three years or something, especially embedding configuration for languages, J.A. for Japanese, simplified Chinese, traditional Japanese and Korean, so all these fonts can be embedded, defined for each of these classes, you can define which font you want to embed, or you can say no embed and let the viewer choose the fonts, which is also very common. For Japanese who are interested, there is also the Gist 2004 variant, can you choose which changes some of the font as of the kanji? And there's a script for automatically setting up or allowing you to easily configure font embedding for the fonts there. Okay, so more or less at the end, so what's the current status? So Japan in Japan, so in the Japanese, there's a Japanese tech developer group, you can find on TechGP, we have our own mirror of tech life, we have our own extra tech life repository for testing release, for commercial stuff. Development is most before like up to like a few years ago, it was all in private repositories on private websites. I have with this creation of the Japanese tech developer community, we have now moved everything to GitHub, everything you can follow there, you can join and help those who are interested, or everything has also finally gotten consistent uploads to Zetan, which was one of the big problems in the initial years, like 10 years ago, because Japanese developers had the tendency not to upload to Zetan, because I don't know why. Anyway, so that has changed completely, I'm very happy about this. So I would say from the Japanese side, it is now really like optimal. I mean, one reason is that of course, I'm a tech life maintainer, so I have a good bridge between this and can care for integration. On the Korean side, we had the big tech user group conference in Tokyo in 2013, there were a lot of Korean participants, and I somehow managed to convince them also to contribute their development to tech life. They are up to then, they had their own repository, everything independent, often hard to access. This has changed, it is now everything in upstream tech life, in collection, in TBM package it would be tech life, long Korean. So practically all the requirements for Korean type setting are also included nowadays in tech life. For Chinese, I have to say, I have never heard any request from any Chinese, neither on a mailing list nor privately. Okay, I don't know. Maybe they are just happy with Xitech and everything is fine. So that's the current status we have in tech life, and that means also in TBM. I didn't put a slide here, I forgot actually, I wanted to mention here before what the future is. The future moves very strongly to Lua tech, it's an extension of the tech engine with Lua as an embedded interpreter. So there are hooks into the type setting system of tech. With Lua it is already used a lot in context, in some other type setting system, and there is a package Lua tech GE that is now I use on a daily basis for our reports. It is excellent. You get direct PDF output. You can use all the fonts and it because just to use Lua for the requirement complex parts and command. This is in tech life since 2015, a heavy development permanently improving. So I recommend everyone interested in Japanese type setting to look at this package. Okay, that's all from my side. Thanks for your attention, and I'm open to question, suggestion, and criticism from more experienced people than me. Thanks a lot. I have two questions. One is, is there a best practice starting point for a correct type setting in Japanese with tech? And the other question is, how's the support of the Sazanami fonts, respectively the wine, Linux, fork of it, VGothic, Sazanami, and VGothic? Okay, the first question, I mean I wrote a blog about type setting in Japanese with tech, very simple. I thought this is something I didn't want to do here. I didn't want to do a tutorial how to write simple stuff where I discuss like encoding problems and what you write. I think the best practice is read, just take the Lua tech GE documentation and make a simple file with use package, one of the Lua tech classes, Lua tech GE classes, and then you get everything for free, more or less. And that is, if you want an easy start, this is like a four-liner for a hell of a world. Everything running out of the box on Debian, on any tech life installation is my recommendation if you want to start type setting in Japanese. If you want to go to vertical type setting, then it's probably still better to use P-tech up-tech, which makes it, but it's still not complicated. But for a start, I recommend Lua tech GE because it is so smooth and easy to use for type setting. The other, no support. No, I don't know. Probably can load them and see if it works. So you can use C-tech of course and load the font. You can use Lua tech to use, to load an arbitrary font. I have no experience with it. I don't know what would come out of it. But I'm doubtful about the quality of the fonts. So, but that doesn't mean you cannot use it. I'm quite, if it's a normal TTF font or something as far as I remember, actually I used it for a Garmin device to hack a Garmin device, so I should know it. But it's a long time ago. So usually, you can load an arbitrary font you should be able to just use it straight ahead with Lua tech GE by selecting the font in a font spec type. Yeah. Just you recommended Lua tech for things. So I use, I don't do a lot of CJK stuff, but just for personal hobby stuff, I often use sort of multiple character sets. And one of the nice things about Z-tech is that you can have it select the font automatically by the code block. I haven't figured out a way to do that with Lua tech yet. Is there a way to do that? I cannot answer. I believe there is, but I wouldn't guarantee you. But you meant by, it's all UTF, but it's by different Unicode code block, right? Yeah, yeah, yeah. That's what you meant. It's not different in coding, but different UTF, but it's a code block in there. It's all UTF-8, and you load, so instead of Babel with Polyglossia, they'll say what the languages are, and then. I believe there is a way. I would have to check it out. I think there is, but yeah. As I said, I cannot guarantee. But it's true, this is a nice feature. Selecting fonts automatically based on the Unicode language block. This is a nice feature, I agree. Okay. Thank you for a good presentation. I was, all tech users, so I remember about Omega Project. Oh. Oh. So I, is that, I Googled about it, so it has close to the three parts are integrated to Lua Techs. So I can, I can explain you the whole story. So John Blaise and Yanni Harambolo developed Omega. I actually, I remember the first time I came to Japan in 2001 as I was invited to the conference of mutual utilization because I wrote support in Omega for writing Tibetan. I studied Tibetan at university, and I wanted to write Tibetan just right ahead in my editor. And so I wrote support. So Omega had two, two interesting extension. The one was, it allowed very free definition of the typesetting direction. So you could freely, I mean, which was never used in this generality, but you can see start at the top, then go to the left or right, or start at the bottom and then go up or left. And then you can also, so you can specify where this is and you can also see the character should be turned or should not be turned, so TLT. So that was a very nice idea. That was included into Luwatech. I think that you can use this direction in the same vein. The other big part of Omega was they had a finite state automaton plugged into the input. So you could write, it was called Omega translation process. So you could write more or less a finite state like a grammar that translates stuff. So I used it for typesetting Tibetan because you have to reorder a lot of stuff that you get the right glyphs. That has not been carried over to Luwatech because there are better ways now because we have now Luwa as a plug in there. So you can do the same thing in Luwa and it is done. So for example, if you look at Devanagari typesetting or Tibetan support, nobody has written it because I don't have time, but the Nagari typesetting there is support for it because it is very important in India. So there you also have, you have to switch character, especially when you input in Romanized letters, then you have to switch the stuff around that you get the right order of the letters in the Sanskrit, in the Nagari. So that is done nowadays in Luwa. So this part of this Omega translation process was not carried over. So these were the parts that were carried over into Luwatech. In addition, Omega project died. Both John and Yanni just stopped developing. John moved on to completely different things. It was later picked up in a different engine. It's called Aleph. I'm not sure if you've heard this. Aleph is still included in Tech Life. Aleph is, so to say, a fixed Omega with a bit improvement. Who was it? It was an Italian who, I forgot the name, sorry. And there is also a format for it. There is also Lamet, which is, well, it's just all Hebrew letters. So Lamet for the Luwatech format. So you still can use, if you still have all documents that uses Omega translation process, you can still principally use them with Aleph and Lamet. They are in Tech Life, they are all included. But there is no development going on. Nobody's interested anymore. Because, well, it was a very nice idea and worked for a long time quite nicely. It is now superseded, I would say. Interesting, thank you. Well, if there are no further questions, we are at zero. I was just indicated zero. No, actually one minute, so one last question. If not, then. Thanks a lot for the attention. And anyway, if you have any questions or problems with typesetting, I mean, I get often from the DBN documentation team, I get requests about problems when typesetting doesn't work out. Because actually, this is a nice thing on the DBN typesetting documentation because they request a lot of features and a lot of languages and a lot of translations that means there is, well, we have to keep up with this. This is very nice. And so if there are any questions, requests, wishes. Actually, my biggest request is actually to the Taiwanese and Chinese here. In the hope that I hear wishes from them because I want to improve support for them if there is something to improve. I mean, I cannot do something out of the bags. Okay, thanks a lot to everyone.