From daniel.buenzli at erratique.ch Mon Sep 4 04:52:48 2023 From: daniel.buenzli at erratique.ch (=?utf-8?Q?Daniel_B=C3=BCnzli?=) Date: Mon, 4 Sep 2023 11:52:48 +0200 Subject: =?utf-8?Q?=E2=97=8C_?=in LB28a in UAX14 of Unicode 15.1.0 Message-ID: Hello,? I can?t figure out what the ? character classification represents in: ? https://www.unicode.org/reports/tr14/proposed.html#LB28a Any hint ?? Best, Daniel From daniel.buenzli at erratique.ch Mon Sep 4 08:33:12 2023 From: daniel.buenzli at erratique.ch (=?utf-8?Q?Daniel_B=C3=BCnzli?=) Date: Mon, 4 Sep 2023 15:33:12 +0200 Subject: =?utf-8?Q?=E2=97=8C_?=in LB28a in UAX14 of Unicode 15.1.0 In-Reply-To: References: Message-ID: Thanks.? I think it would be better if that was written \u{255C} as per regexp notation. Like that it?s highly ambiguous as to what it represents since in these rules a class C itself represent \p{lb=C} and some of the characters are distinguished syntax. Also it would be nicer for certain implementations if that was somehow integrated as a character class in the rules like e.g. ZJW is. Which leads me to another question, is there a machine readable version of the rules for all the Unicode segmentation standards ? In the ldlm perhaps ? Best, D From egg.robin.leroy at gmail.com Mon Sep 4 05:27:08 2023 From: egg.robin.leroy at gmail.com (Robin Leroy) Date: Mon, 4 Sep 2023 12:27:08 +0200 Subject: =?UTF-8?Q?Re=3A_=E2=97=8C_in_LB28a_in_UAX14_of_Unicode_15=2E1=2E0?= In-Reply-To: References: Message-ID: Le lun. 4 sept. 2023 ? 11:57, Daniel B?nzli via Unicode < unicode at corp.unicode.org> a ?crit : > Hello, > > I can?t figure out what the ? character classification represents in: > > https://www.unicode.org/reports/tr14/proposed.html#LB28a Itself: U+25CC DOTTED CIRCLE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.icu at gmail.com Mon Sep 4 12:53:01 2023 From: markus.icu at gmail.com (Markus Scherer) Date: Mon, 4 Sep 2023 10:53:01 -0700 Subject: =?UTF-8?Q?Re=3A_=E2=97=8C_in_LB28a_in_UAX14_of_Unicode_15=2E1=2E0?= In-Reply-To: References: Message-ID: On Mon, Sep 4, 2023 at 6:36?AM Daniel B?nzli via Unicode < unicode at corp.unicode.org> wrote: > Also it would be nicer for certain implementations if that was somehow > integrated as a character class in the rules like e.g. ZJW is. > It didn't seem worth it for a one-off, especially now that we no longer partition the code space with exactly one property value per code point. is there a machine readable version of the rules for all the Unicode > segmentation standards ? > There is not an official version like that. Unofficially, we have such a version in the tools code that generates the test data: https://github.com/unicode-org/unicodetools/blob/main/unicodetools/src/main/resources/org/unicode/tools/SegmenterDefault.txt for the UAX #14/#29 default behavior https://github.com/unicode-org/unicodetools/blob/main/unicodetools/src/main/resources/org/unicode/tools/SegmenterCldr.txt for CLDR/ICU root locale tailorings, if any markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From sosipiuk at gmail.com Mon Sep 4 13:11:35 2023 From: sosipiuk at gmail.com (=?UTF-8?Q?S=C5=82awomir_Osipiuk?=) Date: Mon, 04 Sep 2023 18:11:35 +0000 Subject: =?UTF-8?B?4peM?= in LB28a in UAX14 of Unicode 15.1.0 In-Reply-To: References: Message-ID: <1693850901194.664336717.3974986017@gmail.com> It's definitely confusing. At first glance it certainly appears to be some kind of special marker or syntax, not a simple literal character. It needs at least a note somewhere because this WILL cause confusion and this question will come up again elsewhere. On Monday, 04 September 2023, 06:27:08 (-04:00), Robin Leroy via Unicode wrote: Le lun. 4 sept. 2023 ? 11:57, Daniel B?nzli via Unicode a ?crit : Hello, I can?t figure out what the ? character classification represents in: https://www.unicode.org/reports/tr14/proposed.html#LB28a Itself: U+25CC DOTTED CIRCLE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asmusf at ix.netcom.com Mon Sep 4 13:45:16 2023 From: asmusf at ix.netcom.com (Asmus Freytag) Date: Mon, 4 Sep 2023 11:45:16 -0700 Subject: =?UTF-8?Q?Re=3a_=e2=97=8c_in_LB28a_in_UAX14_of_Unicode_15=2e1=2e0?= In-Reply-To: <1693850901194.664336717.3974986017@gmail.com> References: <1693850901194.664336717.3974986017@gmail.com> Message-ID: <7f4fe3ec-440f-7bbf-dd9a-0e028820f60c@ix.netcom.com> Correct, we don't have a notation for "literal" and we need one. A./ On 9/4/2023 11:11 AM, S?awomir Osipiuk via Unicode wrote: > It's definitely confusing. At first glance it certainly appears to be > some kind of special marker or syntax, not a simple literal character. > It needs at least a note somewhere because this WILL cause confusion > and this question will come up again elsewhere. > > On Monday, 04 September 2023, 06:27:08 (-04:00), Robin Leroy via > Unicode wrote: > > Le?lun. 4 sept. 2023 ??11:57, Daniel B?nzli via Unicode > a ?crit?: > > Hello, > > I can?t figure out what the ? character classification > represents in: > > https://www.unicode.org/reports/tr14/proposed.html#LB28a > > Itself: U+25CC?DOTTED CIRCLE. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.heninger at gmail.com Mon Sep 4 17:55:05 2023 From: andy.heninger at gmail.com (Andy Heninger) Date: Mon, 4 Sep 2023 15:55:05 -0700 Subject: =?UTF-8?Q?Re=3A_=E2=97=8C_in_LB28a_in_UAX14_of_Unicode_15=2E1=2E0?= In-Reply-To: <7f4fe3ec-440f-7bbf-dd9a-0e028820f60c@ix.netcom.com> References: <1693850901194.664336717.3974986017@gmail.com> <7f4fe3ec-440f-7bbf-dd9a-0e028820f60c@ix.netcom.com> Message-ID: > > is there a machine readable version of the rules for all the Unicode > segmentation standards ? It would be nice if the rules in the UAX source documents were tagged in some way such that simple tooling could extract them in a useful form. I used to have a script that would scrape the line break rules from UAX-14, for the purpose of partially automating maintenance of the pair table, but it (and the pair table) are long gone. -- Andy On Mon, Sep 4, 2023 at 11:47?AM Asmus Freytag via Unicode < unicode at corp.unicode.org> wrote: > Correct, we don't have a notation for "literal" and we need one. > A./ > > > On 9/4/2023 11:11 AM, S?awomir Osipiuk via Unicode wrote: > > It's definitely confusing. At first glance it certainly appears to be some > kind of special marker or syntax, not a simple literal character. It needs > at least a note somewhere because this WILL cause confusion and this > question will come up again elsewhere. > > On Monday, 04 September 2023, 06:27:08 (-04:00), Robin Leroy via Unicode > wrote: > > Le lun. 4 sept. 2023 ? 11:57, Daniel B?nzli via Unicode < > unicode at corp.unicode.org> a ?crit : > >> Hello, >> >> I can?t figure out what the ? character classification represents in: >> >> https://www.unicode.org/reports/tr14/proposed.html#LB28a > > Itself: U+25CC DOTTED CIRCLE. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.buenzli at erratique.ch Mon Sep 4 18:11:01 2023 From: daniel.buenzli at erratique.ch (=?utf-8?Q?Daniel_B=C3=BCnzli?=) Date: Tue, 5 Sep 2023 01:11:01 +0200 Subject: Machine readable segmentation rules (was Re: =?utf-8?Q?=E2=97=8C_?=in LB28a in UAX14 of Unicode 15.1.0) In-Reply-To: References: Message-ID: Thanks for your links. > It didn't seem worth it for a one-off, I understand. I got annoyed more than once by the segmenters starting being defined over characters sets defined by regexps rather segmentation class properties. But then if that?s an easier way forward to define meaningful segmentations for end-users I?m willing to play along. > > Unofficially, we have such a version in the tools code that generates the > test data: The reason I?m asking this is because it?s becoming quite clear to me that I took a wrong turn on how I implemented the Unicode segmenters 10 years ago. Or rather, what looked reasonable then no longer is: grapheme clusters could be implemented by a 2D lookup table and the other segmentation rules were simple enough to implement them in an ad-hoc and *streaming* fashion. Nowadays this reasonable thing has grown into *horribly* ad-hoc and convoluted implementations of the segmenters. Sometimes the ad-hocness is nice because it allows to clean the spec [1], but pragmatically I end up spending way too much time when new rules get added. I need to split characters classes myself (e.g. in this case AL), massage the rules and cope with their changing complexity (e.g. the context enlarges). All this increases the probability that I implement them wrongly despite the test suite passing. I thought these rules would eventually stabilize the normalization standard (UAX 15) did but it doesn?t seem to be the case (this is not a complaint). So I wonder we could maybe steer the segmentation standards towards the definition of some kind of general rule-based segmentation machine with machine readable rule specifications defined in the UCD. For implementers it would be a matter of implementing this generic machine in some way and updating the segmenters would be a matter of feeding the machine with the new rules like the way we update normalization data on new Unicode releases. It would also likely make it easier for APIs to provide hooks for tailoring (which might benefit end-users too). It seems to me that except for the (annoying) rewrite rules we are actualy not far from it. IIRC the operational model of all the segmenters is: between each two code points of the string to segment apply all the rule in order taking the first one whose regexp matches on the left and on the right to define the boundary status of the point. That a segmenter UCD data file could simply be: ?SEGMENTER := (RULE ?\n?)*? ?RULE := REGEXP (???|???|?!") REGEXP ?REGEXP := ? # Unicode regexp as per UTS 18 syntax For me it would provide a more sustainable approach from a maintenance point of view, similar to the one I have with normalization for which I simply regenerate compact data from the UCD on new Unicode releases. Best,? Daniel [1]:?https://www.unicode.org/mail-arch/unicode-ml/y2020-m03/0000.html From asmusf at ix.netcom.com Mon Sep 4 18:34:22 2023 From: asmusf at ix.netcom.com (Asmus Freytag) Date: Mon, 4 Sep 2023 16:34:22 -0700 Subject: =?UTF-8?Q?Re=3a_=e2=97=8c_in_LB28a_in_UAX14_of_Unicode_15=2e1=2e0?= In-Reply-To: References: <1693850901194.664336717.3974986017@gmail.com> <7f4fe3ec-440f-7bbf-dd9a-0e028820f60c@ix.netcom.com> Message-ID: <293295f9-0a03-38c1-eb4f-d9da9c30f2e4@ix.netcom.com> The pair table. Those were the days! A./ On 9/4/2023 3:55 PM, Andy Heninger via Unicode wrote: > > is there a machine readable version of the rules for all the > Unicode segmentation standards ? > > > It would be nice if the rules in the UAX source documents were tagged > in some way such that simple tooling could extract them in a useful form. > > I used to have a script that would scrape the line break rules from > UAX-14, for the purpose of partially automating maintenance of the > pair table, but it (and the pair table) are long gone. > > ? -- Andy > > On Mon, Sep 4, 2023 at 11:47?AM Asmus Freytag via Unicode > wrote: > > Correct, we don't have a notation for "literal" and we need one. > A./ > > > On 9/4/2023 11:11 AM, S?awomir Osipiuk via Unicode wrote: >> It's definitely confusing. At first glance it certainly appears >> to be some kind of special marker or syntax, not a simple literal >> character. It needs at least a note somewhere because this WILL >> cause confusion and this question will come up again elsewhere. >> >> On Monday, 04 September 2023, 06:27:08 (-04:00), Robin Leroy via >> Unicode wrote: >> >> Le?lun. 4 sept. 2023 ??11:57, Daniel B?nzli via Unicode >> a ?crit?: >> >> Hello, >> >> I can?t figure out what the ? character classification >> represents in: >> >> https://www.unicode.org/reports/tr14/proposed.html#LB28a >> >> Itself: U+25CC?DOTTED CIRCLE. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.buenzli at erratique.ch Tue Sep 5 04:10:38 2023 From: daniel.buenzli at erratique.ch (=?utf-8?Q?Daniel_B=C3=BCnzli?=) Date: Tue, 5 Sep 2023 11:10:38 +0200 Subject: UAX44 proposed update is missing a description of InCB Message-ID: Hello,? I noticed that the current proposed update (draft 4) [1] for UAX44 is missing a description of the new derived property?Indic_Conjunct_Break present in?DerivedCoreProperties.txt and which is needed for UAX29?s new definition of grapheme clusters. Best,? Daniel [1]:?https://www.unicode.org/reports/tr44/proposed.html From markus.icu at gmail.com Tue Sep 5 10:21:35 2023 From: markus.icu at gmail.com (Markus Scherer) Date: Tue, 5 Sep 2023 08:21:35 -0700 Subject: UAX44 proposed update is missing a description of InCB In-Reply-To: References: Message-ID: On Tue, Sep 5, 2023 at 2:13?AM Daniel B?nzli via Unicode < unicode at corp.unicode.org> wrote: > I noticed that the current proposed update (draft 4) [1] for UAX44 is > missing a description of the new derived property Indic_Conjunct_Break > present in DerivedCoreProperties.txt and which is needed for UAX29?s new > definition of grapheme clusters. > It will be in the 15.1 version which will be released next Tuesday. markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From elango at google.com Fri Sep 8 14:15:06 2023 From: elango at google.com (Elango Cheran) Date: Fri, 8 Sep 2023 12:15:06 -0700 Subject: Unicode Technical Workshop Call for Submissions Message-ID: Hi everyone, In case you haven't seen it yet, Unicode just announced the first ever Unicode Technology Workshop (UTW), hosted in Silicon Valley this November 7-8! This is a new in-person event focused on providing a venue for professionals in the Unicode, i18n, l10n, and related spaces to learn from each other and tackle the latest challenges, something we haven't had since the Internationalization and Unicode Conference (IUC) ended in 2021. Call for submissions is now open! I encourage you all to suggest topics relating to ICU, ICU4X, CLDR, L10n tools, Scripts, Fonts, Layout, and more. Learn more here: https://www.unicode.org/events/index.html -- Elango -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Wed Sep 20 14:19:45 2023 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Wed, 20 Sep 2023 20:19:45 +0100 (BST) Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? Message-ID: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> Abstract symbols for personal pronouns, and for verbs such as "must" and "need" and "want", and for meanings such as "however" and "because" and so on could greatly enhance expressiveness through the language barrier in use with emoji. Use of abstract artwork will allow expressiveness in situations where a realistic artwork is impossible or results in artwork too detailed for use at small sizes. A good mailing list discussion with ideas from many people may lead to progress. William Overington Wednesday 20 September 2023 From gwalla at gmail.com Wed Sep 20 14:25:22 2023 From: gwalla at gmail.com (Garth Wallace) Date: Wed, 20 Sep 2023 12:25:22 -0700 Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? In-Reply-To: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> References: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> Message-ID: You can already use emoji with abstract symbols. There?s nothing stopping you. Go nuts! ?+?=? On Wed, Sep 20, 2023 at 12:22 PM William_J_G Overington via Unicode < unicode at corp.unicode.org> wrote: > Abstract symbols for personal pronouns, and for verbs such as "must" and > "need" and "want", and for meanings such as "however" and "because" and > so on could greatly enhance expressiveness through the language barrier > in use with emoji. > > Use of abstract artwork will allow expressiveness in situations where a > realistic artwork is impossible or results in artwork too detailed for > use at small sizes. > > A good mailing list discussion with ideas from many people may lead to > progress. > > William Overington > > Wednesday 20 September 2023 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtbot2007 at gmail.com Thu Sep 21 09:48:01 2023 From: gtbot2007 at gmail.com (Gabriel Tellez) Date: Thu, 21 Sep 2023 10:48:01 -0400 Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? In-Reply-To: References: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> Message-ID: Unicode is not in the business of making new symbols that don?t already exist. On Wed, Sep 20, 2023 at 3:27 PM Garth Wallace via Unicode < unicode at corp.unicode.org> wrote: > You can already use emoji with abstract symbols. There?s nothing stopping > you. Go nuts! ?+?=? > > On Wed, Sep 20, 2023 at 12:22 PM William_J_G Overington via Unicode < > unicode at corp.unicode.org> wrote: > >> Abstract symbols for personal pronouns, and for verbs such as "must" and >> "need" and "want", and for meanings such as "however" and "because" and >> so on could greatly enhance expressiveness through the language barrier >> in use with emoji. >> >> Use of abstract artwork will allow expressiveness in situations where a >> realistic artwork is impossible or results in artwork too detailed for >> use at small sizes. >> >> A good mailing list discussion with ideas from many people may lead to >> progress. >> >> William Overington >> >> Wednesday 20 September 2023 >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Sat Sep 23 06:11:40 2023 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Sat, 23 Sep 2023 12:11:40 +0100 (BST) Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? In-Reply-To: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> References: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> Message-ID: <6cb04730.521f.18ac1bcf7fa.Webtop.83@btinternet.com> https://forum.affinity.serif.com/index.php?/topic/192209-designs-for-abstract-glyphs-that-could-be-used-with-emoji/ William Overington Saturday 23 September 2023 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtbot2007 at gmail.com Sat Sep 23 10:12:45 2023 From: gtbot2007 at gmail.com (Gabriel Tellez) Date: Sat, 23 Sep 2023 11:12:45 -0400 Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? In-Reply-To: <6cb04730.521f.18ac1bcf7fa.Webtop.83@btinternet.com> References: <2bd6b838.213f.18ab408bb52.Webtop.112@btinternet.com> <6cb04730.521f.18ac1bcf7fa.Webtop.83@btinternet.com> Message-ID: You made those symbols yourself, no? On Sat, Sep 23, 2023 at 7:15?AM William_J_G Overington via Unicode < unicode at corp.unicode.org> wrote: > > https://forum.affinity.serif.com/index.php?/topic/192209-designs-for-abstract-glyphs-that-could-be-used-with-emoji/ > > > William Overington > > > Saturday 23 September 2023 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Sat Sep 23 11:39:02 2023 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Sat, 23 Sep 2023 17:39:02 +0100 (BST) Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? Message-ID: <7f13317f.6de4.18ac2e8ac56.Webtop.112@btinternet.com> Gabriel Tellez wrote: > You made those symbols yourself, no? I thought of having such symbols, thought of designs for the symbols, produced electronic images of the designs using the Affinity Designer software program, suggested the code numbers so that they can be used. They are Open Source in the hope that they will become used. This research is at an early stage. I needed to start somewhere. The symbols are now published and a method to apply them has been suggested. Is it art? Is it technology? Is it useful? Can the symbols convey meaning effectively, including through the language barrier? Will someone study them as applied art? Maybe one day the symbols and the meaning of each will become encoded in The Unicode Standard. That will need the symbols to become widely used by people other than the person who devised them. Maybe one day they will be displayed at MoMA, the Museum of Modern Art in New York. http://www.users.globalnet.co.uk/~ngo/emoji_installation_at_MoMA.htm There are some other symbols that I have devised, listed from the following web page. http://www.users.globalnet.co.uk/~ngo/mariposa_novel.htm They too each have a code that I have assigned to them, so they can be used now if people choose to use them. Maybe other people will devise such abstract symbols and assign meanings too. It would be interesting to observe if symbols by various people can be used together, how various researchers interact. William Overington Saturday 23 March 2023 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at kli.org Sun Sep 24 08:52:49 2023 From: mark at kli.org (Mark E. Shoulson) Date: Sun, 24 Sep 2023 09:52:49 -0400 Subject: Can we discuss the possibility of abstract symbols to be used with emoji please? In-Reply-To: <7f13317f.6de4.18ac2e8ac56.Webtop.112@btinternet.com> References: <7f13317f.6de4.18ac2e8ac56.Webtop.112@btinternet.com> Message-ID: <20c60078-fb9e-ef80-4789-474dece1ab20@shoulson.com> Sounds like a great goal.? You've made designs, made them available...? See if people like using them, put them in the PUA, make apps that can encode them in messages, etc.? As with any writing system, once they become popular you can propose them for inclusion in Unicode.? That's the criterion and that's the order it happens in.? Usage comes first. ~mark On 9/23/23 12:39, William_J_G Overington via Unicode wrote: > > Gabriel Tellez wrote: > > > > You made those symbols yourself, no? > > > I thought of having such symbols, thought of designs for the symbols, > produced electronic images of the designs using the Affinity Designer > software program, suggested the code numbers so that they can be used. > They are Open Source in the hope that they will become used. > > > This research is at an early stage. I needed to start somewhere. The > symbols are now published and a method to apply them has been > suggested. Is it art? Is it technology? Is it useful? Can the symbols > convey meaning effectively, including through the language barrier? > Will someone study them as applied art? > > > Maybe one day the symbols and the meaning of each will become encoded > in The Unicode Standard. That will need the symbols to become widely > used by people other than the person who devised them. > > > Maybe one day they will be displayed at MoMA, the Museum of Modern Art > in New York. > > > http://www.users.globalnet.co.uk/~ngo/emoji_installation_at_MoMA.htm > > > There are some other symbols that I have devised, listed from the > following web page. > > > http://www.users.globalnet.co.uk/~ngo/mariposa_novel.htm > > > They too each have a code that I have assigned to them, so they can be > used now if people choose to use them. > > > Maybe other people will devise such abstract symbols and assign > meanings too. It would be interesting to observe if symbols by various > people can be used together, how various researchers interact. > > > William Overington > > > Saturday 23 March 2023 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.icu at gmail.com Mon Sep 25 19:06:44 2023 From: markus.icu at gmail.com (Markus Scherer) Date: Mon, 25 Sep 2023 17:06:44 -0700 Subject: new ISO 15924 script codes 2023q3 Message-ID: Dear Unicoders, FYI There are ten new script codes registered recently: https://www.unicode.org/iso15924/codechanges.html CodeN?English NameNom fran?aisAlias Age DateKey Chis 298 Chisoi chisoi 2023-09-12 Add Gara 164 Garay garay 2023-09-12 Add Gukh 397 Gurung Khema gurung khema 2023-09-12 Add Krai 396 Kirat Rai kirat rai 2023-09-12 Add Onao 296 Ol Onal ol onal 2023-09-12 Add Sidt 180 Sidetic sid?tique 2023-09-12 Add Tayo 380 Tai Yo ta? yo 2023-09-12 Add Todr 229 Todhri todhri 2023-09-12 Add Tols 299 Tolong Siki tolong siki 2023-09-12 Add Tutg 341 Tulu-Tigalari tulu-tigalari 2023-09-12 Add Best regards, markus ISO 15924 script code registrar -------------- next part -------------- An HTML attachment was scrubbed... URL: