<div dir="ltr"><div>Let's maybe not add some hacky workaround for broken/buggy fonts?</div><div> </div><div>Anyways, I like Jonathan's proposition (I was proposing quite similar patch something like a year ago); if it solves the described issue w/o additional hacks, here is yeat another +1 from me.</div></div><div class="gmail_extra"><br clear="all"><div>Regards,<br>Konstantin</div>
<br><div class="gmail_quote">2014-10-10 12:46 GMT+04:00 Jonathan Kew <span dir="ltr"><<a href="mailto:jfkthame@gmail.com" target="_blank">jfkthame@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 10/10/14 02:12, Behdad Esfahbod wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
I'm helping Dominik port Chrome's vertical text support to HarfBuzz, and we've<br>
hit a buggy font in Windows, that we need to work around.<br>
<br>
"SimSun" on Windows 7, only declares the 'vert' feature under script 'hani'<br>
(fine) language-system "CHN ".  No tag maps to "CHN ".  It's a font bug.<br>
<br>
In Windows 8 family, someone **tried** to fix it.  They tweaked the features<br>
until it worked for them.  So it has the 'vert' feature for script 'hani', now<br>
in language system "ZHS " as well as "CHN ", but also for script 'latn' as<br>
default language-system.  So now, if the itemizer failed to mark the correct<br>
script, HarfBuzz tries 'latn' and gets the right feature.  But if it looks<br>
under 'hani' but there's no language tag, it still fails.<br>
<br>
So, I'm tempted to try this fixup: if feature is 'vert', and we found no<br>
feature, then walk the feature list and enable the first feature found that<br>
has tag 'vert'.<br>
<br>
How does that sound?<br>
<br>
<a href="https://github.com/behdad/harfbuzz/issues/63" target="_blank">https://github.com/behdad/<u></u>harfbuzz/issues/63</a><br>
<br>
</blockquote>
<br></span>
Sounds like it would probably work, but this makes me really uneasy - it's too much of a hack. Yuck.<br>
<br>
Here's a proposal for an alternative fixup that *maybe* feels more acceptable to me (maybe, because I haven't thought about it for very long, and perhaps it's just as hackish really):<br>
<br>
If the script we're using has no matching langSys for the buffer's language, and if there's also no default langSys defined, then look for the "typical" language system(s) for the script (e.g. ENG for 'latn') - allowing this to be a list of tags, so that for 'hani', for instance, we could list ZHS, ZHT, JAN ... and we could append the unofficial CHN here.<br>
<br>
So we'd need to have a mapping of script tag -> langSys tag(s), often just one "prototypical" language that uses the script, but sometimes several candidates. This would address the comparable issue of a font that (for example) provides features only under arab/ARA (or deva/HIN), and is presented with text tagged as Persian (or Nepali)... ISTM it'd be better to use the Arabic- (or Hindi-) language features here than to fail altogether.<br>
<br>
(This is obviously related, though not identical, to the idea of Pango's pango_script_get_sample_<u></u>language function.)<br>
<br>
WDYT?<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
HarfBuzz mailing list<br>
<a href="mailto:HarfBuzz@lists.freedesktop.org" target="_blank">HarfBuzz@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/harfbuzz" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/harfbuzz</a><br>
</div></div></blockquote></div><br></div>