C headers lack defines for alasied codepoints

[TheLastRar]

The unicode codepoints listed under aliases are not represented as defines.

I noticed this a arrow-rotate-left/right was aliased to a codepoint that conflicted with another font, but the script we use to handle this missed this conflict because this aliased codepoint was not absent from the header.

Would it be possible to have these included in the headers?
It seems that the aliased codepoints are also useful for duotones, although this is not our use case.

[TheLastRar]

Actually, we might have a need for the aliased codepoint for equals

[dougbinks]

We generate the defines using the listed names and their codepoints.

Font Awesome's yml file also contains aliases: names which we don't parse but potentially could.

It seems that the aliased codepoints are also useful for duotones, although this is not our use case.

This won't give you duotone fonts. To get duotone fonts would require understanding how the layers are represented, then parse the extra icon information for the two layers, and finally users would need to change how they render fonts to ensure they set colors and move the rendering position to overlay the fonts.

Actually, we might have a need for the aliased codepoint for equals

I can't see an alias for equals.

The simplest workaround for now to use aliased codepoints would be to use the unaliased name, or add those you need manually:

#define ICON_FA_ARROW_LEFT_ROTATE  ICON_FA_ARROW_ROTATE_LEFT
#define ICON_FA_ARROW_ROTATE_BACK  ICON_FA_ARROW_ROTATE_LEFT 
#define ICON_FA_ARROW_ROTATE_BACKWARDS  ICON_FA_ARROW_ROTATE_LEFT
#define ICON_FA_UNDO  ICON_FA_ARROW_ROTATE_LEFT 

We'll look into adding the aliases in the future, but I don't think duotone codepoints are within our scope.

[TheLastRar]

Actually, we might have a need for the aliased codepoint for equals

I can't see an alias for equals.

I see one for composite, along with the duotone layers

https://github.com/FortAwesome/Font-Awesome/blob/af620534bfc3c2d4cbefcfeec29603bbe7809e64/metadata/icons.yml#L14649-L14658
equals has a unicode of 3d, but is aliased to f52c

The simplest workaround for now to use aliased codepoints would be to use the unaliased name, or add those you need manually:

#define ICON_FA_ARROW_LEFT_ROTATE  ICON_FA_ARROW_ROTATE_LEFT
#define ICON_FA_ARROW_ROTATE_BACK  ICON_FA_ARROW_ROTATE_LEFT 
#define ICON_FA_ARROW_ROTATE_BACKWARDS  ICON_FA_ARROW_ROTATE_LEFT
#define ICON_FA_UNDO  ICON_FA_ARROW_ROTATE_LEFT 

We'll look into adding the aliases in the future, but I don't think duotone codepoints are within our scope.

To elaborate further on our specific usecase.

We load multiple fonts together in ImGui as a merged font.
We are in the process of updating ImGui to wip 1.92 which has changed how glyph ranges are specified.
Instead of specifying glyph ranges to include, we now have to specify glyph ranges to exclude
We have a python script to would scan the header file and create exclusion glyph ranges to avoid one font overriding another.

ICON_FA_ARROW_ROTATE_LEFT is defined as unicode f0e2, but is also aliased to Unicode 21ba
Unicode 21ba was used by a different icon font, but our code ended up loading the aliased ICON_FA_ARROW_ROTATE_LEFT instead of the desired icon, an exclusion was not generated as our script was written under the assumption that the header had all codepoints defined.

As a workaround, we added an exclude range for all codepoints outside the PUA* (as otherwise we would need to add defines for all aliased codepoints for our script).

As a result of that workaround, ICON_FA_EQUALS wasn't usable and we needed the aliased codepoint. Initially we added a define for this, before later switching to a different icon.

*This is only a partial workaround, as our script will still miss icons aliased into the PUA (i.e. equals)

[dougbinks]

Ah, my apologies I thought you were asking for the aliased names.

We are in the process of updating ImGui to wip 1.92 which has changed how glyph ranges are sopecified.

This is something we'll need to investigate to ensure we can produce information to aid compatibility with the new imgui dynamic font approach.

ICON_FA_ARROW_ROTATE_LEFT is defined as unicode f0e2, but is also aliased to Unicode 21ba
Unicode 21ba was used by a different icon font, but our code ended up loading the aliased ICON_FA_ARROW_ROTATE_LEFT instead of the desired icon, an exclusion was not generated as our script was written under the assumption that the header had all codepoints defined.

Our header does not have all codepoints defined.

As a result of that workaround, ICON_FA_EQUALS wasn't usable and we needed the aliased codepoint. Initially we added a define for this, before later switching to a different icon.

Our min and max ranges in the header also ignore fonts in the standard ascii ranges (so not all the non-PUA ranges). Adding code to select an alternative codepoint in the PUA might be possible.

Is there any reason why you could not define the exclusion ranges using ICON_MIN_FA and ICON_MAX_FA?

[TheLastRar]

Is there any reason why you could not define the exclusion ranges using ICON_MIN_FA and ICON_MAX_FA?

The current range closely matches the BMP PUA range (and thus what I currently had the exclusion range set for)

I was not sure if future updates would continue to have ICON_MIN_FA/ICON_MAX_FA ignore icons in the ascii range

[dougbinks]

We should be more specific about this, but yes.

Indeed we probably shouldn't include the ascii icons, as the code we show (and use) will just use the currently loaded font in the ascii range.