profile
viewpoint

fonttools/fonttools 2449

A library to manipulate font files from Python.

harfbuzz/harfbuzz 1673

HarfBuzz text shaping engine

dscorbett/duployan-font 3

A Duployan Unicode font

dscorbett/dfhack-scripts 2

DFHack scripts

dscorbett/pygments-main 2

A copy of Pygments for lexer development

pranav/cs4500 2

Repository for the CS4500 Project

dscorbett/hmong-font 1

A Pahawh Hmong Unicode font

dscorbett/i7x 1

Inform 7 extensions

dscorbett/pixelated-nushu 1

Pixelated Nüshu glyphs for GNU Unifont and the tools to create them

push eventbasis-technology-corp/open-source-parent

Katsuya Tomioka

commit sha cec406483302c211ef9ec06b9644dfb7b8a12d83

ROS-321: add coverage profile with jacoco

view details

Katsuya Tomioka

commit sha 52dec0efe691abba08e7c7c88be91e8b8db0c75c

ROS-321: reorder jacoco property

view details

David Corbett

commit sha 0df68a50aeb5b5fbd9156254a770c3dfedeff03c

Merge pull request #20 from Katsuya-Tomioka/ROS-321 ROS-321: add coverage profile with jacoco

view details

push time in 2 hours

PullRequestReviewEvent

Pull request review commentbasis-technology-corp/open-source-parent

ROS-321: add coverage profile with jacoco

         <maven.scm.version>1.11.2</maven.scm.version>         <nexus-staging-plugin-version>1.6.8</nexus-staging-plugin-version>         <wagon-ssh.version>3.3.2</wagon-ssh.version>+        <jacoco-maven-plugin.version>0.8.6</jacoco-maven-plugin.version>

Please alphabetize this between exec-maven-plugin.version and maven-antrun-plugin.version.

Katsuya-Tomioka

comment created time in 2 hours

PullRequestReviewEvent
PullRequestReviewEvent

issue openedagarick/agave

Braille patterns have confusing spacing

The side bearings of the braille patterns are too small relative to the internal spacing between dots. For example, U+2831 is hard to distinguish from <U+2808, U+2806>. Table 703.3.1 of the ADA Accessibility Guidelines indicates the proper ratios. ⠱⠈⠆

created time in 2 hours

issue openedagarick/agave

Stroke width of U+23B7 RADICAL SYMBOL BOTTOM

The stroke width of U+23B7 RADICAL SYMBOL BOTTOM is wider than that of other radical symbol pieces, which are unified with the box drawing symbols U+2502 and U+250C according to L2/00-159. Here it is below U+2502. │⎷ U+23B7 does, however, have the same width as U+23AE INTEGRAL EXTENSION, which L2/00-159 lists as an alternative to U+2502, but I think using U+2502 is preferable, since U+2502 has the same stroke width as U+250C for the corner piece, for which L2/00-159 lists no alternative.

created time in 15 hours

issue openedagarick/agave

Inconsistent baseline for U+0267 LATIN SMALL LETTER HENG WITH HOOK

Most glyphs that have descenders as well as vertical stems, such as U+014B, U+019E, and U+0220, shorten their vertical stems a bit so they float above the baseline. U+0267 LATIN SMALL LETTER HENG WITH HOOK is an exception. ɧŋƞȠ

created time in a day

issue closedagarick/agave

Inconsistencies introduced in v30

The x-heights of ⟨b⟩, ⟨d⟩, and ⟨h⟩ and the bottom corner of ⟨d⟩ changed in version 30, but not the glyphs of all related characters:

  • U+01C6 LATIN SMALL LETTER DZ WITH CARON
  • U+01F3 LATIN SMALL LETTER DZ
  • U+0238 LATIN SMALL LETTER DB DIGRAPH
  • U+02A4 LATIN SMALL LETTER DEZH DIGRAPH
  • U+0195 LATIN SMALL LETTER HV

While you’re updating x-heights, you might want to change U+01F6 LATIN CAPITAL LETTER HWAIR, the capital of U+0195, too.

ddždzȸʤhƕǶ

closed time in a day

dscorbett

issue commentsharanda/manrope

Localized forms for different language systems in the same lookup

I’ve seen other fonts with the same bug, so I suspect it is a problem with your version of Glyphs. However, you should be able to work around it. My advice is to split locl_latn_0 into two lookups: one for Romanian/Moldovan and one for the Turkic languages. Similarly, split locl_cyrl_0 into two lookups: one for Bulgarian and one for Serbian.

dscorbett

comment created time in a day

push eventdscorbett/duployan-font

David Corbett

commit sha efed929868de4f7f1761152863a5fe059a754ba2

Use fontTools 4.16.1

view details

push time in 2 days

create barnchdscorbett/duployan-font

branch : ci

created branch time in 2 days

issue openedagarick/agave

Inconsistencies introduced in v30

The x-heights of ⟨b⟩, ⟨d⟩, and ⟨h⟩ and the bottom corner of ⟨d⟩ changed in version 30, but not the glyphs of all related characters:

  • U+01C6 LATIN SMALL LETTER DZ WITH CARON
  • U+01F3 LATIN SMALL LETTER DZ
  • U+0238 LATIN SMALL LETTER DB DIGRAPH
  • U+02A4 LATIN SMALL LETTER DEZH DIGRAPH
  • U+0195 LATIN SMALL LETTER HV

While you’re updating x-heights, you might want to change U+01F6 LATIN CAPITAL LETTER HWAIR, the capital of U+0195, too.

ddždzȸʤhƕǶ

created time in 2 days

PR opened harfbuzz/harfbuzz

Avoid duplication of categories between C++ and Ragel

A bunch of Ragel machines for complex shapers had comments like “Same order as enum indic_category_t. Not sure how to avoid duplication.” I put the enums into their own headers and included them in both C++ and Ragel. This relies on the difference between the two languages’ include statements so that the same enum value is called e.g. OT_ZWJ in C++ and ZWJ in Ragel.

I merged khmer_category_t and myanmar_category_t into indic_category_t. I guess this wasn’t strictly necessary. It required renaming Myanmar’s OT_V (visarga or Shan tone) because it clashed with Indic’s OT_V (independent vowel).

+259 -299

0 comment

17 changed files

pr created time in 3 days

push eventharfbuzz/harfbuzz

Khaled Hosny

commit sha c2cdcd4901132ea7690bda655602d84e63505eb1

[tests] warning: unused variable 'num_glyphs'

view details

David Corbett

commit sha 79fd5ce22e03d9db6553dadc0a5e3862b0bfa20d

[use] Merge IND and Rsv classes into O

view details

David Corbett

commit sha 49ebb9ebdd689490c74da835a3fb829f14df6ed1

[use] Remove redundant O entries from the table

view details

David Corbett

commit sha 6ee4173283921859be91974feca6950828a10e7f

Avoid category duplication between C++ and Ragel

view details

push time in 3 days

push eventharfbuzz/harfbuzz

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha f37f985eab7bb2ecfaec9facf956e7906c0cb1c1

Avoid category duplication between C++ and Ragel

view details

David Corbett

commit sha 7c42a41fce34763a1e0a8b8528bd48d7554bdf5f

Debug Ragel on MSYS2

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha 7af09431c7a9d2c161a183a71e7ee0358eb7b340

Debug Ragel on MSYS2

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha 09dd4b37154c73c7d8de138d51c1759eb6234aee

Avoid category duplication between C++ and Ragel

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha 79f5e301d61ee38edf172e9c9af7237a5ffcf07c

Debug Meson build

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha 2dbcbfcbf1b24bcb8b7bfd06026843da7f3e781c

Avoid category duplication between C++ and Ragel

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha bb180d0d33ec9114f7f64d8bbd97f0c26440030b

Debug Meson build

view details

push time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha 595490f5169a0e41b8b6e3ee846c565a8ce03eba

Avoid category duplication between C++ and Ragel

view details

push time in 3 days

create barnchharfbuzz/harfbuzz

branch : avoid-duplication

created branch time in 3 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha e25aa49a1bcd8f25eeda1846c7daf9b887571d84

Fix a dead link in CMakeLists.txt

view details

push time in 3 days

PR opened harfbuzz/harfbuzz

[use] Merge IND and Rsv classes into O

IND, Rsv, and O are effectively identical, so they might as well all be O.

+71 -87

0 comment

5 changed files

pr created time in 3 days

create barnchharfbuzz/harfbuzz

branch : use-ind-rsv

created branch time in 3 days

push eventharfbuzz/harfbuzz

Behdad Esfahbod

commit sha cde2cf84c0d6515c701296351b9d5a80a41d78c5

[use] Minor clean-up of unused categories

view details

push time in 3 days

delete branch harfbuzz/harfbuzz

delete branch : use-cleanup-categories

delete time in 3 days

PR merged harfbuzz/harfbuzz

[use] Minor clean-up of unused categories

Unfortunately Fedora ships ragel 7.0.0, which, ehem, is "developmental" version and breaks things badly. So I cannot even compile with this change, let alone the lots of whitespace and other unnecessary changes.

The compile error is a legit unused-variable issue in the ragel-generated code:

CXX libharfbuzz_la-hb-ot-shape-complex-use.lo In file included from hb-ot-shape-complex-use.cc:202: hb-ot-shape-complex-use-machine.rl: In function ‘void find_syllables_use(hb_buffer_t*)’: hb-ot-shape-complex-use-machine.rl:195:15: error: unused variable ‘act’ [-Werror=unused-variable] 195 | unsigned int act; | ^~~

Someone without older ragel please amend this commit if you can.

+18 -33

2 comments

4 changed files

behdad

pr closed time in 3 days

PullRequestReviewEvent

pull request commentharfbuzz/harfbuzz

[use] Minor clean-up of unused categories

I have amended the commit. I don’t have Fedora, but it’s my understanding that you can install old versions of packages if you can find them archived somewhere, like this package of Ragel 6.8. For reference, I have Ragel 6.10. You could probably also build your own: see https://github.com/harfbuzz/harfbuzz/pull/1695#issuecomment-490614199 for how I built Ragel 7; building Ragel 6 is probably similar.

behdad

comment created time in 3 days

push eventharfbuzz/harfbuzz

Behdad Esfahbod

commit sha 24165780f9eb0be6cb283c1799aa03668b913c65

[use] Minor clean-up of unused categories

view details

push time in 3 days

PR opened harfbuzz/harfbuzz

[use] Skip WJ and ZWJ when clustering

This is a follow-up to #1695 for U+2060 WORD JOINER and U+200D ZERO WIDTH JOINER. These default ignorable code points do not need any special handling. This is intentionally different from what the USE spec specifies: the spec requires many more dotted circles to be inserted, but the spec is wrong. The point of a character being default ignorable is so it gets ignored for rendering if the renderer doesn’t know what to do with it. A user should always be allowed to explicitly forbid a line break or request a ligature, even in contexts Microsoft didn’t think of.

The USE spec says that WJ is always in a cluster by itself. This is wrong because WJ is default ignorable. Because WJ has Joining_Type=Transparent, we can infer that it is not meant to have any visual effect when there is no line break. WJ is generally not useful within a cluster since a cluster does not normally have a line break opportunity anyway, but it is none of the shaper’s business if someone wants to use it.

The USE spec says that if there are two consecutive ZWJs, there is a cluster break between them. Why should there be? It would be acceptable, though unnecessary, to break the cluster in contexts like ⟨C, H, ZWJ, ZWJ, C⟩ but it is not acceptable to break the cluster when that would require a dotted circle. Again, the shaper should not be second-guessing the user’s questionable choices.

The USE spec says that ZWJ merges two adjacent clusters into a single cluster. However, according to MicrosoftDocs/typography-issues#232, DirectWrite does not implement it. I don’t want to go out on a limb supporting an otherwise unimplemented feature. Also, I think it is a bad feature: it would make character sequences like ⟨C, ZWJ, C, VPre⟩ be rendered as ⟨VPre, C, C⟩ or ⟨VPre, C_C⟩, which a reader would probably pronounce wrong. A ZWJ is not a virama.

+272 -342

0 comment

6 changed files

pr created time in 4 days

create barnchharfbuzz/harfbuzz

branch : use-wj-zwj

created branch time in 4 days

pull request commentmathiasbynens/small

Lowercase the doctype

It is still there.

fulldecent

comment created time in 4 days

pull request commentmathiasbynens/small

Lowercase the doctype

This change adds an unnecessary newline.

fulldecent

comment created time in 4 days

issue commentgooglefonts/noto-fonts

\u06E0 should look like oval shaped zero

The substance of this bug report is true, but I want to point out that the name ARABIC SMALL HIGH UPRIGHT RECTANGULAR ZERO isn’t incorrect: this mark is apparently known in Arabic as “<span lang=ar>الصفر المستطيل القائم</span>”.

fawazahmed0

comment created time in 4 days

issue openedrosettatype/handjet

Combinations of shaddah and other marks are spacing

Some combinations of U+0651 ARABIC SHADDA with other marks are ligated into spacing glyphs. They should not be spacing. For example, here is <U+06CC ARABIC LETTER FARSI YEH, U+064D ARABIC KASRATAN, U+0651 ARABIC SHADDA>: یٍّ

The glyphs for U+FC5E..U+FC63 should still be spacing.

created time in 6 days

issue openedrosettatype/handjet

Decomposing Yiddish digraphs makes them wider

The Yiddish digraphs U+05F0..U+05F2 are decomposed. The digraph glyphs (hbVav_hbVav etc.) are narrower than the pairs they are decomposed into (hbVav hbVav etc.). For U+05F0 and U+05F1, this is harmless though pointless, but it makes a vowelless U+05F2 HEBREW LIGATURE YIDDISH DOUBLE YOD wider than it is with patah, which may have been unintentional. Here is <U+05F2, U+05F2, U+05B7>: ײײַ

I recommend not decomposing U+05F0..U+05F2.

created time in 6 days

issue commentgooglefonts/noto-fonts

Quranic annotation signs (U+06D7 U+06D6) misplaced in Noto fonts

It only looks good in your test file because a space comes between the letter and the annotation sign. If you remove the space, the problem appears. دَرَجَاتٍۚ

nizarsq

comment created time in 6 days

issue commentgooglefonts/noto-fonts

Incorrect decomposition of U+FDF0

This bug is back in Noto Sans Arabic 2.002.

dscorbett

comment created time in 7 days

issue openedMicrosoftDocs/typography-issues

Names of 'FNE ' and 'TNE ' should include “Enets”

The names of 'FNE ' and 'TNE ' in the “Language System” column are “Forest Nenets” and “Tundra Nenets”. In #53, it was resolved that these tags should be ambiguous between Nenets and Enets. Therefore, each one’s name should mention Enets as well as Nenets.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 7 days

issue commentMicrosoftDocs/typography-issues

Missing ISO 639 codes for Chin

"cey" was already covered by #204. "pub" is Purum, which I mentioned at the end of my last comment. Do you consider Purum’s situation to be different from those of Kharam and Darlong?

dscorbett

comment created time in 7 days

issue commentMicrosoftDocs/typography-issues

Missing ISO 639 codes for Chin

I got a list of all the Kuki-Chin languages on Wikipedia and on Glottolog and pared it down to the ones in language families that the current 'QIN ' list covers. That ended up being Central Kuki-Chin and Peripheral Kuki-Chin but not Northwestern Kuki-Chin. The Northwestern Kuki-Chin languages are apparently different from the others and spoken by a different ethnic group, so it is not unreasonable to not put them in the same list.

There is one exception in the current list: "flm" (Halam) is a Northwestern Kuki-Chin language. That code was split into "cfm" and "rnl". If the one is present, so should the other two. However, it is odd to have this one outlier, so it might be better to remove "flm" from the list instead of adding "cfm" and "rnl". Note that Halam already has its own language system tag, 'HAL '.

I also excluded Kharam, Purum, and Darlong because Glottolog and Wikipedia disagree about their language families.

dscorbett

comment created time in 7 days

issue openedMicrosoftDocs/typography-issues

Missing ISO 639 codes for Chin

The language system tag 'QIN ' should have the following ISO 639 codes added to its list: biu, cek, cfm, ckn, clj, clt, csj, csv, cth, gnb, hmr, hra, lus, mwq, pkh, ral, rnl, rtc, sch, shl, smt, vap, weu, zyp.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 8 days

issue commentalif-type/amiri

Overlapping stop signs

Although the three dots are spacing, I think they should still be encoded as U+06DB ARABIC SMALL HIGH THREE DOTS. In this Quran’s style, it seems that stop signs are often spacing and slightly above the baseline; cf. U+06DA ARABIC SMALL HIGH JEEM in ayah 4, U+08D7 ARABIC SMALL HIGH QAF in ayah 5, and another stack of <U+06DA, U+06D6> in ayah 14.

I understand if you decline to support this, but I only just discovered this and I thought it was too interesting not to report.

dscorbett

comment created time in 8 days

issue commentgooglefonts/noto-fonts

Quranic annotation signs (U+06D7 U+06D6) misplaced in Noto fonts

This affects all the waqf signs, not just U+06D6 and U+06D7.

Another positioning quirk of these signs is that they appear at a certain minimum height. They can be raised to make room for other marks but not lowered below that height. See “AlQalam for typesetting traditional Arabic texts”, section 5.1. For example, U+06D6 should be at the same height in both <U+0631, U+06D6> and <U+0631, U+064E, U+06D6>. رۖرَۖ

For the UI fonts with their restricted line height, this minimum height might be too high. I have found an alternative positioning strategy: in surah 2, ayah 26 of this Quran there are examples of U+0615 ARABIC SMALL HIGH TAH, U+06DA ARABIC SMALL HIGH JEEM, and U+06D8 ARABIC SMALL HIGH MEEM INITIAL FORM. They are rendered as spacing marks to the left of their bases and are only somewhat raised above the baseline. Something like this (at least the use of spacing marks) may be appropriate for the UI fonts.

nizarsq

comment created time in 8 days

issue openedalif-type/amiri

Overlapping stop signs

In surah 2, ayah 2 of this Quran, there are three consecutive stop signs in ⟨رَیۡبَۛۚۖ⟩. In Amiri, they overstrike each other. رَیۡبَۛۚۖ

created time in 8 days

issue commentrosettatype/handjet

Decomposed pasekh tsvey yudn is rendered wrong

Because <U+05F2, U+05B7> and U+FB1F are canonically equivalent, they should look equivalent, regardless of language tagging.

dscorbett

comment created time in 8 days

issue commentrosettatype/handjet

Decomposed pasekh tsvey yudn is rendered wrong

This was only partially fixed. It only works when the text is tagged as Yiddish because the relevant lookup uses the language system tag 'JII '.

dscorbett

comment created time in 8 days

issue commentharfbuzz/harfbuzz

Questions about HB_BUFFER_MAX_OPS_FACTOR

Wow! That is quite a high limit. Thanks!

dscorbett

comment created time in 9 days

issue openedharfbuzz/harfbuzz

Questions about HB_BUFFER_MAX_OPS_FACTOR

I am developing a Duployan font that uses many complex lookups to work around the lack of spacing marks in OpenType. Compiling HarfBuzz with CPPFLAGS=-DHB_BUFFER_MAX_OPS_FACTOR=256 is sufficient for my own testing, but the font won’t work for anyone else, so I have some questions.

max_ops was added for #429 to “curb DoS fonts”. How I can tell if I accidentally made a DoS font? My font doesn’t have any recursive lookup loops and produces only linear growth (about 192 glyphs per character as of the latest commit). Is there a way for HarfBuzz to distinguish a legitimate complex font from a DoS font other than by counting operations?

If not, would it be acceptable to increase the default HB_BUFFER_MAX_OPS_FACTOR from 64? I don’t know if 256 will ultimately suffice for the final font; what is the highest value to which you would agree to increase it? I’m asking now, well before the font is complete, because I will have wasted a lot of time and effort if I can’t count on HarfBuzz supporting it. I’d like to know now so I can plan accordingly.

created time in 9 days

issue openedrosettatype/handjet

Decomposed pasekh tsvey yudn is rendered wrong

The sequence <U+05F2 HEBREW LIGATURE YIDDISH DOUBLE YOD, U+05B7 HEBREW POINT PATAH> should look identical to U+FB1F HEBREW LIGATURE YIDDISH YOD YOD PATAH. ײַײַ

created time in 9 days

issue openedMicrosoftDocs/typography-issues

'YCR ' should be mapped only to "crk"

The tag 'YCR ' (Y-Cree) should be mapped to "crk" (Plains Cree). It should not be mapped to "cre" (Cree). This is because Y-Cree is a subset of Cree, not a synonym of Cree.


Document Details

Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

created time in 10 days

PR opened harfbuzz/harfbuzz

Fix and tweak gen-tag-table.py

These are a few unrelated changes to gen-tag-table.py.

The first is purely cosmetic for more consistency of language names in comments.

The second adds a mapping from "hy-arevmda" (Western Armenian) to 'HYE ' (Armenian). Previously, the variant subtag was unrecognized, so it mapped to HYE0 (Eastern Armenian) as plain "hy" does. "arevmda" is deprecated, but it should be recognized to support documents created in the 11 years it was recommended.

The third fixes the mapping from 'MNK ' to "man". Previously it was being mapped to "emk". It was a general bug but it happened to only affect this single mapping.

The fourth maps every individual language to its macrolanguage’s language system tag (if any). For example, "prs" maps to 'DRI ' as before, but now falls back to 'FAR '. Previously it would not do that if the individual language had its own language system tag. That was a bad idea because, given a document tagged as "prs" and a font that supports 'FAR ' but not 'DRI ', it would be better to apply the 'FAR ' lookups than not.

+197 -81

0 comment

3 changed files

pr created time in 10 days

create barnchharfbuzz/harfbuzz

branch : language-tags

created branch time in 10 days

issue commentpsb1558/Junicode-New

A75B (LATIN SMALL LETTER R ROTUNDA) not yet available?

The purpose of U+A75B LATIN SMALL LETTER R ROTUNDA is to always look like an r rotunda, just as the purpose of U+017F LATIN SMALL LETTER LONG S is to always look like a long s. The font shouldn’t obscure the underlying text for code points intended for particular glyph variants.

jsbien

comment created time in 10 days

issue openedMicrosoftDocs/typography-issues

Missing ISO 639 codes for Athapaskan

The ISO 639 codes "apa" (Apache languages), "qwt" (Kwalhioqua-Tlatskanai), and "xup" (Upper Umpqua) should be mapped to the language system tag 'ATH ' (Athapaskan).

created time in 10 days

issue openedsimoncozens/youseedee

Angle brackets in names

The returned Name field is taken from field 2 of UnicodeData.txt, which is not always the name. Some code points’ names are the empty string and some are derived algorithmically.

$ python3 -m youseedee 0000
{'Age': '1.1',
 'Block': 'Basic Latin',
 'Canonical_Combining_Class': '0',
 'East_Asian_Width': 'N',
 'General_Category': 'Cc',
 'Line_Break': 'CM',
 'Name': '<control>',
 'Name_Alias': 'NUL',
 'Script': 'Common'}
$ python3 -m youseedee 4e00
{'Age': '1.1',
 'Block': 'CJK Unified Ideographs',
 'Canonical_Combining_Class': '0',
 'East_Asian_Width': 'W',
 'General_Category': 'Lo',
 'Line_Break': 'ID',
 'Name': '<CJK Ideograph, First>',
 'Script': 'Han'}

created time in 12 days

issue commentpsb1558/Junicode-New

U+1D24 LATIN LETTER VOICED LARYNGEAL SPIRANT is too short

Yes, as a phonetic character it would generally be amidst lowercase letters.

dscorbett

comment created time in 13 days

issue openedpsb1558/Junicode-New

U+1D24 LATIN LETTER VOICED LARYNGEAL SPIRANT is too short

The current glyph for U+1D24 LATIN LETTER VOICED LARYNGEAL SPIRANT is only slightly taller than x-height, but it is caps-height in the document cited in the Unicode proposal; see https://www.unicode.org/L2/L2002/02141-n2419-uralic-phonetic.pdf#page=33 and https://helda.helsinki.fi/bitstream/handle/10224/4089/sovijarvi1-24.pdf#page=12.

created time in 13 days

issue openedfroyotam/ferrite-core

Blank kana glyphs

Some scattered hiragana and katakana have blank glyphs. They should be removed from the font.

created time in 13 days

issue openedslavfox/Cozette

U+220F N-ARY PRODUCT and U+2210 N-ARY COPRODUCT are too short

U+220F N-ARY PRODUCT and U+2210 N-ARY COPRODUCT are too short. They should, as <var>n</var>-ary operators, be taller than caps-height, like the current glyph for U+2225, but their glyphs are x-height. Here they are with U+03C0 GREEK SMALL LETTER PI for comparison. ∏∐π

created time in 14 days

issue openedrosettatype/handjet

Incomplete soft-dotting

Soft dots are only removed from ⟨i⟩ and ⟨j⟩. The following should also lose their dots in the same contexts:

  • U+012F LATIN SMALL LETTER I WITH OGONEK
  • U+0456 CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
  • U+0458 CYRILLIC SMALL LETTER JE
  • U+1ECB LATIN SMALL LETTER I WITH DOT BELOW

created time in 14 days

issue closedrosettatype/handjet

U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned wrong

When applied to U+05D5 HEBREW LETTER VAV, U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned identically to U+05B9 HEBREW POINT HOLAM. U+05BA should go above and to the left. (On other letters, U+05B9 goes above and to the left and U+05BA is invalid.) וֹוֺ

closed time in 14 days

dscorbett

issue openedhuertatipografica/Alegreya

Incomplete soft-dotting

Soft dots are only removed from ⟨i⟩ and ⟨j⟩. The following should also lose their dots in the same contexts:

  • U+012F LATIN SMALL LETTER I WITH OGONEK
  • U+02B2 MODIFIER LETTER SMALL J
  • U+0456 CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
  • U+0458 CYRILLIC SMALL LETTER JE
  • U+1ECB LATIN SMALL LETTER I WITH DOT BELOW

created time in 14 days

issue openedagarick/autonoe

Extra oxeia in U+03D7 GREEK KAI SYMBOL

The glyph for U+03D7 GREEK KAI SYMBOL should not include a diacritic above it.

created time in 14 days

push eventharfbuzz/harfbuzz

David Corbett

commit sha c39ab82c90479341dcf28eaa8174af6f08c0d7ae

Fix usage text of gen-use-table.py

view details

push time in 14 days

issue commentharfbuzz/harfbuzz

gen-use-table is failing

You swapped the last two arguments.

simoncozens

comment created time in 14 days

issue closedagarick/agave

U+0462 CYRILLIC CAPITAL LETTER YAT has misplaced crossbar

The crossbar of U+0462 CYRILLIC CAPITAL LETTER YAT should go through the vertical stroke, not on top of it. Ѣ

closed time in 14 days

dscorbett

issue commentn8willis/opentype-shaping-documents

[Indic] Input masks for features

Consonant–halant is not always pre-base. For example, it can appear at the end of a word or before a ZWNJ. So the substitution does depend on context. Context masks are therefore needed for correct shaping in the Indic shaper.

simoncozens

comment created time in 14 days

issue commentrosettatype/handjet

U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned wrong

Yes, that looks good.

dscorbett

comment created time in 14 days

issue closedCatharsisFonts/Cormorant

U+220F N-ARY PRODUCT and U+2211 N-ARY SUMMATION are too short

U+220F N-ARY PRODUCT and U+2211 N-ARY SUMMATION should descend below the baseline, which is the convention for <var>n</var>-ary operators. The current glyphs would be appropriate for U+03A0 GREEK CAPITAL LETTER PI and U+03A3 GREEK CAPITAL LETTER SIGMA instead. Here they are, with ⟨R⟩ for comparison: R∏∑

closed time in 15 days

dscorbett

issue commentrosettatype/handjet

U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned wrong

You shifted both U+05B9 and U+05BA to the left instead of just U+05BA. Now U+05B9 HEBREW POINT HOLAM is positioned wrong. The point of having two holam code points is so that <U+05D5, U+05B9> and <U+05D5, U+05BA> look different. וֹוֺ

dscorbett

comment created time in 15 days

issue closedCatharsisFonts/Ysabeau

U+03CF GREEK CAPITAL KAI SYMBOL is too short

U+03CF GREEK CAPITAL KAI SYMBOL should be as tall as a capital letter. Here it is beside U+039A GREEK CAPITAL LETTER KAPPA. ΚϏ

closed time in 16 days

dscorbett

issue commentCatharsisFonts/Ysabeau

U+03CF GREEK CAPITAL KAI SYMBOL is too short

It looks good now.

dscorbett

comment created time in 16 days

issue openedagarick/agave

U+0462 CYRILLIC CAPITAL LETTER YAT has misplaced crossbar

The crossbar of U+0462 CYRILLIC CAPITAL LETTER YAT should go through the vertical stroke, not on top of it. Ѣ

created time in 16 days

issue closedagarick/agave

Inconsistencies introduced in v27

The glyphs of ⟨a⟩ and ⟨f⟩ changed in version 27, but not the glyphs of all related characters:

  • U+00AA FEMININE ORDINAL INDICATOR
  • U+2090 LATIN SUBSCRIPT SMALL LETTER A
  • U+0192 LATIN SMALL LETTER F WITH HOOK
  • U+02A9 LATIN SMALL LETTER FENG DIGRAPH

aªₐfƒʩ

FWIW, I think the sharper curve of ⟨f⟩ looks too lumpy. It is only really noticeable at large font sizes. It looks okay in the SVG, so perhaps something went wrong in the conversion to SFD.

closed time in 16 days

dscorbett

issue commentCatharsisFonts/Ysabeau

U+03CF GREEK CAPITAL KAI SYMBOL is too short

I checked U+03CF in all the fonts I have that support it. All but two show it as caps-height. The exceptions are Athelas and Gill Sans. Gill Sans swaps the glyphs for U+03CF and U+03D7, which is a bug, not a design choice. System fonts often have bugs in obscure characters that go unfixed for years. I would therefore not trust Athelas.

dscorbett

comment created time in 16 days

issue openedhuertatipografica/piazzolla

Incomplete soft-dotting

Soft dots are only removed from ⟨i⟩ and ⟨j⟩. The following should also lose their dots in the same contexts:

  • U+012F LATIN SMALL LETTER I WITH OGONEK
  • U+0456 CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
  • U+0458 CYRILLIC SMALL LETTER JE
  • U+1ECB LATIN SMALL LETTER I WITH DOT BELOW

created time in 17 days

issue commentagarick/agave

Inconsistencies introduced in v27

I mean that the curve isn’t smooth. zoomed-in view of the curve of the ⟨f⟩ glyph

dscorbett

comment created time in 17 days

issue commentCatharsisFonts/Ysabeau

U+03CF GREEK CAPITAL KAI SYMBOL is too short

The examples in L2/06-266, figures 1–3 show it as caps-height and it is defined in Unicode as an uppercase letter. If you open your browser’s developer tools it should show you what font is being used on the Wikipedia article; I’m curious to know which font that is.

dscorbett

comment created time in 17 days

issue openedagarick/agave

Inconsistencies introduced in v27

The glyphs of ⟨a⟩ and ⟨f⟩ changed in version 27, but not the glyphs of all related characters:

  • U+00AA FEMININE ORDINAL INDICATOR
  • U+2090 LATIN SUBSCRIPT SMALL LETTER A
  • U+0192 LATIN SMALL LETTER F WITH HOOK
  • U+02A9 LATIN SMALL LETTER FENG DIGRAPH

aªₐfƒʩ

FWIW, I think the sharper curve of ⟨f⟩ looks too lumpy. It is only really noticeable at large font sizes. It looks okay in the SVG, so perhaps something went wrong in the conversion to SFD.

created time in 17 days

issue closedagarick/agave

𝑛-ary operators are too short

<var>n</var>-ary mathematical operators should be taller than normal operators: U+220F N-ARY PRODUCT, U+2210 N-ARY COPRODUCT, and U+2211 N-ARY SUMMATION should descend below the baseline. The current glyph for U+2210 would be appropriate for U+2A3F AMALGAMATION OR COPRODUCT.

closed time in 17 days

dscorbett

issue closedagarick/agave

U+2201 COMPLEMENT looks like ⟨C⟩

U+2201 COMPLEMENT looks identical to U+0043 LATIN CAPITAL LETTER C. It should look more stretched, as in \complement in LaTeX.

closed time in 17 days

dscorbett

issue openedrosettatype/handjet

Wrong glyph for U+05C7 HEBREW POINT QAMATS QATAN

In this font, U+05C7 HEBREW POINT QAMATS QATAN looks identical to U+05B8 HEBREW POINT QAMATS. According to L2/04-150, U+05C7 “is usually presented with a longer vertical; it can also be represented simply with a larger glyph, and in one case we have found the horizontal lengthened and bent.”

created time in 17 days

issue openedrosettatype/handjet

U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned wrong

When applied to U+05D5 HEBREW LETTER VAV, U+05BA HEBREW POINT HOLAM HASER FOR VAV is positioned identically to U+05B9 HEBREW POINT HOLAM. U+05BA should go above and to the left. (On other letters, U+05B9 goes above and to the left and U+05BA is invalid.) וֹוֺ

created time in 17 days

issue openedagarick/agave

U+2201 COMPLEMENT looks like ⟨C⟩

U+2201 COMPLEMENT looks identical to U+0043 LATIN CAPITAL LETTER C. It should look more stretched, as in \complement in LaTeX.

created time in 17 days

issue openedagarick/agave

𝑛-ary operators are too short

<var>n</var>-ary mathematical operators should be taller than normal operators: U+220F N-ARY PRODUCT, U+2210 N-ARY COPRODUCT, and U+2211 N-ARY SUMMATION should descend below the baseline. The current glyph for U+2210 would be appropriate for U+2A3F AMALGAMATION OR COPRODUCT.

created time in 17 days

issue openedhuertatipografica/Alegreya

U+220F N-ARY PRODUCT and U+2211 N-ARY SUMMATION are too short

U+220F N-ARY PRODUCT and U+2211 N-ARY SUMMATION look identical to U+03A0 GREEK CAPITAL LETTER PI and U+03A3 GREEK CAPITAL LETTER SIGMA. n-ary operators should descend below the baseline. ∏∑ΠΣ

created time in 17 days

issue openedTypeNetwork/Amstelvar

Wrong glyph components for /Ebrevecyr

Ebrevecyr at U+F524 has a diaeresis instead of a breve; cf. ebrevecyr at U+F525 which has a breve. The current Ebrevecyr glyph belongs at U+04EC CYRILLIC CAPITAL LETTER E WITH DIAERESIS.

created time in 17 days

issue openedTypeNetwork/Amstelvar

Wrong glyph for U+2015 HORIZONTAL BAR

According to Unicode’s names list, U+2015 HORIZONTAL BAR is a “long dash introducing quoted text”. In many fonts it looks similar or identical to U+2014 EM DASH. However, in this font, it looks like a hyphen, not a long dash.

created time in 17 days

issue openedTypeNetwork/Amstelvar

Problems with diacritics

U+00A8 DIAERESIS, U+0384 GREEK TONOS, and U+0385 GREEK DIALYTIKA TONOS have non-spacing glyphs. They should be spacing and should not have anchor points.

All the glyphs in the block Combining Diacritical Marks except for U+0308 are spacing. They should be combining.

U+0308 COMBINING DIAERESIS correctly has a combining glyph with an anchor point. However, its contour points have positive x values. Most base glyphs in this font lack anchor points, so if U+0308 is applied to one base, it will appear above the following base. The simplest solution is to shift the glyph left so it has negative x values.

created time in 17 days

issue openedCatharsisFonts/Ysabeau

U+03CF GREEK CAPITAL KAI SYMBOL is too short

U+03CF GREEK CAPITAL KAI SYMBOL should be as tall as a capital letter. Here it is beside U+039A GREEK CAPITAL LETTER KAPPA. ΚϏ

created time in 18 days

push eventbasis-technology-corp/annotated-data-model

Katsuya Tomioka

commit sha 8be7fcb634af3104f09e629c2b28441114c0afc5

ROS-320: remove adm.* taglets

view details

Katsuya Tomioka

commit sha 616fc019ebb1560c570655b6f8187bc7bcd37826

ROS-320: set travis dist to trusty for oraclejdk8

view details

Katsuya Tomioka

commit sha ba1188cc086aec029b259a316c316448bc22e857

ROS-320: typo

view details

David Corbett

commit sha 79ef662736d3057c259d667e06484062c1213adc

Merge pull request #61 from Katsuya-Tomioka/ROS-320-remove-taglets ROS-320: remove adm.* taglets

view details

push time in 18 days

PullRequestReviewEvent
more