The file IndicSyllabicCategory-Additional.txt contains a few overrides in duplicate:

– The entire section for Vowel_Independent with overrides for three Tai Viet characters is duplicated.

– The line for 1820..1878 duplicates the override for the immediately following 1843, although with an incorrect general category in the comment.

U+10AE5 MANICHAEAN ABBREVIATION MARK ABOVE and U+10AE6 MANICHAEAN ABBREVIATION MARK BELOW are non-starters. NFC puts the below-base one first whereas USE specifies that CMAbv precedes CMBlw. Like Tibetan vowel signs, their positional categories need overriding to allow U+10AE6 to precede U+10AE5.

#2 (comment) says:

Ahom sign killer needs to be able to render with vowels, so override ISC to Bindu (i.e., vowel modifier).

Unicode assigns Indic_Syllabic_Category=Pure_Killer to U+1172B AHOM SIGN KILLER. USE maps Pure_Killer to VOWEL. Therefore, it can already render with vowels and this override is unnecessary.

For the reason given in harfbuzz/harfbuzz#627, the sequence <vowel, vowel killer> should be considered an error in Batak and should get a dotted circle. The best solution is to override the two vowel killers to Indic_Syllabic_Category = Nukta and Indic_Positional_Category = Bottom.

The following overrides are missing.

# Indic_Syllabic_Category=Consonant

2D30..2D67   ; Consonant # Lo   [56] TIFINAGH LETTER YA..TIFINAGH LETTER YO
16F00..16F44 ; Consonant # Lo   [69] MIAO LETTER PA..MIAO LETTER HHA

# Indic_Syllabic_Category=Modifying_Letter

16F50        ; Modifying_Letter # Lo       MIAO LETTER NASALIZATION

# Indic_Syllabic_Category=Vowel_Dependent

16F51..16F87 ; Vowel_Dependent # Mc  [55] MIAO SIGN ASPIRATION..MIAO VOWEL SIGN UI

# Indic_Syllabic_Category=Tone_Mark

16F8F..16F92 ; Tone_Mark # Mn   [4] MIAO TONE RIGHT..MIAO TONE BELOW

# Indic_Positional_Category=Bottom

16F51..16F87 ; Bottom # Mc  [55] MIAO SIGN ASPIRATION..MIAO VOWEL SIGN UI
16F8F..16F92 ; Bottom # Mn   [4] MIAO TONE RIGHT..MIAO TONE BELOW

The file IndicSyllabicCategory-Additional.txt has the following entry:

1B6B..1B73 ; Nukta # Mn [9] BALINESE MUSICAL SYMBOL COMBINING TEGEH..BALINESE MUSICAL SYMBOL COMBINING GONG

This override is very likely incorrect. According to the Unicode Standard section 17.3, these characters are part of the musical symbols and intended to be used with base characters or this set. There is no indication that they’re meant to be used as part of regular Balinese orthographic syllables. The USE specification has a special class SYM_MOD just for these characters and a special symbol cluster that allows characters from this class to attach to SYM characters, including the other Balinese musical symbols. The override prevents these attachments and enables incorrect ones.

U+07FD NKO DANTAYALAN is overridden to USE class FM. It should instead be in VMAbv, the same as the other N’Ko marks.

U+07FD has ccc=220. U+07EB NKO COMBINING SHORT HIGH TONE (for example) has USE class VMAbv and ccc=230. Therefore, in NFC text, U+07FD precedes U+07EB, but with the current override USE requires the opposite order.

The cantillation marks U+1CF8 and U+1CF9 do not match any USE subclass and therefore form independent clusters, which was surely not what was intended. Their Indic_Positional_Category should be overridden to Top, which will make them match VOWEL_MOD_ABOVE.

The Kharoshthi nuktas U+10A38..U+10A3A all have different canonical combining classes such that the canonical order is <U+10A39, U+10A3A, U+10A38>. However, U+10A38 is a CMAbv, so USE requires it to precede other nuktas. When it is used with another nukta, canonicalizing the input induces a dotted circle, as in harfbuzz/harfbuzz#3550. The solution is to classify U+10A38 as CMBlw by overriding its Indic_Positional_Category to Bottom.

The Kayah Li vowel signs U+A926..U+A92A do not match any USE subclass and therefore form independent clusters, which was surely not intended. Their Indic_Positional_Category should be overridden to Top, which will make them match VOWEL_ABOVE. (I have also reported this to Unicode, but for now the overrides are necessary.)

Core text of Unicode 15 specifies that certain paired punctuation signs can participate in Hieroglyph clusters. The Hieroglyph properties need to be updated to support the required clustering behaviour.

I would like to say first and foremost, this is a wonderful font which works excellently well and I'm greatly appreciative of the release of the font publicly. This is significantly better than most of the tools/fonts that have existed so far, however with many glyph combinations under many circumstances there are ratio distortions.

Notable examples Include (Without Spaces):
𓂓 𓐰 𓇅
and
𓏞 𓐰 𓂓

There are also circumstances of misalignment and ratio distortion when using the overlay feature and the corner feature respectively. The later in this case is minor yet noticeable.

Example:𓇅 𓐶 𓂓 and 𓅓 𓐴 𓎡

Also:𓅓 𓐴 𓎡 𓐴 𓅓

Leads to a strange issue which will induce subscript.

Lastly, there is an issue which may take a while to fix but is completely fixable. in many glyph combinations the thickness outline of each glyph is mismatched which isn't aesthetically ideal.

I would like to thank the developer for pursuing this project, however, I do hope improvements and alternate fonts for example the one used in JSesh can be re-rendered using this tool to have format control functionality. Additionally, most people have no idea how to render the font using python and VOLT and keep running into various errors, if you want to improve the build instructions please make it a YouTube video going through the process step by step.

I hope over time an improved version of this font can be integrated into windows/most word processing/video processing applications and the web as a whole natively and as standard.

IndicSyllabicCategory-Additional.txt overrides U+0F7F TIBETAN SIGN RNAM BCAD to Consonant_Dead and U+0FC6 TIBETAN SYMBOL PADMA GDAN to Consonant_Final. That means that ⟨ཧྲཱིཿ࿆⟩ gets a dotted circle. Why are these overrides necessary?

For example:
####..####; B; B
####..####; VM; VMPre

Unicode assigns Indic_Syllabic_Category=Vowel_Dependent and Indic_Positional_Category=Bottom to U+10A0C KHAROSHTHI VOWEL LENGTH MARK, which would put in USE class VBlw. USE overrides it to Indic_Syllabic_Category=Bindu and Indic_Positional_Category=Top, putting it in VMAbv. Why? Kharoshthi already has another character in VMAbv: U+10A0F KHAROSHTHI SIGN VISARGA. If U+10A0C and U+10A0F are in the same class, they may occur in either order; since they don’t really have the same position, this introduces a visual ambiguity.

If the goal is that the vowel length mark follow vowels and precede U+10A0D KHAROSHTHI SIGN DOUBLE RING BELOW, one solution is Indic_Syllabic_Category=Vowel_Dependent and Indic_Positional_Category=Right.

U+0F39 TIBETAN MARK TSA -PHRU is in USE subclass CMAbv. U+0F71 TIBETAN VOWEL SIGN AA is overridden to Indic_Syllabic_Category=Nukta, so it is in subclass CMBlw. Other vowel signs are in subclasses VAbv and VBlw. Therefore, U+0F39 must precede all vowel signs. However, NFC reorders it after all vowel signs. Therefore, a normalized string like <U+0F40, U+0F71, U+0F39> will get a dotted circle.

HarfBuzz handles this by normalizing U+0F39 to precede all vowel signs, but USE explicitly doesn’t support normalization, so how is USE supposed to handle this?

Per Unicode SAH: https://github.com/unicode-org/sah/issues/359
Zanabazar Square needs ISC overrides for the Zanabazar Cluster Finals to permit multiple occurences in a cluster.

U+1BC9D DUPLOYAN THICK LETTER SELECTOR gets Indic_Syllabic_Category=Nukta and Indic_Positional_Category=Not_Applicable. USE does not specify what to do about positionless nuktas: there are only CMAbv and CMBlw. I recommend Indic_Positional_Category=Overstruck for U+1BC9D so it can appear before or after U+1BC9E DUPLOYAN DOUBLE MARK. (I have found no attestation of a shaded double mark, but it is logically possible, and there is no need to disallow it.)

The UTC has approved proposal L2/22-031 to encode the Tulu-Tigalari script in a future version of the Unicode Standard. Pages 22-23 of the proposal discuss the need to override the Indic syllabic category of the Tulu-Tigalari Virama with the value Bindu.

Please implement that override when the future version arrives.

Although created fonts work well when its supported, in most software which either supports imported fonts or system fonts, the rendering does not work.

I should note, this is likely to be the fault of the software not supporting/recognizing the Unicode format controls, I'm not entirely sure but I don't believe this is the fault of the Font/FontTool, but since the developer is developing this for Microsoft, it would be appreciated if we could be updated on when this will be integrated properly into the windows operating system and its software.

Also since third party apps/websites are likely to not integrate this functionality intentionally, it would be great if some kind of workaround could be developed by Microsoft so that whenever the hieroglyph format controls are detected on a website, application, etc. Windows will use a Hieroglyphic Format Control Functional Font to render the glyphs correctly.

I believe that windows currently defaults to Sergio UI Historic whenever it sees any hieroglyphic Unicode characters which includes the Egyptian glyphs to ensure hieroglyphics are always visible. A more sophisticated system being put in place to ensure the format controls always work will be appreciated.

List Of Software I've Tested:

List Of Functional Software:
Microsoft Paint (Partially) (Overlay and Stacking Functions Fine, Cartouche and most other features appear to not work)
DaVinci Resolve (With some very slight common sense adjustments)
Most Web browsers (So long as you reference the font in HTML code)

List Of Non-Functional Software:
Video Editor (A Part Of The Windows Photos App) (Windows 10 and Windows 11 As Photos Legacy) (Supports all hieroglyphic characters, but will not render the format controls at all.)
Paint 3D (Some Text Appears to render properly in preview then renders improperly when actually saving)
Windows 11 UI (Example, renaming a folder or a file using the Hieroglyphic controls)
WordPad
Most Other 3rd Party Software

I should also add, hieroglyphic text on windows is typically small to the point of being illegible under most circumstances. Example: 𓇋𓎼𓊃𓂝𓅓𓊪𓅱. If windows is to integrate correct hieroglyphic rendering, there should also be a system to have hieroglyphic texts default to a much larger size in any circumstance where there is a default font size and its considered too small to be readable for Egyptian hieroglyphic.

The Unicode Standard version 15.0 has a new “Do Not Use” table for Khojki, which should be incorporated into IndicShapingInvalidCluster.txt.

There’re 15 code points still “reserved” but are included in the range 1BC00..1BC99 and are prematurely assigned an override value:

Unicode assigns Indic_Syllabic_Category=Consonant_With_Stacker to U+11003 BRAHMI SIGN JIHVAMULIYA and U+11004 BRAHMI SIGN UPADHMANIYA. USE overrides them to Indic_Syllabic_Category=Consonant. Why? “They enter into ligatures with the following homorganic voiceless stop consonant, without the use of a virama”, according to The Unicode Standard, which makes them consonants with stackers.

USE properties need to be checked against Unicode 14 data changes.

May you explain:
Hieroglyphic shaping glyphs [details to follow]
Variant sizes for Egyptian Hieroglyphics [details to follow]

U+16FE4 KHITAN SMALL SCRIPT FILLER is overridden to Indic_Syllabic_Category=Virama, but that is wrong. Also, it is not useful.

By default, a sequence of Khitan small script letters is rendered as a cluster (similar to a Hangul syllable block) with two letters per row. U+16FE4 forces the preceding letter to be on a row by itself and pushes the following letter onto the next row. U+16FE4 separates letters, whereas a virama joins them, so the override is wrong.

Each KSS letter has USE class BASE. One KSS cluster therefore corresponds to multiple USE clusters (one USE cluster per letter). That makes USE clustering not particularly useful for KSS. Having U+16FE4 put the two surrounding letters in the same USE cluster will still not put the whole KSS cluster into a single USE cluster, so the override is not useful.

Old Uyghur consonants were missed in ISC. They get fallback category in USE because they are defined in ArabicShaping.txt, but they should have a dedicated value in ISC as fallback may vary across implementations.

IndicSyllabicCategory-Additional.txt overrides U+A982 JAVANESE SIGN LAYAR from Consonant_Succeeding_Repha to Tone_Mark, i.e. from USE class CONS_FINAL_ABOVE to VOWEL_MOD_ABOVE. It should not be overridden. The new class lets it mix with other VMAbv characters in any order, but as layar is always placed in the same position relative to those marks, this introduces an encoding ambiguity. For example, <U+A981 U+A982> and <U+A982 U+A981> would be rendered the same.

A comment in the file explains why it was overridden: “Not a repha, because it does not reorder to front of cluster”. This comment is misleading, because it implies that if not for this override, U+A982 would reorder to the front of a cluster. However, because its original Indic_Syllabic_Category is Consonant_Succeeding_Repha, it is not a member of USE class REPHA, so it would not be subject to reordering anyway.

10A38..10A3A ; Nukta # Mn [3] KHAROSHTHI SIGN BAR ABOVE..KHAROSHTHI SIGN DOT BELOW

USE currently overrides all Chakma above-base vowel signs to have Indic_Positional_Category=Bottom. This means that a cluster with an above-base vowel sign and a below-base vowel sign can be written in either order, with no dotted circle inserted. For example, <U+11132, U+11127> and <U+11127, U+11132> look identical because USE considers both valid. To encourage people to use one order consistently, only one of those should be considered valid. Because the canonical decomposition of U+1112F is <U+11132, U+11127>, that order must be valid. Therefore, <U+11127, U+11132> should not be considered valid: a dotted circle should be inserted. To that end, all Chakma below-base vowel signs (U+1112A, U+1112B, U+11131, and U+11132) should be overridden to have Indic_Positional_Category=Top.

I am interested in building the OpenType font for Egyptian, but I have not been able to figure out how. Would it be possible to provide an explanation for how how to build the font? Thank you.

Dear Andrew,

Please don't forget about this project. I know you may think its a small project that most people won't use, but for those who care about stuff like this and find this, its an absolute blessing and miracle. I have wanted something like this for years.

As mentioned prior its terribly incompatible with most software but since you are an employee at Microsoft shouldn't it be as simple as sending a few emails?

I've written suggestions about compatibility in the following link:
#44

Also, a comprehensive screen recorded video tutorial on how to generate fonts would help users create their own varied fonts with additional features without running into errors.

Thanks.

Extension rules need to be reworked so that the extension end blocks the continuation of an extension.