- 16 9月, 2011 8 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Fixes bug with uniscribe not handling GIGANTIC sizes.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Make --font-file accept "-" to mean stdin, and have it work in Windows too!
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Apparently there's no equivalent to "/dev/stdout", so write using stdio to be able to output to stdout.
-
由 Behdad Esfahbod 提交于
-
- 15 9月, 2011 2 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Now we can use the same code to do other utils...
-
- 09 9月, 2011 7 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
We now support using -1 for NUL-terminated strings.
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
- 03 9月, 2011 2 次提交
-
-
由 Behdad Esfahbod 提交于
In hb_ot_tag_from_language(), if first component of an unknown language is three letters long, use it directly as OpenType language tag (after case conversion and padding).
-
由 Behdad Esfahbod 提交于
Doesn't seem to be slower.
-
- 26 8月, 2011 9 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Still not sure about: 1) Case. We pass lowercase for now. Would be nice if graphite was uppercase 3letter like OpenType, 2) Padding. IMO, tag padding is always with spaces, but Martin was talking about NUL bytes.
-
由 Behdad Esfahbod 提交于
Can be -1 for NUL-terminated string. This is useful for passing parts of a larger string to a function without having to copy or modify the string first. Affected functions: hb_tag_t hb_tag_from_string() hb_direction_from_string() hb_language_from_string() hb_script_from_string()
-
由 Behdad Esfahbod 提交于
-
- 25 8月, 2011 3 次提交
-
-
由 Behdad Esfahbod 提交于
As reported by Khaled on the list: "After the introduction of canonical reordering of combining marks (commit 34c22f81), I'm no longer able to do mark/mark substitution or positioning for mark sequences that involve shadda as a first mark (or most interesting sequences at least). "After some digging, it turned out that shadda have a ccc=33 while most Arabic marks that combine with it have a lower ccc value, which results in the shadda being reordered after the other mark which, unsurprisingly, breaks my contextual substitution and mkmk anchors." See: http://unicode.org/faq/normalization.html#8 http://unicode.org/faq/normalization.html#9
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
Oops!
-
- 24 8月, 2011 8 次提交
-
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
-
由 Behdad Esfahbod 提交于
I don't see how this function can be useful.
-
由 Behdad Esfahbod 提交于
To be modified, a lot.
-
由 Behdad Esfahbod 提交于
-
- 23 8月, 2011 1 次提交
-
-
由 Behdad Esfahbod 提交于
Fixes build with MSVC.
-