<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Helvetica Neue";
panose-1:2 0 5 3 0 0 0 2 0 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">This discussion is getting very focused on CJK. That was the original context for which Apple started the discussion back in 2016, and pan-CJK fonts are certainly a significant use case for a ‘dmap’ table.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But the potential benefit of a dmap table is not just for pan-CJK fonts. There are many reasons why TTCs get created. Windows has 28 .ttc files, none of which are for pan-CJK fonts. (Most are single-region
CJK fonts; three are Thai and one is Latin.) <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">A key reason for creating a TTC is size savings by de-duplication of data, and the cmap table is one of the larger tables in fonts for which there’s potential to de-duplicate—especially in CJK fonts but not
only CJK fonts.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">From:
</span></b><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">mpeg-otspec <mpeg-otspec-bounces@lists.aau.at> on behalf of Hin-Tak Leung <htl10@users.sourceforge.net><br>
<b>Date: </b>Friday, December 22, 2023 at 8:54</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"> </span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">AM<br>
<b>To: </b>Ken Lunde <lunde@unicode.org>, Skef Iterum <skef@skef.org><br>
<b>Cc: </b>mpeg-otspec@lists.aau.at <mpeg-otspec@lists.aau.at><br>
<b>Subject: </b>[EXTERNAL] Re: [MPEG-OTSPEC] dmap proposal<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">From a user's perspective (I am native to one of the 5/6), it is easier to have a system-wide configuration, as in I want *all* my applications to prefer one of the 5/6, unless
specifically overridden per usage instance. Hence a named subfont is more attractive, compared to locl/lang features to be applied per paragraph/sentence. Yes, I guess you can argue for applying specific locl/lang tags unless overridden too; but as Ken said,
applications supporting tags are rare...<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">For those who care about the subtle differences between Taiwan & HK variant of traditional Chinese, the Taiwan MOE (ministry of education) have/had a document somewhere on their
web site about common mis-writings and the "correct" variants among historical forms of various characters (numbers in the hundreds, so it is sizeable but small compared to the 10k/20k daily usage size). The difference is legally important for those who notice
the difference.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">I am surprised there isn't a 6th - Singapore variant of simplified Chinese.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">dmap (and ttc subfonts with different dmaps) has the advantage that it is seen as a more system-wide feature, at least in existing usage of ttc sub fonts.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">I like the idea of ttc subfonts having some locl/lang features on by default.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""><o:p> </o:p></span></p>
</div>
<div id="ydp93314d83yahoo_quoted_3800566910">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue";color:#26282A">On Friday, 22 December 2023 at 07:58:17 GMT, Skef Iterum <skef@skef.org> wrote:
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue";color:#26282A"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue";color:#26282A"><o:p> </o:p></span></p>
</div>
<div>
<div id="ydp93314d83yiv9637583505">
<div>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">I stand dystopianed.
<o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">However, to not yet give up entirely on this line of thinking ...<o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">What is on the table in these messages is a further extension of an existing table, in this case cmap. Which at least suggests that the problem here isn't "system-level" support --
we think we can get those changes. What you describe is, loosely speaking, "application level" support -- allowing the context that the user interacts with to specify the needed parameters, and then educating the user to do so.<o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">I agree that's hopeless for the foreseeable future.
<o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">These dmap ideas do have the benefit of being
<i>somewhat</i> general (although one might worry about unusual cases). Maybe other compelling use cases, or just the value of generality itself, justify such an extension. Still, if the fundamental problems are what you describe, we might also consider addressing
them directly and specifically. Instead of extending cmap, and building region- or language-specific fonts via a separate mechanism, we should at least consider extending TTC to associate a named subfont with the missing parameters. Basically: "render this
set of tables using this script and this language by default". Done a bit subtly, one could just ship every cross-language font file with a "base" font with just the name, and some entries for other scripts and language, suitably named, and otherwise sharing
TTC data-structures. <o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">From the perspective of the font engineer that seems more productive than building a cross-language font with one set of mechanisms and then building multiple data-sharing individual
language fonts using a different mechanism (assuming we still want engineers to do the former).<o:p></o:p></span></p>
<p><span style="font-size:10.0pt;font-family:"Helvetica Neue";color:#26282A">Skef<o:p></o:p></span></p>
<div id="ydp93314d83yiv9637583505yqtfd30427">
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue";color:#26282A">On 12/21/23 18:15, Ken Lunde wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span style="color:#26282A">Skef,<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">I might be the only one in this discussion who clearly remembers that Version 1.000 of Source Han Sans and Noto Sans CJK, which were released on 2014-07-15, *was* utopian in that the fonts with the full set of 64K glyphs, meaning genuine Pan-CJK, expected that language tagging would be used to access the desired non-default region-specific glyphs, with the default glyphs being for Japan. Reality quickly taught us that expecting language tagging alone to solve this was completely unrealistic for the following three reasons:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">1) The app must support language tagging<o:p></o:p></span></pre>
<pre><span style="color:#26282A">2) The app must support language tagging for the appropriate East Asian languages, which is now up to five for these Pan-CJK fonts<o:p></o:p></span></pre>
<pre><span style="color:#26282A">3) Assuming #1 and #2 work, the user must then language-tag the text<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">Going on 10 years later, not much has changed for #1 and #2.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">Modern browsers supported the 'locl' GSUB feature way back in 2014, but support in authoring apps is still severely lacking today.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">I use Adobe InDesign to get full language-tagging support for these fonts, which is still about the only game in town. Adobe Illustrator silently added East Asian language-tagging in the 2018 release (in 2017), but it was a "close but no cigar" outcome in that they added only "Chinese" (that turned out to be Traditional Chinese for Taiwan) and Japanese, and despite filing bugs over five years ago, Adobe Illustrator 2024 (in 2023) is still unchanged in this regard. What makes the current support even less useful for mainstream users, ignoring that three of the five East Asian regions are not supported at all, is that the two supported East Asian regions are visible only when creating Character or Paragraph styles. They are not shown in the list of languages in the Character or Properties panels. Adobe Photoshop 2024 (in 2023) still does not support language tagging for East Asian languages.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">Getting back to Source Han Sans and Noto Sans CJK, Version 1.001 was released on 2014-09-12, which added separate 64K-glyph fonts for each of the four (at the time) supported East Asian regions. The 'locl' feature is still included for the benefit of those environments that support language tagging. All five regions were not supported until Version 2.000, which was released on 2018-11-19, which meant five separate sets of 64K-glyph fonts. The fifth region, of course, was Hong Kong SAR.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">In other words, we are quite far from Utopia, and we are unlikely to arrive there anytime soon.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">Regards...<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">-- Ken<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span style="color:#26282A">On Dec 21, 2023, at 17:04, Skef Iterum <a href="mailto:skef@skef.org" target="_blank"><skef@skef.org></a> wrote:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
<pre><span style="color:#26282A">More stuff after hitting send too fast:<o:p></o:p></span></pre>
<pre><span style="color:#26282A">I can see a set of arguments against trying to deal with these regional problems within a single mega-font grounded one way or another in GIDs being a limited resource. But we've already decided to overcome that problem. So, for example, if we need to spend a GID to, in effect, abstractly represent a given codepoint to bridge from cmap into the shaping tables, we have GIDs to spend now. (And, as implied in my other messages today, wouldn't necessarily have to pay the typical file overhead for them.)<o:p></o:p></span></pre>
<pre><span style="color:#26282A">As I understand it that's how regional variations in, e.g., Cyrillic are handled now. So I guess, other than the large number of glyphs in CJK fonts I'm not understanding what requirements are pushing the solution in such a different (and seemingly ad hoc) direction.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">Skef<o:p></o:p></span></pre>
<pre><span style="color:#26282A">On 12/21/23 16:49, Skef Iterum wrote:<o:p></o:p></span></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span style="color:#26282A">Maybe I'm being utopian but I can't help thinking that either there's some token ("dialect"?) that Unicode should be tracking and formalizing but isn't, or Unicode is doing that and we haven't tilted the font specifications enough in its direction to use it. There's already all of that script and language infrastructure there that is meant for this flavor of need, and it seems like a much better place to be solving these problems than rapping stuff up in a TTC and having the client side pick out the sub-font by name or whatever.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">Skef<o:p></o:p></span></pre>
<pre><span style="color:#26282A">On 12/21/23 15:00, Peter Constable wrote:<o:p></o:p></span></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><span style="color:#26282A">During the recent AHG meeting, I mentioned that Apple, Adobe and Microsoft, some years ago, had started discussing a ‘dmap’ (delta character map) table proposal. This was in late fall of 2016; the focus was on pan-CJK fonts, and in that timeframe Ken Lunde has submitted a proposal to UTC (L2/16-063 Proposal to accept the submission to register the “PanCJKV” IVD collection) to define variation sequences for ideographs that designated a range of variation selector characters to correspond to several regions for which regional glyph variants of CJK ideographs might need to be supported. I managed to find an archive of some emails from discussions at the time, so can summarize:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> The aim was to be able to support distinct fonts for regional CJK variants without duplication of data. A TTC could allow de-duplication of glyph data, but there would be other duplication. We agreed the biggest concern was with ‘cmap’ data: If any one of the regional variant fonts in the collection were taken as a point of reference, then any of the other regional variants would have many of the same mappings (perhaps most), though not all the same mappings. But there wasn’t any existing means to share common mappings across fonts while there were also some different mappings. Dwane Robinson suggested that we define a new ‘dmap’ table that uses ‘cmap’ formats but is just used to describe the differences in mappings from a common ‘cmap’. We agreed that a ‘dmap’ table doesn’t need the duplication of different platforms/encodings, and that we can converge on only one platform/encoding (hence, no encoding records are necessary). We discussed format 4 versus 12, and agreed to allow either, but that both are never required. Now, we had teleconfs between Apple and MS, but the emails I found indicate that Behdad was also kept informed: one of the emails records that Behdad requested that format 13 also be allowed.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> We hadn’t settled, however, on what to do about format 14 subtables. It wasn’t a priority for Apple at the time, but it seemed like it would be incomplete if we ignored it. Knowing that Ken Lunde was dealing a lot with VSes and also working on pan CJK Source Han Sans CJK, we brought Adobe into our discussion at that point.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> The issue with format 14 is that it divides variation sequences into two groups: (i) VSes that map to the same glyph already mapped in a format 4 or 12 subtable (DefaultUVS), and (ii) VSes that map to a different glyph. Certainly the default mappings would be different in the various regional variant fonts, and some of the non-default mappings could also be different. (Even if a given VS never mapped to different glyphs in the different fonts, the fonts could still differ in what VSes they need to support.) So it’s necessary to resolve how a dmap/14 subtable should interacts with a cmap/4 (or cmap/12) subtable, with a cmap/14 subtable, with a dmap/4 (or dmap/12) subtable, and with a dmap/14 subtable. One possible approach would be that the dmap/14 subtable completely supersedes the cmap/14 subtable (i.e., the latter is not used at all, and there is no de-duplication of that data). Another approach could be that a dmap/14 subtable complements the cmap/14 subtable by providing select replacement mappings (a delta—though there are still further details about how that would work exactly).<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> There were some useful points brought up along the way: <o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • Ned Holbrook pointed out that the format 14 DefaultUVS subtable is just a space-saving variant of the NonDevaultUVS subtable. A font doesn’t need to have any DefaultUVS table: the same sequences could be handled in NonDefaultUVS subtables — less efficiently… _in a single font_.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • For CJK, Ken Lunde pointed out that there are two kinds of UVSes to consider: <o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • “Standardized” VSs: these are defined in the Unicode Standard (see unicode.org/Public/UCD/latest/ucd/StandardizedVariants.txt) for CJK Compatibility Ideographs. They are defined in Unicode in a region-independent manner, but most represent region-specific glyphs.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • “Ideographic” VSes: these are VSes registered in the Ideographic Variation Database (Ideographic Variation Database (unicode.org)) in region-specific collections. <o:p></o:p></span></pre>
<pre><span style="color:#26282A">Because of the nature of each type, Ken thought there might be limited sharing across fonts. (E.g., at least some font developers would want to support a given IVS collection only in the one regional font for the corresponding region.) He did identify cases, however, in which the same SVS would need to map to different glyphs in different fonts.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • Again, for CJK, there would be cases in which different fonts would need to support the same VSes, but they would differ wrt DefaultUVS vs. NonDefaultUVS mappings.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> Ken also called out some other uses in email exchanges. It all suggested that an ideal solution would make it possible to construct a collection file in which - two or more fonts can share some UVS mapping data while also having some font-specific mapping data; and<o:p></o:p></span></pre>
<pre><span style="color:#26282A">- it's also possible to have other fonts that do not share any UVS mapping data with other fonts.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> That would allow the fonts to support only UVSs that are relevant for their respective markets, while also having an efficiency benefit from data-sharing between certain of the fonts.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> That was in December 2016. We ran into end-of-year holidays and never resumed to closed on an approach that optimizes size of VS mapping data. The following is the last draft proposal that we exchanged. —-<o:p></o:p></span></pre>
<pre><span style="color:#26282A">dmap - Character to Glyph Index Differences Table<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> This table is an optional adjunct to the ‘cmap’ table defining differences from the nominal mappings in order to increase sharing of the ‘cmap’ itself across fonts in a TTC.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> If a font production tool determines that the ‘cmap’ tables across the fonts in a TTC are largely but not entirely identical, it can choose one font to be used as the basis for the others in terms of character to glyph index mapping, expressing the mappings of the other fonts using only the mappings that are different from those of the former font. An example would be a CJK font family with region-specific fonts, where most characters would map to the same glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> The ‘dmap’ table<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> Type Name Description<o:p></o:p></span></pre>
<pre><span style="color:#26282A">UInt16 version Set to 0.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">UInt16 numTables Number of offset fields to follow.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">UInt32 offset[numTables] Array of byte offsets from beginning of table to cmap subtables. All subtables are assumed to use Unicode. There can be at most one subtable of either format 4, 12, or 13.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> As in the ‘cmap’ table, each ‘dmap’ subtable shall have the same structure as in ‘cmap’, starting with a format field that determines the remainder. The language field for a format 4, 12, or 13 subtable must be set to zero.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> The steps for determining the glyph index for a given UVS consisting of a base character and optional variation selector are as follows:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> <o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • Apply the Unicode ‘cmap’ subtable to the base character to get the nominal glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • If the font has a ‘dmap’ format 4 or 12 subtable that maps the base character to a non-zero glyph index, it will replace the nominal glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> • If the ‘cmap’ has a format 14 subtable, apply it in this way: <o:p></o:p></span></pre>
<pre><span style="color:#26282A">3.1.If the Default UVS Table contains the base character, the final glyph index will the be one determined by the ‘cmap’.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">3.2.Else if the Non-Default UVS Table contains the base character, it will determine the final glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">3.3.Else the final glyph index will remain as it was after step 2.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> Note: An earlier draft of this document allowed for a second subtable of format 14, which would allow redefinition of variation sequences. Owing to uncertainty about usefulness and the exact behavior of the Default UVS Table, however, it has been removed pending further discussion.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> —<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> In the previous draft, a different set of steps for handling UVSes were considered:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> —<o:p></o:p></span></pre>
<pre><span style="color:#26282A">The steps for determining the glyph index for a given UVS consisting of a base character and optional variation selector are as follows:<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> 1. Apply the ‘cmap’ to the base character to get the nominal glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">2. If the font has a ‘dmap’ format 4 or 12 subtable that maps the base character to a non-zero glyph index, it will replace the nominal glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">3. If the ‘dmap’ has a format 14 subtable, it will be used in place of the one in the ‘cmap’.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">4. If there is a format 14 subtable, apply it in this way:<o:p></o:p></span></pre>
<pre><span style="color:#26282A">4.1.If the Default UVS Table contains the base character, the final glyph index will the be one determined by the ‘cmap’.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">4.2.Else if the Non-Default UVS Table contains the base character, it will determine the final glyph index.<o:p></o:p></span></pre>
<pre><span style="color:#26282A">4.3.Else the final glyph index will remain as it was after step 2.<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> —<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> Peter<o:p></o:p></span></pre>
<pre><span style="color:#26282A"> <o:p></o:p></span></pre>
<pre><span style="color:#26282A">_______________________________________________<o:p></o:p></span></pre>
<pre><span style="color:#26282A">mpeg-otspec mailing list<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><o:p></o:p></span></pre>
<pre><span style="color:#26282A"><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><o:p></o:p></span></pre>
<pre><span style="color:#26282A"><o:p> </o:p></span></pre>
</blockquote>
</blockquote>
<pre><span style="color:#26282A">_______________________________________________<o:p></o:p></span></pre>
<pre><span style="color:#26282A">mpeg-otspec mailing list<o:p></o:p></span></pre>
<pre><span style="color:#26282A"><a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><o:p></o:p></span></pre>
<pre><span style="color:#26282A"><a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><o:p></o:p></span></pre>
</blockquote>
</blockquote>
</div>
</div>
</div>
<div id="ydp93314d83yqtfd97323">
<p class="MsoNormal"><span style="font-family:"Helvetica Neue";color:#26282A">_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>