search

notofonts / egyptian-hieroglyphs

Noto Egyptian Hieroglyphs
SIL Open Font License 1.1
7 stars 1 forks source link

Add hieroglyphic variants controlled by variation selectors #6

Open dwerning opened 2 years ago

dwerning commented 2 years ago

Title

Add hieroglyphic variants controlled by variation selectors to Noto Sans Egyptian Hieroglyphs

Font

NotoSansEgyptianHieroglyphs-Regular.ttf

Font Version

Version 2.0

Feature request

In the context of Unicode 15.0, variants of the hieroglyphic chars are defined that are controlled by the an eventually following Variation Selector (U+FE00 ff.). These are generally rotated vatiants of the modified sign, without any changes of details of the sign itself, e.g., U+132A4 grafik U+132A4&U+FE02 grafik

Please consider to add this capability to react to VS to Noto Sans Egyptian Hieroglyphs font.

Mercury13 commented 8 months ago

@dwerning, I looked into your proposal — four funky thousand hieros! How shall we draw them? My current concern is font’s metrics, no point to draw new ones until we fix them.

Mercury13 commented 8 months ago

I can write a program that automatically creates these rotations. But IDK how to make CCMP or RLIG for these rotations.

simoncozens commented 8 months ago

I'm a little bit uneasy about adding "partial" layout to the font, especially if it is going to mean thousands of extra glyphs. I'm not sure how beneficial it is to add rotations if we're not also supporting inclusions, subdivisions, etc. The long-term plan is to support all of these things via the WASM-based shaping engine (https://github.com/harfbuzz/harfbuzz-wasm-examples#hieroglyphs); I am not sure if there's much benefit in doing a bit of the job in OpenType.

Mercury13 commented 8 months ago

It’s going to mean ≈200 glyphs.

aelatham commented 1 month ago

This is tame compared to adding the Unicode 16.0 additions, which should be done around the same time that this issue starts getting fixed.

Update: I now realize that this statement is incorrect. 16.0 additions are being imported from SVGs by a certain contributor! Hieroglyphic variants are harder.

dwerning commented 1 month ago

Rotations

As for rotations, there are only 100 cases (https://unicode.org/Public/UCD/latest/ucd/StandardizedVariants.txt, as of 09/13/2024). And there are another 10 cases coming with v16 (https://www.unicode.org/L2/L2024/24177-additional-var-selectors.pdf).

I agree that while the implementation of rotations is very welcome and appreciated, they are only indispensable if the control characters (notably vertical/horizontal alignment, insertion, mirroing) are also functional (issue #1).

Hieroglyphs

With v16, there are almost 4,000 new hieroglyphs. As far as I know, the font used in/for the Unicode proposal will be released under an OFL. Shapes for the new characters can probably be taken from it?

Mercury13 commented 1 month ago

@dwerning Where to find that font?

simoncozens commented 1 month ago

I don't think people appreciate how absolutely insane the task of supporting format controls is in OpenType. The hieroglyphs format control system is - necessarily - very complicated and unlike every other kind of variation selector.

I think it's probably the right way to encode it, but it leaves font implementors with a huge headache: format controls encode a parse tree, so even working out what glyphs to draw requires writing a recursive parsing engine inside a font, in OpenType Layout - which, to put it mildly, was not designed for such purposes. The WASM shaping engine can help with this part somewhat.

Even once you have worked out what you're drawing where, OpenType font technology assumes that the glyphs as drawn are known at render time. The only control you have over them is which glyph to select from the repertoire and where to position it. But to support format controls you need arbitrary scaling at render time - which you don't have - so you need to pre-render each glyph at all the appropriate sizes you are ever going to need inside the font. (And WASM isn't going to help you here; that only handles shaping; that is, glyph selection and placement - we can't communicate scaling information from the shaping engine to rendering engines, which are generally separate.)

If the font technology had the ability to dynamically scale, rotate, mirroring, etc. the glyphs during shaping, we'd be fine. It would be relatively easy. But if we want to do this in OpenType, there is this huge problem of needing all the relevant variants to be baked in. We may only need a hundred extra glyphs for the rotated variants, but again each of these would need to be pre-rendered at all the possible sizes it would be shaped at.

Ultimately I think I have to sadly conclude that OpenType is just sadly not up to the challenge of performing hieroglyph layout. Something like Javascript/SVG, where you have full control of how stuff is drawn, is much more suitable.

I'm not going to give up, and I'm going to do my best to support what's possible, but people should be aware when requesting these things being added to Noto Sans Hieroglyphs that we are strongly constrained by font technology and ultimately fighting a losing battle.

khaledhosny commented 1 month ago

Is https://github.com/microsoft/font-tools/blob/main/EgyptianOpenType/eot.md any good for Noto?

simoncozens commented 1 month ago

My understanding is that this only solves the shaping part of the puzzle - i.e. the bit we know how to fix with WASM. And it only solves it to two levels of nesting. (I fully intend to use the complexity of hieroglyph layout as a wedge to push the WASM shaper into production...)

It doesn't seem to generate the size/mirrored/rotated variants - although I suppose that is something that could be scripted, now that I think about it.