From john at tiro.ca Tue Oct 1 18:14:39 2024 From: john at tiro.ca (John Hudson) Date: Tue, 1 Oct 2024 09:14:39 -0700 Subject: [MPEG-OTSPEC] Many to many substitution and localization In-Reply-To: <307aa3db.32539.19238dd052d.Webtop.184@btinternet.com> References: <307aa3db.32539.19238dd052d.Webtop.184@btinternet.com> Message-ID: On 2024-09-28 06:41, William_J_G Overington via mpeg-otspec wrote: > > Well, I am suggesting the substitution from the displaying of glyphs for > > !983 > > to the displaying of glyphs for > > Diolch am ymweld. > I understand what you are proposing, but you have not demonstrated any value in doing this at the glyph level. Fonts are media for typography. The way in which they work and how they relate to text encoding is particular to the needs of typography, which is to say that they are designed to enable flexible stylistic representation of text with more or less idiosyncratic features at the glyph level in terms of both design and behaviour. Purely standardised behaviours, i.e. non-idiosyncratic features, are best defined outside the scope of individual fonts, at e.g. the text encoding or higher level. Unsurprisingly, that is exactly where text string localisation is done, with the great benefit that the localised strings /can be displayed by any font supporting the target writing system/. You are proposing breaking something that already works in order to make it work in a more convoluted and less useful way. JH -- John Hudson Tiro Typeworks Ltdwww.tiro.com Tiro Typeworks is physically located on islands in the?Salish Sea, on the traditional territory of the?Snuneymuxw?and Penelakut First Nations. __________ EMAIL HOUR In the interests of productivity, I am only dealing with email towards the end of the day, typically between 4PM and 5PM. If you need to contact me more urgently, please use other means. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Tue Oct 1 18:24:34 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Tue, 1 Oct 2024 17:24:34 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <3a33e677.27407.19248e5d49d.Webtop.159@btinternet.com> Simon Cozens replied. ? Thank you for replying. ? Simon Cozens wrote as follows. ? > 1) Ensure that any suggestion is written in as broad terms as > possible, allowing for general purpose rather than specific purpose > use. ? I have been thinking of other possible applications for this suggested additional layout feature. ? Decode a symbol character or an emoji character or a sequence of emoji characters that result in a new meaning, such as the sequence that is used to specify the astronaut emoji, into localized text for display and as plain text for input to a text to speech system. ? The display being, expressed by applying a sequence of glyph index values, one of ? instead of the emoji, ? or the emoji, a space, and the localized text, ? or the emoji a space, and between a LEFT PARENTHESIS character and a RIGHT PARENTHESIS character the localized text. ? The localized text expressed as plain text being expressed as characters. ? > 2) Gather evidence of broad consensus that the new feature is > desirable. Well, if anyone chooses to say that the suggested new feature is desirable, then that would be great. ? > One person thinking that something is a good idea does not make it so. ? Well, it does to that person. ? It seems to be a well-known phenomenon with ideas being put forward, and I mean generally, I am not meaning just in this fourm, that people who think it is a good idea do not actually write and say so, the responses are mostly from people who express an objection of some sort. Also, if people are in employment then, whatever opinion is held, they might not be allowed to reply, it is only the person in charge who is allowed to reply. ? What is not known is whether any of the businesses that write software for font generation have already had a go at implementing this suggestion so as to be in a position to comment knowledgeably should this suggestion be raised for discussion at a meeting. ? A new idea can go from seeming to have zero acceptance to being regarded as accepted practice very quickly, even if there is quite a time elapsed before the sudden driven-by-positive-feedback transition takes place. ? Yet what is the official process for considering whether this suggestion will become included in the font standard please? ? William Overington ? Tuesday 1 October 2024 ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Tue Oct 1 21:41:24 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Tue, 1 Oct 2024 20:41:24 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <3ee7afcc.2503a.192499a0774.Webtop.250@btinternet.com> John Hudson replied. ? Thank you for replying. ? John Hudson wrote as follows. ? > You are proposing breaking something that already works in order to > make it work in a more convoluted and less useful way. ? I am not proposing breaking anything, I am suggesting an additional facility. ? I do not purport to know much about localization. So maybe I have got it wrong. ? So I will try to explain my thinking and readers can decide whether this is a new idea, and if so, what they opine about it and about my suggested new layout feature becoming added to the font standard. ? Around 2009 there was lots of discussion about whether to encode emoji each as a character in ISO/IEC 10646. ? I wondered what else could be encoded as a character. ? Letters, digits, punctuation, spaces, symbols - some of each of those had been encoded. ? "What about whole sentences?" I thought. ? So I did a thought experiment. ? Consider a sentence such as "It is snowing.". ? Suppose that that sentence is encoded as a character. ? So someone who wants to send the message "It is snowing." can look up the character, maybe from a printed list, or in a menu in an email program, and send it in an email to a friend. ? The friend can then find the meaning of the character, or a computer system can decode it automatically, and the message "It is snowing." becomes known to the friend. ? Yes, it could be done, but it is not of any use. ? I then realized that the decoding by or for the friend need not be into the same language, so the received message could have gone ("tunneled") through the language barrier. ? Oh! ? So the encoded character was a localizable sentence. ? Not localized. But localizable. ? So the significance of what I am suggesting is that the localization is at the receiving end of a communication, not at the sending end. ? So in the scenario that is in the slide show, the link repeated here for convenience, ? http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf ? Albert does not need to know the language in which Sonja works. ? Extending the simulation, Sonja can be sending out localizable emails to various people in various countries and upon receipt each email is localized into the language being used by the person at that location. ? So this suggestion is based on my opinion that that would be good to be able to do. I do not know if it can already be done. ? The only system of which I am aware that uses code numbers that can be used to send precise information through the language barrier is SNOMED CT a clinical terminology system, though the code numbers are not only for that purpose, they are used for accurate recording of clinical records within a country. ? William Overington ? Tuesday 1 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Wed Oct 2 19:34:53 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Wed, 2 Oct 2024 18:34:53 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <706dff48.1261.1924e4c904b.Webtop.188@btinternet.com> If anyone who is assessing the desirability of implementing the suggested new layout feature wishes to explore the details of how I imagine the conversations about seeking information through the language barrier about relatives and friends after a disaster are facilitated using encoded localizable sentences, the following documents are available. ? http://www.users.globalnet.co.uk/~ngo/A_List_of_Code_Numbers_and_English_Localizations_for_use_in_Research_on_Communication_through_the_Language_Barrier_using_encoded_Localizable_Sentences.pdf ? http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_second_novel_chapter_002.pdf ? http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_second_novel_chapter_006.pdf ? http://www.users.globalnet.co.uk/~ngo/locse027.pdf ? http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_novel_chapter_042.pdf ? The talk in the caf? was before the introduction of the exclamation mark way of expressing a code number. ? That starting in Chapter 46. ? http://www.users.globalnet.co.uk/~ngo/localizable_sentences_the_novel_chapter_046.pdf ? The font is available here. ? http://www.users.globalnet.co.uk/~ngo/LOCSE977.TTF ? It just has the glyphs available in the Private Use Area for convenience of use to produce illustrations. ? William Overington ? Wednesday 2 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconstable at microsoft.com Thu Oct 3 01:33:30 2024 From: pconstable at microsoft.com (Peter Constable) Date: Wed, 2 Oct 2024 23:33:30 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Text of ISO/IEC 14496-22/CD is now available for review In-Reply-To: References: Message-ID: Murata: The Directives (Part 2, clause 7) are clear about statements regarding requirements (use ?shall? or ?shall not?), recommendations (use ?should? / ?should not?) and permission (use ?may?). It also describes words to use to describe possibilities: use ?can? or ?cannot?. However, the latter doesn?t adequately cover the scenario of possibility of a non-event. ?Can? means that an event could occur???>0% possibility; ?cannot? means the event will not occur???0% possibility. But it doesn?t recommend language when you want to advise the reader of <100% possibility, i.e., the possibility the event does not occur. While I haven?t checked all occurrences of ?may not?, the occurrences I did check were all attempting to state the possibility of non-occurrence. If you are aware of terminology guidance in the Directives for that situation, I?d be interested to know where it is. Regards, Peter Constable From: mpeg-otspec On Behalf Of MURATA via mpeg-otspec Sent: Friday, July 12, 2024 4:37 PM To: MPEG OT Spec list (mpeg-otspec at lists.aau.at) Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Text of ISO/IEC 14496-22/CD is now available for review To the editors, I have not read this CD carefully yet, but I am happy to report that neither "MUST" nor "must" appears in this document. Unfortunately, "may not" is still used. I will try to make JP raise a comment. While editing the OOXML specification (ISO/IEC 29500-1, 2, 3, and 4), ISO instructed SC34/WG4 not to use normative modal verbs (such as "shall", "may", and "should") in non-normative descriptions such as examples and notes. So, I wrote a program for enumerating all such occurrences. I will modify this program and use it for this document. Regards, Makoto 2024?7?12?(?) 5:10 Vladimir Levantovsky via mpeg-otspec >: Dear all, The text of the Committee Draft of the 5th edition ISO/IEC 14496-22/CD "Open Font Format" is now available for download and review: https://www.mpeg.org/wp-content/uploads/mpeg_meetings/146_Rennes/w23797.zip Once the ballot is open, any changes you wish to make in the current text need to be submitted via your respective National Bodies as comments, using the following ISO commenting template. The CD text is available for download as both "tracked changes" and "clean" versions - when submitting comments, please reference the clean version of the text for clarity and correct page number references. Please note that if the proposed change requires a substantial amount of text to be replaced, it is allowed to submit a comment referencing a future input contribution document with detailed proposed changes. Any such document would have to be registered and uploaded in advance - to reserve the document number and provide comments prior to ballot closing date (which is yet to be announced). Please also note that different National Bodies have their own additional processes for comments submission and may impose earlier deadlines than the ballot closing date. Thank you for your contributions and hard work! Vladimir _______________________________________________ mpeg-otspec mailing list mpeg-otspec at lists.aau.at https://lists.aau.at/mailman/listinfo/mpeg-otspec -- -- ???????????????????? ???? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconstable at microsoft.com Thu Oct 3 01:56:43 2024 From: pconstable at microsoft.com (Peter Constable) Date: Wed, 2 Oct 2024 23:56:43 +0000 Subject: [MPEG-OTSPEC] [EXTERNAL] Many to many substitution and localization In-Reply-To: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com> References: <2ec50151.2e2c.1922f4a8d25.Webtop.155@btinternet.com> Message-ID: FYI, this topic has been brought up in the past in the Unicode email discussion list. After the idea was broadly panned, it continued to be raised, sometimes with slightly details. After repeated requests and broad consensus (in the ISO sense) for the topic to be dropped, the originator continued, and the list moderator eventually had to intervene. I suggest that people stop responding on this topic. Peter Constable -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Thu Oct 3 14:31:59 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Thu, 3 Oct 2024 13:31:59 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <351c95c2.5d3.192525d9bc6.Webtop.51@btinternet.com> I gather that some people may have found it impossible to access the documents to which I linked in my previous post in this thread. ? One possible problem is that the server is http and not https and maybe some email systems are treating that as unsafe. ? Yet, as I understand it, http is only possibly unsafe if one is sending information to the server as potentially other people could read it. ? The reason that it is http and not https is that it is a "Free website with dial-up internet" from 1997. We went over to broadband around early 2000s but kept the dial up just so as to keep the website, not actually doing any dialling up as such after then. When they finally closed the dial-up facility in 2014 or thereabouts, they kindly let those people who already were using their "free-with" website keep it. I do not know if it will make any difference but trying to use the links from the archive might possibly give a different result. ? https://lists.aau.at/pipermail/mpeg-otspec/2024-October/003497.html ? https://lists.aau.at/pipermail/mpeg-otspec/2024-October/date.html ? William Overington ? Thursday 3 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eb2mmrt at gmail.com Thu Oct 3 15:09:38 2024 From: eb2mmrt at gmail.com (MURATA) Date: Thu, 3 Oct 2024 22:09:38 +0900 Subject: [MPEG-OTSPEC] [EXTERNAL] Re: Text of ISO/IEC 14496-22/CD is now available for review In-Reply-To: References: Message-ID: Peter, 2024?10?3?(?) 8:33 Peter Constable : > Murata: > > > > The Directives (Part 2, clause 7) are clear about statements regarding > requirements (use ?shall? or ?shall not?), recommendations (use ?should? / > ?should not?) and permission (use ?may?). It also describes words to use to > describe possibilities: use ?can? or ?cannot?. > > > > However, the latter doesn?t adequately cover the scenario of possibility > of a non-event. ?Can? means that an event could occur ? >0% possibility; > ?cannot? means the event will not occur ? 0% possibility. But it doesn?t > recommend language when you want to advise the reader of <100% possibility, > i.e., the possibility the event does not occur. While I haven?t checked all > occurrences of ?may not?, the occurrences I did check were all attempting > to state the possibility of non-occurrence. > > > > If you are aware of terminology guidance in the Directives for that > situation, I?d be interested to know where it is. > I know Directives, Part 2 and ISO House Style. I am not aware of any other guidelines. The interpretation of these guidelines by our Editorial Program Manager in ISO/CS is authoritative. Who is that person in SC29? Whenever we have a question, we should contact that person. Regards, Makoto > > > > > > > Regards, > > Peter Constable > > > > *From:* mpeg-otspec *On Behalf Of *MURATA > via mpeg-otspec > *Sent:* Friday, July 12, 2024 4:37 PM > *To:* MPEG OT Spec list (mpeg-otspec at lists.aau.at) < > mpeg-otspec at lists.aau.at> > *Subject:* [EXTERNAL] Re: [MPEG-OTSPEC] Text of ISO/IEC 14496-22/CD is > now available for review > > > > To the editors, > > > > I have not read this CD carefully yet, but I am happy to report that > neither "MUST" nor "must" appears in this document. > > > > Unfortunately, "may not" is still used. I will try to make JP raise a > comment. > > > > While editing the OOXML specification (ISO/IEC 29500-1, 2, 3, and 4), ISO > instructed SC34/WG4 not to use normative modal verbs (such as "shall", > "may", and "should") in non-normative descriptions such as examples and > notes. So, I wrote a program for enumerating all such occurrences. I will > modify this program and use it for this document. > > > > Regards, > > Makoto > > > > 2024?7?12?(?) 5:10 Vladimir Levantovsky via mpeg-otspec < > mpeg-otspec at lists.aau.at>: > > Dear all, > > > > The text of the Committee Draft of the 5th edition ISO/IEC 14496-22/CD > "Open Font Format" is now available for download and review: > > https://www.mpeg.org/wp-content/uploads/mpeg_meetings/146_Rennes/w23797.zip > > > > Once the ballot is open, any changes you wish to make in the current text > need to be submitted via your respective National Bodies as comments, using > the following ISO commenting template > . > The CD text is available for download as both "tracked changes" and "clean" > versions - when submitting comments, please reference the clean version of > the text for clarity and correct page number references. > > > > Please note that if the proposed change requires a substantial amount of > text to be replaced, it is allowed to submit a comment referencing a future > input contribution document with detailed proposed changes. Any such > document would have to be registered and uploaded in advance - to reserve > the document number and provide comments prior to ballot closing date > (which is yet to be announced). > > Please also note that different National Bodies have their own additional > processes for comments submission and may impose earlier deadlines than the > ballot closing date. > > > > Thank you for your contributions and hard work! > > Vladimir > > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > > > > > -- > > -- > > ???????????????????? > > ?? ? > -- -- ???????????????????? ?? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Thu Oct 3 15:22:47 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Thu, 3 Oct 2024 14:22:47 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <7309d06.84f.192528c1cc9.Webtop.51@btinternet.com> Peter Constable wrote as follows. ? > FYI, this topic has been brought up in the past in the Unicode email > discussion list. ? In the list to which reference is made I suggested encoding each localizable sentence as a single character, possibly in plane 7 or plane 13. ? Later I suggested encoding each localizable sentence as a base character followed by a sequence of tag characters. ? Neither suggestion was successful. ? So I am using a sequence of an exclamation mark and some ordinary digit characters as a way to continue with my research and its applications. ? I have also used a sequence of an integral sign followed by some circled digit characters.? ? This discussion, in this mailing list, is about a suggestion for an additional feature in the font standard. ? > I suggest that people stop responding on this topic. ? Why, exactly, precisely? ? This mailing list is the place to put forward a suggestion for an additional feature in the font standard and for it to be discussed. The mailing list is open for all to participate if they so choose. ? William Overington ? Thursday 3 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at tiro.ca Thu Oct 3 17:34:06 2024 From: john at tiro.ca (John Hudson) Date: Thu, 3 Oct 2024 08:34:06 -0700 Subject: [MPEG-OTSPEC] Many to many substitution and localization In-Reply-To: <3ee7afcc.2503a.192499a0774.Webtop.250@btinternet.com> References: <3ee7afcc.2503a.192499a0774.Webtop.250@btinternet.com> Message-ID: a) everything you have described involves characters, not glyphs. b) machine translation already works at the receiving end, and is able to handle arbitrary text (and speech) rather than being limited to a set of string localisations. JH On 2024-10-01 12:41, William_J_G Overington via mpeg-otspec wrote: > > John Hudson replied. > > > Thank you for replying. > > > John Hudson wrote as follows. > > > > You are proposing breaking something that already works in order to > make it work in a more convoluted and less useful way. > > > I am not proposing breaking anything, I am suggesting an additional > facility. > > > I do not purport to know much about localization. So maybe I have got > it wrong. > > > So I will try to explain my thinking and readers can decide whether > this is a new idea, and if so, what they opine about it and about my > suggested new layout feature becoming added to the font standard. > > > Around 2009 there was lots of discussion about whether to encode emoji > each as a character in ISO/IEC 10646. > > > I wondered what else could be encoded as a character. > > > Letters, digits, punctuation, spaces, symbols - some of each of those > had been encoded. > > > "What about whole sentences?" I thought. > > > So I did a thought experiment. > > > Consider a sentence such as "It is snowing.". > > > Suppose that that sentence is encoded as a character. > > > So someone who wants to send the message "It is snowing." can look up > the character, maybe from a printed list, or in a menu in an email > program, and send it in an email to a friend. > > > The friend can then find the meaning of the character, or a computer > system can decode it automatically, and the message "It is snowing." > becomes known to the friend. > > > Yes, it could be done, but it is not of any use. > > > I then realized that the decoding by or for the friend need not be > into the same language, so the received message could have gone > ("tunneled") through the language barrier. > > > Oh! > > > So the encoded character was a localizable sentence. > > > Not localized. But localizable. > > > So the significance of what I am suggesting is that the localization > is at the receiving end of a communication, not at the sending end. > > > So in the scenario that is in the slide show, the link repeated here > for convenience, > > > http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf > > > > Albert does not need to know the language in which Sonja works. > > > Extending the simulation, Sonja can be sending out localizable emails > to various people in various countries and upon receipt each email is > localized into the language being used by the person at that location. > > > So this suggestion is based on my opinion that that would be good to > be able to do. I do not know if it can already be done. > > > The only system of which I am aware that uses code numbers that can be > used to send precise information through the language barrier is > SNOMED CT a clinical terminology system, though the code numbers are > not only for that purpose, they are used for accurate recording of > clinical records within a country. > > > William Overington > > > Tuesday 1 October 2024 > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec -- John Hudson Tiro Typeworks Ltdwww.tiro.com Tiro Typeworks is physically located on islands in the?Salish Sea, on the traditional territory of the?Snuneymuxw?and Penelakut First Nations. __________ EMAIL HOUR In the interests of productivity, I am only dealing with email towards the end of the day, typically between 4PM and 5PM. If you need to contact me more urgently, please use other means. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Mon Oct 7 09:45:56 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Mon, 7 Oct 2024 08:45:56 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: John Hudson wrote as follows. ? > a) everything you have described involves characters, not glyphs. ? Well, in that particular post, yes, but the whole suggestion for an additional layout feature for a font involves both characters and glyphs, applied together to convey message content and present that message content in a display. ? > b) machine translation already works at the receiving end, and is able > to handle arbitrary text (and speech) rather than being limited to a > set of string localisations. ? To some level of accuracy. I am not very knowledgeable about machine translation. I have used it to possibly get some level of understanding of a text that is not in English by translating text from a language other than English into English, but that is not the same as precise translation by a human expert linguist fluent in both languages who is a native speaker of English. ? Yes, what I am suggesting does involve a limited set of string localizations, yet those localizations would have been prepared by a human expert linguist who is a native speaker of the language into which the localization is made. That is important for provenance of the precision of the translation. ? ---- ? Some years ago, as a result of my posting about localizable sentences in another mailing list, a helpful person sent me a link about some interesting and important work in France about lists of translations of particular sentences. ? Here is a link to a recent article. ? https://www.connexionfrance.com/news/french-nurses-translation-tool-helps-give-care-in-101-languages/473481 ? There are two links to the OuiKer website in the article, the first one does not work here, but the second one does. ? William Overington ? Monday 7 October 2024 ? ?? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From skef at skef.org Tue Oct 15 01:39:24 2024 From: skef at skef.org (Skef Iterum) Date: Mon, 14 Oct 2024 16:39:24 -0700 Subject: [MPEG-OTSPEC] Direct variable font support in Adobe OpenType Feature Files: Change review Message-ID: Hello?I hope everyone can forgive a slight abuse of this list ... The Adobe Type Team has been working to extend the OpenType Feature File Specification to add direct support for Variable fonts. We are introducing the specification changes in two stages: * ?Stage 1 adds support for variable values * ?Stage 2 will add support for feature variations (such as swapping one glyph for another based on axis range conditions) The stage 1 changes are now in a public review period that will end January 15th 2025. The review repository is: https://github.com/adobe-type-tools/feature_file_change_review/ Any further discussion of this topic should of course happen in that repository, as the Feature File Specification and the Open Font Format specification are only loosely related. Feature files are used in the development of many fonts, sometimes directly and sometimes "under the hood". We expect these changes will be of most interest to tool developers and designers of fonts with extensive or unusual GSUB or GPOS features. The top-level README of the review repository has more information on the review process and guidance on whether and how you may want to participate. I will be rolling out the announcement of this review across other channels over the next few days. Thanks, Skef Iterum Adobe Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Thu Oct 17 11:05:18 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Thu, 17 Oct 2024 10:05:18 +0100 (BST) Subject: [MPEG-OTSPEC] Many to many substitution and localization Message-ID: <5f5bad08.972.19299b96997.Webtop.122@btinternet.com> Many to many substitution and localization ? Can this suggestion go forward for consideration to become included in the Open Font Format please? ? William Overington ? Thursday 17 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From behdad at behdad.org Wed Oct 23 00:17:15 2024 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 22 Oct 2024 16:17:15 -0600 Subject: [MPEG-OTSPEC] CFF2 errata Message-ID: Hi everyone, CFF2 has a file size advantage over TrueType-flavored variable fonts, specially if one doesn't care about hinting (Android, Apple platforms, etc) but does care about (uncompressed) size. CFF2 also alleviates some other limitations of variable-fonts built against the gvar table. Unfortunately, it imposes its own limitations. These are among the issues I'm going to raise. Please see: https://github.com/harfbuzz/boring-expansion-spec/issues/155 for details of the changes I am proposing. Ideally, Adobe folks choose to turn these ideas into proposals and push it through the OFF standardization / OpenType integration process. Failing that, we might want to go ahead and do it at Google Thanks, behdad http://behdad.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmccully at adobe.com Thu Oct 24 00:24:17 2024 From: nmccully at adobe.com (Nat McCully) Date: Wed, 23 Oct 2024 22:24:17 +0000 Subject: [MPEG-OTSPEC] My personal comments on the CD In-Reply-To: <6a504d858f55e10cc457a3bd23571bebc6fa08bb.camel@fromoldbooks.org> References: <6a504d858f55e10cc457a3bd23571bebc6fa08bb.camel@fromoldbooks.org> Message-ID: A little late, here are the final edits that Japan will submit for the 'apkn' proposal. Nat McCully | Principal Scientist | Adobe | T 206 675 7351 | C 206 409 0624 | nmccully at adobe.com ________________________________ From: Liam R. E. Quin Sent: Sunday, September 29, 2024 16:56 To: Nat McCully ; mpeg-otspec ; MURATA ; kida at mac.com Subject: Re: [MPEG-OTSPEC] My personal comments on the CD EXTERNAL: Use caution when clicking on links or opening attachments. On Sun, 2024-09-29 at 21:33 +0000, Nat McCully via mpeg-otspec wrote: Here are my comments in the template, for tonight's discussion with the Japan body Just for myself, i think those are very helpful clarifications, especially for implementers. liam -- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nmccully comments for ISO14496-22.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 31115 bytes Desc: nmccully comments for ISO14496-22.docx URL: From vladimir.levantovsky at gmail.com Thu Oct 24 20:56:22 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Thu, 24 Oct 2024 14:56:22 -0400 Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines Message-ID: Dear AHG members, I would like to remind you that the deadlines for registration and submission of input contributions for the upcoming SC29/WG3 meeting are approaching: Document registration: Monday, Oct.28, 23:59 UTC Document submission: Wednesday, Oct. 30, 23:59 UTC If you plan to submit an input contribution, either to complement previously submitted ballot comment or bring additional information for consideration at the next WG meeting (to be held on Nov. 4-8, 2024) - please be certain to register and upload your submissions before the deadlines. Thank you, Vladimir -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Thu Oct 24 23:56:03 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Thu, 24 Oct 2024 22:56:03 +0100 (BST) Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines In-Reply-To: References: Message-ID: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> Vladimir Levantovsky wrote as follows. ? > If you plan to submit an input contribution, either to complement > previously submitted ballot comment or bring additional information > for consideration at the next WG meeting (to be held on Nov.?4-8, > 2024) - please be certain to register and upload your submissions > before the deadlines. ? Can you write about the required format for an input contribution and about how one registers and uploads a submission please? ? William Overington ? Thursday 24 October 2024 ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Fri Oct 25 04:15:13 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Thu, 24 Oct 2024 22:15:13 -0400 Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines In-Reply-To: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> References: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> Message-ID: > Can you write about the required format for an input contribution and about how one registers and uploads a submission please? > ISO Working Group meetings are not open to general public, they?re open only to registered delegates that are nominated as Working Group experts by their respective National Bodies. You need to contact your national standards organization to further inquire on the process and requirements, and they are the only entity that is authorized to share procedural details and login credentials with registered WG delegates. Once you become an NB member nominated as the WG delegate, you would be eligible to gain access to members-only WG resources, including documents registry. I also need to remind you that although this ad-hoc group and the associated mailing list are accessible to public, we operate according to ISO rules. You do need to be a registered delegate nominated by your NB. Also, our scope of work is limited by what is expressly defined by the Working Group mandates. These mandates are approved at WG meetings - participants of this AHG are not at liberty to amend them. Thank you, Vladimir > On Oct 24, 2024, at 5:56?PM, William_J_G Overington via mpeg-otspec wrote: > > ? > Vladimir Levantovsky wrote as follows. > > > > If you plan to submit an input contribution, either to complement previously submitted ballot comment or bring additional information for consideration at the next WG meeting (to be held on Nov. 4-8, 2024) - please be certain to register and upload your submissions before the deadlines. > > > Can you write about the required format for an input contribution and about how one registers and uploads a submission please? > > > William Overington > > > Thursday 24 October 2024 > > > > > > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Fri Oct 25 18:55:24 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Fri, 25 Oct 2024 17:55:24 +0100 (BST) Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines In-Reply-To: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> References: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> Message-ID: <230f035.182c8.192c49aac97.Webtop.200@btinternet.com> Vladimir Levantovsky kindly replied to my enquiry. ? Thank you for replying. ? Vladimir Levantovsky wrote as follows. ? > ISO Working Group meetings are not open to general public, they?re > open only to registered delegates that are nominated as Working Group > experts by their respective National Bodies. ? I was not seeking to participate in the meeting. I was simply hoping to send a document about my idea for a Many to many substitution and localization feature to be added. ? > Once you become an NB member nominated as the WG delegate, you would > be eligible to gain access to members-only WG resources, including > documents registry. ? I do not have the necessary expertise in font technology to perform such a role. I have made a few fonts, including some with glyphs for symbols that I have designed in relation to my research in communication through the language barrier in some particular circumstances using encoded localizable sentences, but I am not an expert in font technology. ? > I also need to remind you that although this ad-hoc group and the > associated mailing list are accessible to public, we operate according > to ISO rules. You do need to be a registered delegate nominated by > your NB. ? Oh! I did not know that. Though in fairness, there is nothing about that on the ? https://lists.aau.at/mailman/listinfo/mpeg-otspec ? webpage. It looks like anyone can join and post. ? I do not know what are the ISO rules. ? Should my suggestion of a Many to many substitution and localization feature not have been posted in this mailing list? ? > Also, our scope of work is limited by what is expressly defined by the > Working Group mandates. These mandates are approved at WG meetings - > participants of this AHG are not at liberty to amend them. ? Is there a way that a future Working Group mandate could include a Many to many substitution and localization feature please? ? William Overington ? Friday 25 October 2024 ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.levantovsky at gmail.com Fri Oct 25 19:32:43 2024 From: vladimir.levantovsky at gmail.com (Vladimir Levantovsky) Date: Fri, 25 Oct 2024 13:32:43 -0400 Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines In-Reply-To: <230f035.182c8.192c49aac97.Webtop.200@btinternet.com> References: <69efd62f.158d4.192c08792f5.Webtop.140@btinternet.com> <230f035.182c8.192c49aac97.Webtop.200@btinternet.com> Message-ID: William Overington wrote: I was not seeking to participate in the meeting. I was simply hoping to send a document about my idea for a Many to many substitution and localization feature to be added. And if you do so, your document would end up being seen by the same group of experts that already gave you very elaborate detailed feedback on your idea. I do not know what are the ISO rules. Our work is governed by the Declaration for participants in ISO activities and by the ISO Directives . Should my suggestion of a Many to many substitution and localization feature not have been posted in this mailing list? At some point in time, the AHG mandates included exploration activities of new technologies, but since the new 5th edition text is now finalized, no new proposals can be accepted at this time. Besides, your idea has already received a preliminary review of experts and has been rejected primarily because it violates the basic principles of separation between textual content and its visual representation. Is there a way that a future Working Group mandate could include a Many to many substitution and localization feature please? No, because the mandates for future work are developed by consensus of the Working Group experts. Your idea has already been discussed at lengths, and the reasons for its rejection have been clearly stated. Repeated discussions of the same idea are not going to yield a different outcome. With kind regards, Vladimir On Fri, Oct 25, 2024 at 12:55?PM William_J_G Overington via mpeg-otspec < mpeg-otspec at lists.aau.at> wrote: > Vladimir Levantovsky kindly replied to my enquiry. > > > Thank you for replying. > > > Vladimir Levantovsky wrote as follows. > > > > ISO Working Group meetings are not open to general public, they?re open > only to registered delegates that are nominated as Working Group experts by > their respective National Bodies. > > > I was not seeking to participate in the meeting. I was simply hoping to > send a document about my idea for a Many to many substitution and > localization feature to be added. > > > > Once you become an NB member nominated as the WG delegate, you would be > eligible to gain access to members-only WG resources, including documents > registry. > > > I do not have the necessary expertise in font technology to perform such a > role. I have made a few fonts, including some with glyphs for symbols that > I have designed in relation to my research in communication through the > language barrier in some particular circumstances using encoded localizable > sentences, but I am not an expert in font technology. > > > > I also need to remind you that although this ad-hoc group and the > associated mailing list are accessible to public, we operate according to > ISO rules. You do need to be a registered delegate nominated by your NB. > > > Oh! I did not know that. Though in fairness, there is nothing about that > on the > > > https://lists.aau.at/mailman/listinfo/mpeg-otspec > > > webpage. It looks like anyone can join and post. > > > I do not know what are the ISO rules. > > > Should my suggestion of a Many to many substitution and localization > feature not have been posted in this mailing list? > > > > Also, our scope of work is limited by what is expressly defined by the > Working Group mandates. These mandates are approved at WG meetings - > participants of this AHG are not at liberty to amend them. > > > Is there a way that a future Working Group mandate could include a Many to > many substitution and localization feature please? > > > William Overington > > > Friday 25 October 2024 > > > > _______________________________________________ > mpeg-otspec mailing list > mpeg-otspec at lists.aau.at > https://lists.aau.at/mailman/listinfo/mpeg-otspec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wjgo_10009 at btinternet.com Fri Oct 25 21:06:42 2024 From: wjgo_10009 at btinternet.com (William_J_G Overington) Date: Fri, 25 Oct 2024 20:06:42 +0100 (BST) Subject: [MPEG-OTSPEC] Input contributions - upcoming registration and submission deadlines In-Reply-To: <230f035.182c8.192c49aac97.Webtop.200@btinternet.com> References: <230f035.182c8.192c49aac97.Webtop.200@btinternet.com> Message-ID: <8391490.354a.192c512e4bc.Webtop.122@btinternet.com> Vladimir Levantovsky kindly replied to my post. ? Thank you for your reply. ? Best regards, ? William ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: