v1.1.5 Update

[amwx]

FluentAvalonia v1.1.5 update, which features a full pass over all controls to ensure they're visually ok compared to the new WinUI Fluent v2 styles & matching Windows 11.

This PR is just about complete. I'm waiting for a fix in Avalonia for ItemsSourceView to either be pushed into 0.10.8 or for 0.10.9 to be released. If you update to 0.10.8, the NavigationView will break b/c of this bug with the ItemsRepeater/ItemsSourceView

New Controls

• Added InfoBadge control & integration with NavigationView

New features:

• Add support to FluentAvaloniaTheme to for new Windows 11 Segoe UI Variable font (checks for OS Build Version >= 22000)
• Addition of High Contrast theme styles for all controls (this still needs some work, but implementation has begun and should be useable)
• Adds remaining core Avalonia control templates for compatibility with new styles (CaptionButtons, Carousel, EmbeddableControlRoot, Label, ManagedFileChooser, NotificationCard/WindowNotificationManager, NumericUpDown, TabStrip/TabStripItem, TitleBar)
  NOTE: ContentMenu will not be supported in FluentAvalonia - use ContextFlyout
• Replace FluentUI Icons font with WinSymbols3 by robloo for compatibility with WinUI Segoe Fluent

Fixes

• Fixed Icons for InfoBar to more closely resemble WinUI (Fixes [Bug] Incorrect InfoBar Severity Icon #45)
• Fixed ComboBox Placeholder text not showing except on hover (Fixes [Bug] ComboBox Placeholder Text Not Showing #44)
• Added some opacity hacks to prevent pages flashing when navigating using Frame (Fixes Navigation Control Animation Glitch #46)

Miscellaneous

• Ensured Templates & Resources are valid as of Oct 12 for all controls
• Resources in ThemeDictionaries in WinUI are now themed and removed from Control Styles
• Use TemplatedControl.CornerRadius & TemplateBinding for all controls
• Added recent fixes for NavigationView from WinUI
• AcrylicBrush resources now use the WinUI Fallback color
• Updated AvaloniaProperties to use nameof()
• Removed warnings in codebase
• Tweaks to IconElements, including preserving inherited Foreground when using IconSources & using AddOwner where appropriate

Deprecations/Removals

• Removal of Fluent v1 theme from FluentAvalonia

[Other updates to be added as they're completed]

[robloo]

Will this include use of the newly added CornerRadius to controls? It's useful to update code like this.

FluentAvalonia/FluentAvalonia/Styling/Controls/ButtonStyle.axaml

Line 48 in fcfc26f

CornerRadius="{DynamicResource ControlCornerRadius}"

Separately, let me know if you need help with, or run across issues, updating to the WinSymbols3 font.

For example, I can write a quick script to generate https://github.com/amwx/FluentAvalonia/blob/master/FluentAvalonia/UI/Controls/IconElement/Symbol.cs using latest glyph mappings.

I'm not sure if this method is needed at all after this?

FluentAvalonia/FluentAvalonia/UI/Controls/IconElement/SymbolIcon.cs

Line 108 in fcfc26f

private int VerifySymbolCodePoint(Symbol code)

[amwx]

Will this include use of the newly added CornerRadius to controls? It's useful to update code like this.

Yep! I've already started making the changes on some controls.

Separately, let me know if you need help with, or run across issues, updating to the WinSymbols3 font.

Will do. I haven't gotten there yet, I'm still going over the templates to make sure they're up to date, which is a little time consuming.

[amwx]

@robloo
I've started the move to WinSymbols3 and looked through my Symbol enum. I'd say a little over half of the unfilled icons had matches, and most of the filled icons did not. Not surprising since I did build the enum off of FluentUI. I'm not sure how you'd like to handle this since there isn't a code point match in Segoe Fluent. I've linked the 2 new Symbol enums below (I'll probably merge them later, but for now its easier to keep them separate) with the new mappings or where there wasn't a match, the current code point I mapped in FluentUI. Though I didn't realize at the time that the 20px icons were specifically built for desktop, so I always mapped to the largest size available (24 or 48 in most cases, iirc)

Unfilled Icons: https://gist.github.com/amwx/578e4aae716519251b8e09140d2d57c3
Filled icons: https://gist.github.com/amwx/d146a5ee44f94dc8c498ddd07a9ade28

[robloo]

Not surprising since I did build the enum off of FluentUI.

Oh, I thought you were keeping the WinUI Segoe Fluent Unicode points to match upstream. I didn't realize you were building your own symbols different from upstream WinUI.

I'm not sure how you'd like to handle this since there isn't a code point match in Segoe Fluent.

This is no issue really. I can easily build you a new, custom font using a new IconMapping file with whatever you want.

(I'll probably merge them later, but for now its easier to keep them separate)

I would definitely merge these if possible. WinUI uses the suffix 'Fill' so 'Heart' and 'HeartFill' would be in the same enum. https://docs.microsoft.com/en-us/windows/apps/design/style/segoe-fluent-icons-font#layering-and-mirroring

Though I didn't realize at the time that the 20px icons were specifically built for desktop, so I always mapped to the largest size available (24 or 48 in most cases, iirc)

This is also not much of an issue. I already have code that can re-map to whatever icon size you would like. If you want, I can re-map all available ones to size 20 for you automatically.

Some follow-up questions:

1. Is it really a good idea not to match these at all with WinUI upstream? It seems the correct methodology would actually be to use the Segoe Fluent Unicode points, then assign new Unicode points for your new symbols taken from the FluentUI font outside the range used by Segoe Fluent. That means your new symbols would start well above 0xf8b3.
2. With your go-ahead I'll build you a custom font separate from WinSymbols3 that will include new Unicode points. However, I really would keep the existing Segoe Fluent Unicode points in that new font as well for compatiblity.
3. With your go ahead I'll fully rebuild the symbols enum to match the new font I propose along with update Unicode points that don't conflict with upstream Windows. I will start in the range U+F0000..U+FFFFD (Supplementary Private Use Area-A).
4. The mapping file for your new font will be a .json file. I'll create that in my repository but feel free to copy that here as well.

[amwx]

Not surprising since I did build the enum off of FluentUI.

Oh, I thought you were keeping the WinUI Segoe Fluent Unicode points to match upstream. I didn't realize you were building your own symbols different from upstream WinUI.

I meant the when I created the Symbol enum originally. What I actually did was start with the UWP Symbol enum, tried to match what I could of the MDL2 symbols with FluentUI, and then added a bunch of additional icons in there - but it originally was built to fit FluentUI since at the time Segoe Fluent wasn't a thing (or still early) and it and MDL2 have restrictive licenses.

Some follow-up questions:

1. Is it really a good idea not to match these at all with WinUI upstream? It seems the correct methodology would actually be to use the Segoe Fluent Unicode points, then assign new Unicode points for your new symbols taken from the FluentUI font outside the range used by Segoe Fluent. That means your new symbols would start well above 0xf8b3.

Sorry if I made it sound more confusing than it should be, but that's the intent here - to follow your idea of matching Segoe Fluent where possible. I've already mapped what I could to the Segoe Fluent code points. In the two files I linked above, the values are remapped, and I tested it with WinSymbols3 font and it works. Those enum values that are set to zero are the ones that are missing matching code points, and then in comments I put what I'm currently mapping to.

2. With your go-ahead I'll build you a custom font separate from WinSymbols3 that will include new Unicode points. However, I really would keep the existing Segoe Fluent Unicode points in that new font as well for compatiblity.

3. With your go ahead I'll fully rebuild the symbols enum to match the new font I propose along with update Unicode points that don't conflict with upstream Windows. I will start in the range U+F0000..U+FFFFD (Supplementary Private Use Area-A).

4. The mapping file for your new font will be a .json file. I'll create that in my repository but feel free to copy that here as well.

That would be great! Keep the code points that match the same for compatibility and everything else can be put where ever its not in the way. I don't know how much work this is (and I hope its not too much), but your help on this is greatly appreciated!

[robloo]

@amwx Ok, I know how to complete this without too much work -- we are thinking the same now! I'll try to set aside a few hours today/tomorrow to finish it for you.

I will do the following:

1. Create a new mapping file for new symbols that don't exist in upstream WinUI FluentAvaloniaSupplemental.json. These will start in the supplemental private use area-A mentioned above and there should be no overlap with Segoe Fluent Unicode points. This mapping will will ONLY include the symbols that don't exist in Segoe Fluent. Warning: This will be a breaking change from your current Unicode points: I'll be pushing them much higher in the table so they don't overlap with either FluentUI System or Segoe Fluent.
2. Build you a new font using the Segoe Fluent base + merging in your new symbols taken from FluentUI. I'll complete the merge mappings functionality in the SymbolIconManager so I can build a single font from two different mapping files: SegoeFluent.json and a new FluentAvaloniaSupplemental.json.
3. Update all icon glyphs to size 20 where possible
4. I will also merge the enum into a single one for you using the WinUI naming convention 'Fill' instead of 'Filled' suffix. It will include the new Unicode points. I'll try to think of a good way to automate this.

[robloo]

@amwx I ran into several things with the source files. Can you verify what should be done about the cells highlighted in red in the attached workbook? There is no source Unicode point specified for either SegoeFluent or FluentUISymbols.

FluentAvaloniaSymbols.zip

Edit: I think I read this too literally at first. Most of these unknowns originate from the comment "fluentUI codepoint same as nonfilled". It's possible this comment is old and was based off the first version of the enum when everything was just FluentUISystem Unicode points. When you switched relevant glyphs over to SegoeFluent, the comment may now may simply mean "codepoint same as non-filled" -- keep the same Unicode point between filled/nonfilled enums. In that case most of the issues go away. HOWEVER, I would not keep a filled enum value when the filled/non-filled versions are the same. If the Unicode points are the same, don't duplicate and don't include the filled variant.

[amwx]

@robloo The comment "fluentUI codepoint same as nonfilled" means that the unicode value for the filled symbol is the same as the unfilled between the 2 FluentUI font files. I guess that doesn't mean much now that I think about it since 1) the unfilled are remapped, and 2)they're being switched to 20px variants.

I've added the code points for the red cells, and made sure to use the 20px variants so all is ready now. I've also corrected Crop unfilled (I accidentally put the FluentUI value) and Earth where I left off 'E'

FASymbols.zip

[robloo]

@amwx I ran into some complications because the Symbol enum in UWP/WinUI is so old (from Windows 8). The Unicode points it uses for values are no longer in use by SegoeFluent or SegoeMDL2Assets and so are undefined. I really, really want to ensure this new font in Fluent Avalonia is not only compatible with SegoeFluent but also the Symbol enum upstream. Therefore, I'm going to do this correctly and add full support in the Symbol Icon Manager for Segoe UI Symbols and automatically translating them to SegoeFluent. Bottom line: This is going to be a bit more time.

This will be possible because I finally ran across the original Segoe UI Symbols icon definitions here.

[amwx]

@amwx I ran into some complications because the Symbol enum in UWP/WinUI is so old (from Windows 8). The Unicode points it uses for values are no longer in use by SegoeFluent or SegoeMDL2Assets and so are undefined. I really, really want to ensure this new font in Fluent Avalonia is not only compatible with SegoeFluent but also the Symbol enum upstream. Therefore, I'm going to do this correctly and add full support in the Symbol Icon Manager for Segoe UI Symbols and automatically translating them to SegoeFluent. Bottom line: This is going to be a bit more time.

This will be possible because I finally ran across the original Segoe UI Symbols icon definitions here.

No problem. If there's anything you need from me or any way I can help, just let me know. And no worries on time. I discovered last night that the changes made to ItemsSourceView for 0.10.8 broke the ItemsRepeater, and therefore the NavigationView, so this PR will be held until that gets fixed.

[robloo]

I completed the very first build of the mapping file. This generated the JSON file attached below that looks like the given image inside the Symbol Icon Manager. There are errors and I can't build a font from this so there is a fair bit of debugging left I expect. I should have a font by tomorrow though.

This enum is going to be huge -- 505 entries is what it comes out to right now. There are almost 200 in the Windows Symbol enum itself. Then you have added several and included both filled/regular variants. This also doesn't include all the other icons that will be merged in from the standard SegoeFluent font (but won't be in the enum, only the font). When complete:

1. FluentAvalonia.ttf will include all Unicode points available from the WinSymbols3 (Segoe Fluent Icons)
2. FluentAvalonia.ttf will include all Unicode points from the Symbol enum that correspond with the very old Segoe UI Symbol font from Windows 8 (this enum is the only place they are still used).
3. FluentAvalonia.ttf will include all of the new regular/filled icons you've added from the Fluent UI System
4. I will also generate a new Symbols enum for you from this mapping file.

After the initial mapping file is complete, edits should be made within the JSON file directly or through the UI in the Symbol Icon Manager. There is a very complicated build process to generate the initial mapping file but it isn't needed going forward.

FluentAvalonia.zip

[robloo]

@amwx Please give this a good testing:

FluentAvalonia_v1.zip

[amwx]

I've only taken a quick look, but overall it looks like it's working really well. One observation: Were there some new symbols added to the enum, some of them I don't remember being present? That's fine if so, I just want to make sure I'm not going crazy.
There also seems to be some symbols missing, but I'll take a closer look at that later.

In related news, as it stands, the new font file will cut ~2MB off the package/solution size, so that's awesome

[robloo]

Were there some new symbols added to the enum, some of them I don't remember being present?

Yes, I wanted the enum to be 100% compatible with upstream so it includes ALL values from the WinUI Symbol enum. Then I also added in all of your new ones as well. 505 in total.

The font itself includes everything in the enum plus everything in SegoeFluent that exists in the current mapping file. This means the FluentAvalonia font is also compatible with SegoeFluent while including your new symbols as well (in much higher Unicode points so there is no overlap).

The initial build process was more complicated than I would have liked but you can read through it starting here: https://github.com/robloo/SymbolIconManager/blob/acceda83c61b2eb3d26624319ac47678c7e4ebba/Source/Models/Specialized/FluentAvalonia.cs#L33

There also seems to be some symbols missing, but I'll take a closer look at that later.

The enum includes all symbols in WinUI and not all of them have an equivalent in the new font. I just don't know a good mapping for them. This can be improved by updating the SegoeFluent.json mapping file and then rebuilding all fonts. I decided it's better for the enum to have an entry even if the glyph doesn't exist (so copy/pasted code compiles).

In addition, I noticed the conversion to size 20 FluentUISystem SVGs doesn't seem to be working everywhere so I definitely will give the font another look. Just let me know what else you might find and I'll rebuild it next week.

In related news, as it stands, the new font file will cut ~2MB off the package/solution size, so that's awesome

Perfect! Another bonus of the Symbol Icon Manager is can build custom fonts specifically for an app. This is for the same reason: to cut down on app package size. This is especially helpful for some larger apps.

[amwx]

The font itself includes everything in the enum plus everything in SegoeFluent that exists in the current mapping file. This means the FluentAvalonia font is also compatible with SegoeFluent while including your new symbols as well (in much higher Unicode points so there is no overlap).
The enum includes all symbols in WinUI and not all of them have an equivalent in the new font. I just don't know a good mapping for them. This can be improved by updating the SegoeFluent.json mapping file and then rebuilding all fonts. I decided it's better for the enum to have an entry even if the glyph doesn't exist (so copy/pasted code compiles).

Perfect. What I'll probably do is just mark the missing WinUI symbols with an [Obsolete] attribute so they keep their position, but it's known don't use them. Then they can be added back in the future if something becomes available.

I've given everything a closer look, and there's only a few missing that should be there:

These show a mapping, but are showing the 'invalid glyph' character.
CloudBackup/CloudBackupFilled
CloudDownload/CloudDownloadFilled
CloudOffline/CloudOfflineFilled
CloudSyncComplete/CloudSyncCompleteFilled
DockLeftFilled
DockRightFilled
Restore/RestoreFilled
WifiProtected/WifiProtectedFilled

These should be showing something, but don't have a mapping present. These have a code point for the 'Destination' but is undefined for the source.
DockLeft (0xFBF8 in FluentUI)
DockRight (0xFBFD in FluentUI)
DockBottom (0xFF78 in FluentUI)
FontColor (0xF7BF in FluentUI)
MailReply (0xF177 in FluentUI)
PreviewLink (0xF625 in FluentUI)
Scan (0xF68B in FluentUI)

How difficult is it to build the font itself now that the mapping file is generated? Good to know for future use, and if it's not hard I could probably fix the second set above myself.

[robloo]

Yea, what you found with the first set matches with the log file. The build script wasn't able to locate a few SVG files. I'm not sure why but I'll take a look.

The second set is probably because those mappings are missing in SegoeFluent.json (the mapping to build that font). Those mappings are master and will overwrite anything in the custom FluentAvalonia mappings file. I shouldn't be overwriting a good source with a missing one though so that's a bug in merge functionality I'll fix. I'll also update SegoeFluent font itself.

I'll rebuild the font again from initial after fixing this. Don't worry about updating the json mapping file. Afterwards, I'll document how to font, its quite easy on Windows. I'll also probably make a button for known fonts to make it even easier.

Edit: Good idea with the Obsolete attribute too. I'll automatically add that in the generated file for you. Let me know what message you would like for it.

[robloo]

@amwx

Can you please re-review the below list in upstream FluentUISystem repo: https://github.com/microsoft/fluentui-system-icons. It appears they have removed them entirely from the font (they do not exist in the upstream .ttf files and I can't locate the SVG files either). SVG files are critical in order to build a font. They also don't exist anymore in https://github.com/microsoft/fluentui-system-icons/blob/master/icons.md. The only place they are still referenced is FluentSystemIcons-Filled.json and FluentSystemIcons-Regular.json which is why they still are detected and processed by the Symbol Icon Manager.

Perhaps they changed the name and didn't properly update the repository: cloud_backup could now be cloud_archive for example (I can't compare images to tell though). I'm not sure what to do here.

1. It might be easiest to remove them from FluentAvalonia and your enum
2. We can try to find equivalent replacements (assuming they were just incorrectly renamed)
3. We can go back in the FluentUISystem repository history and save a copy of the SVGs before they were removed. Then rebuild the font instead using custom images. (For example the source would be IconSet=Undefined, Name="ic_fluent_cloud_backup_48_regular" UnicodePoint=0)

Important: These appear to have been removed from the .TTF files as well. This means they wouldn't work on your end as soon as you update the TTF files. My guess is these are Windows-specific icons that never should have been released publicly to begin with

Your list

CloudBackup/CloudBackupFilled
CloudDownload/CloudDownloadFilled
CloudOffline/CloudOfflineFilled
CloudSyncComplete/CloudSyncCompleteFilled
DockLeftFilled
DockRightFilled
Restore/RestoreFilled
WifiProtected/WifiProtectedFilled

Build Log

Error: Missing SVG source URL, mapping skipped src=0xF2E8, dst=0xF8039 (ic_fluent_cloud_backup_48_regular)
Error: Missing SVG source URL, mapping skipped src=0xF2E8, dst=0xF803A (ic_fluent_cloud_backup_48_filled)
Error: Missing SVG source URL, mapping skipped src=0xFE5B, dst=0xF803C (ic_fluent_cloud_download_20_filled)
Error: Missing SVG source URL, mapping skipped src=0xF2EC, dst=0xF8040 (ic_fluent_cloud_offline_24_regular)
Error: Missing SVG source URL, mapping skipped src=0xF2EC, dst=0xF8041 (ic_fluent_cloud_offline_24_filled)
Error: Missing SVG source URL, mapping skipped src=0xF2EE, dst=0xF8043 (ic_fluent_cloud_sync_complete_48_regular)
Error: Missing SVG source URL, mapping skipped src=0xF2EE, dst=0xF8044 (ic_fluent_cloud_sync_complete_48_filled)
Error: Missing SVG source URL, mapping skipped src=0xFC03, dst=0xF8060 (ic_fluent_dock_panel_left_48_filled)
Error: Missing SVG source URL, mapping skipped src=0xFC08, dst=0xF8061 (ic_fluent_dock_panel_right_48_filled)
Error: Missing SVG source URL, mapping skipped src=0xF670, dst=0xF80B9 (ic_fluent_restore_16_regular)
Error: Missing SVG source URL, mapping skipped src=0xF67A, dst=0xF80BA (ic_fluent_restore_16_filled)
Error: Missing SVG source URL, mapping skipped src=0xF8B4, dst=0xF812A (ic_fluent_wifi_protected_24_regular)
Error: Missing SVG source URL, mapping skipped src=0xF8CC, dst=0xF812B (ic_fluent_wifi_protected_24_filled)

[robloo]

Ah, I found the commit that seems to have changed all these. The good news is that they likely were just renamed.

microsoft/fluentui-system-icons#331

What will be removed on July 15th

Arrow Growth → Arrow Trending Lines
AutoFit Content → Arrow Autofit Content
Calendar Overdue → Calendar Error
Cellular Unavailable → Cellular Warning
Circle Subtract Arrow Back → Subtract Circle Arrow Back
Circle Subtract Arrow Forward → Subtract Circle Arrow Forward
Cloud Add → Cloud Plus
Cloud Backup → Cloud Arrow Up
Cloud Download → Cloud Arrow Down
Cloud Off → Cloud Dismiss
Cloud Offline → Cloud Off
Cloud Sync Complete → Cloud Checkmark
Convert To Table → Scan Table
Convert To Text → Scan Text
Convert To Type → Scan Type
Dock Panel Left → Panel Left
Dock Panel Right → Panel Right
Dock Panel Top → Panel Top
Document Header Remove → Document Header Dismiss
Extension → Puzzle Piece
iOS Arrow Left & Right → iOS Arrow LTR & RTL
Mail All → Mail Multiple
Office Apps to Grid Dots
Pane Close → Panel Right Expand
Pane Open → Panel Right Contract
Restore → Square Multiple
Set Top Stack → Stack Star
Shield Checkmark → Shield Task
Signed → Checkmark Starburst
Slide Design → Text More A
Text Add → Text Add T
Text → Text T
Usb Port → USB Plug
Usb Stick → USB Stick
WIFI Protected → WIFI Lock

[robloo]

The only thing that was mis-matched was 'Target' which is mapping to RadioButtonFilled from FluentUI instead of '_target_20'

Thanks, I'll be sure to fix that. It's likely an issue with the SegoeFluent mappings.

I don't think WinUI ever uses a SymbolIcon in any of its controls, preferring to map directly to the glyph.

Yes, correct. However, WinUI also defines the resource to use for this {ThemeResource SymbolThemeFontFamily}. This means you should only need to define a new font here and it should be updated everywhere. This is what the Uno Platform does and it works quite well. We even made sure upstream is fixed to never hard-code Segoe MDL2 Assets microsoft/microsoft-ui-xaml#3745.

That said, Microsoft is using some old codepoints that they shouldn't: microsoft/microsoft-ui-xaml#5887. So a few glyphs won't appear even with the new font. I should probably support these old codepoints in the SegoeFluent replacement font (WinSymbols3) but don't because they really should have been obsoleted by now.

I would suggest for Fluent Avalonia you update to the latest codepoints. I have all the mappings from the old, original Segoe UI Symbol codepoints to the new ones in SegoeMDL2Assets/SegoeFluent here: https://github.com/robloo/SymbolIconManager/blob/main/Source/Data/Mappings/SegoeUISymbolToSegoeMDL2Assets.json. It would just be a find-replace and things should work.

If all of this still doesn't get things to work, I never defined a name in the font file so maybe that won't allow you to select the font properly in XAML. You'll need to do something like: "/Assets/Fonts/SourceSansPro-Italic.ttf#Source Sans Pro" I expect.

I'm now wondering if we need to match Segoe Fluent font to accommodate this. They wouldn't need to be in the enum (that's got enough as it is), but will at least need to be in the font file for full compatibility.

I'm already doing this mentioned above. "The font itself includes everything in the enum plus everything in SegoeFluent that exists in the current mapping file. This means the FluentAvalonia font is also compatible with SegoeFluent while including your new symbols as well (in much higher Unicode points so there is no overlap)."

Edit:

Biggest example is the little carets used in the ScrollBars and the CalendarView.

It's entirely possible I couldn't find a replacement symbol for these. So if you have one please let me know. If we talk specific codepoints I think this is easily fixable. How did you get this to work previously?

[amwx]

@robloo Thanks. I got myself confused between still having the old code points but changing the font. I already have SymbolThemeFontFamily declared, now I just have to go back through and change all the code points from FluentUI to the new font which matches WinUI, and switching the fonts should be complete! Huge thanks for all your help.

[robloo]

Let's hope this does it!

FluentAvalonia_v3.zip

There are lots of fixes and synchronizations with upstream SegoeFluent. Major changes include:

• Fixed Target glyph
• Fixed Wifi glyphs that were incorrect, synced with SegoeFluent as well
• Corrected build to automatically use size 20 where possible (was a stupid mistake and an easy fix!)
• Where a name matches with SegoeFluent, SegoeFluent's Unicode point is now used instead of a new, custom one in some cases.

Note that these changes mean everything is updated including the enum as there were Unicode point changes.

I'm pretty happy where things are with the build process even if it's a lot more complicated than I would like. It is also fully automated now. Feel free to browse through the code if you get a chance in the future and you should be able to make updates yourself as needed without too much effort.

• Mapping file build/rebuild process
• FluentAvalonia.ttf build. There is now only 1 button to click and out comes your font!