- 24 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
See comment. Micro-tests added.
-
- 18 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 17 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 12 7月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Simplifies hb_in_range() calls as the type can be inferred. The rest is obsessiveness, I admit.
-
- 01 7月, 2014 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
These were introduced in a498565c, but IndicSyllabicCategory has had the correct value already, so the special code was never needed.
-
由 Behdad Esfahbod 提交于
Touch code just enough to preserve previous syllable structure and functionality as closely as possible. Many further cleanups coming later.
-
- 13 6月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
If pre-base reordering Ra is NOT formed (or formed and then broken up), we should consider that Ra as base. This is observable when there's a left matra or dotreph that positions before base. Now, it might be that we shouldn't do this if the Ra happend to form a below form. We can't quite deduce that right now... Micro test added. Also at: https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=186#c29
-
- 10 6月, 2014 3 次提交
-
-
由 Behdad Esfahbod 提交于
Sometimes font designers form half/pref/etc consonant forms unconditionally and then undo that conditionally. Try to recover the OT_H classification in those cases. No test number changes expected.
-
由 Behdad Esfahbod 提交于
No test numbers change.
-
由 Behdad Esfahbod 提交于
-
- 06 6月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Normally if you want to, say, conditionally prevent a 'pref', you would use blocking contextual matching. Some designers instead form the 'pref' form, then undo it in context. To detect that we now also remember glyphs that went through MultipleSubst. In the only place that this is used, Uniscribe seems to only care about the "last" transformation between Ligature and Multiple substitions. Ie. if you ligate, expand, and ligate again, it moves the pref, but if you ligate and expand it doesn't. That's why we clear the MULTIPLIED bit when setting LIGATED. Micro-test added. Test: U+0D2F,0D4D,0D30 with font from: [1] https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=186#c29
-
- 03 6月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Apparently they can intermix with other OT_A. Test: U+0915,A8E2,1CD0
-
- 30 5月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Tests: U+0967,0951 U+0031,093F
-
- 28 5月, 2014 6 次提交
-
-
由 Behdad Esfahbod 提交于
No functional change intended.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Unicode 6.x IndicSyllableCategory categorizes them as placeholders, but they can subjoin.
-
- 24 5月, 2014 3 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
In anticipation of adding more characters to that class of clusters.
-
- 23 5月, 2014 7 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
It's spacing, but otherwise the same as the other ones.
-
由 Behdad Esfahbod 提交于
Up to two of them come after all OT_A characters.
-
由 Behdad Esfahbod 提交于
Also adjust U+0953,0954 handling.
-
- 22 5月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 16 5月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
Sinhala and Telugu use "explicit" reph. That is, the reph is formed by a Ra,H,ZWJ sequence. Previously, upon detecting this sequence, we were checking checking whether the 'rphf' feature applies to the first two glyphs of the sequence. This is how the Microsoft fonts are designed. However, testing with Noto shows that apparently Uniscribe also forms the reph if the lookup ligates all three glyphs. So, try both sequences. Doesn't affect test results for Sinhala or Telugu. https://code.google.com/a/google.com/p/noto-alpha/issues/detail?id=232
-
- 26 4月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
-
- 19 4月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
commit b5a0f69e Author: Behdad Esfahbod <behdad@behdad.org> Date: Thu Oct 17 18:04:23 2013 +0200 [indic] Pass zero-context=false to would_substitute for newer scripts For scripts without an old/new spec distinction, use zero-context=false. This changes behavior in Sinhala / Khmer, but doesn't seem to regress. This will be useful and used in Javanese. The *intention* was to change zero-context from true to false for scripts that don't have old-vs-new specs. However, checking the code, looks like we essentially change zero-context to always be true; ie. we only changed things for old-spec, and we broke them. That's what causes this bug: https://bugs.freedesktop.org/show_bug.cgi?id=76705 The root of the bug is here: /* Use zero-context would_substitute() matching for new-spec of the main * Indic scripts, but not for old-spec or scripts with one spec only. */ bool zero_context = indic_plan->config->has_old_spec || !indic_plan->is_old_spec; Note that is_old_spec itself is: indic_plan->is_old_spec = indic_plan->config->has_old_spec && ((plan->map.chosen_script[0] & 0x000000FF) != '2'); It's easy to show that zero_context is now always true. What we really meant was: bool zero_context = indic_plan->config->has_old_spec && !indic_plan->is_old_spec; Ie, "&&" instead of "||". We made this change supposedly to make Javanese work. But apparently we got it working regardless! So I'm going to fix this to only change the logic for old-spec and not touch other cases.
-
- 09 4月, 2014 1 次提交
-
-
由 Behdad Esfahbod 提交于
As requested by Martin Hosken on the list.
-
- 31 12月, 2013 1 次提交
-
-
由 Behdad Esfahbod 提交于
No shaper has more than one behavior re this, so no need for a callback.
-
- 28 10月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
This reverts commit d5bd0590. The reasoning behind that logic was flawed and made under a misunderstanding of the original problem, and caused regressions as reported by Jonathan Kew in thread titled "tibetan marks" in Oct 2013. Apparently I have had fixed the original problem with this commit: 7e08f125 So, revert the faulty commit and everything seems to be in good shape.
-
由 Behdad Esfahbod 提交于
For Javanese (pref_len == 1) only reorder if it didn't ligate. That's sensible, and what the spec says. For other Indic (pref_len > 1) only reorder if ligated. Doesn't change any test numbers.
-
- 19 10月, 2013 2 次提交
-
-
由 Behdad Esfahbod 提交于
Bug 58714 - Kannada u+0cb0 u+200d u+0ccd u+0c95 u+0cbe does not provide same results as Windows8 https://bugs.freedesktop.org/show_bug.cgi?id=58714 Test with U+0CB0,U+200D,U+0CCD,U+0C95,U+0CBF and tunga.ttf. Improves some scripts. Improves Bengali too, but numbers are up because we produce better results than Uniscribe for some sequences now. New numbers: BENGALI: 353724 out of 354188 tests passed. 464 failed (0.131004%) DEVANAGARI: 707307 out of 707394 tests passed. 87 failed (0.0122987%) GUJARATI: 366349 out of 366457 tests passed. 108 failed (0.0294714%) GURMUKHI: 60732 out of 60747 tests passed. 15 failed (0.0246926%) KANNADA: 951190 out of 951913 tests passed. 723 failed (0.0759523%) KHMER: 299070 out of 299124 tests passed. 54 failed (0.0180527%) MALAYALAM: 1048140 out of 1048334 tests passed. 194 failed (0.0185056%) ORIYA: 42320 out of 42329 tests passed. 9 failed (0.021262%) SINHALA: 271662 out of 271847 tests passed. 185 failed (0.068053%) TAMIL: 1091753 out of 1091754 tests passed. 1 failed (9.15957e-05%) TELUGU: 970555 out of 970573 tests passed. 18 failed (0.00185457%)
-
-