Mar 11 2022 06:36 AM - edited Mar 11 2022 06:37 AM
I filed an issue a long time ago about the syntax constraints of the AppXManifest when it comes to having font files where the filename has problematic characters in the file name, such as the space character.
Prior versions of the MMPT were ignoring all installed fonts, so I have been working around the issue myself, but now the MMPT is trying add fonts into the AppXManifest, and fonts with the unusual names now cause MakeAppX to fail within the MMPT. Here is example output from the MMPT log showing the error:
[N2WorkerA]: MakeAppx : error: Failure at packageWriter2->Close( manifestStream, contentGroupMapStream.Get()) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.
[N2WorkerA]: MakeAppx : error: Error info: /*[local-name()="Package" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"]/*[local-name()="Applications" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"][1]/*[local-name()="Application" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"][1]/*[local-name()="Extensions" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/foundation/windows10"][1]/*[local-name()="Extension" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"][1]/*[local-name()="SharedFonts" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"][1]/*[local-name()="Font" and namespace-uri()="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"][1]/@File
[N2WorkerA]: 'VFS\Fonts\%C3%86%20Systematic%20TT%20BRK.ttf' violates pattern constraint of '[^<>":%\|\?\*\x01-\x1f]+'.
[N2WorkerA]: The attribute 'File' with value 'VFS\Fonts\%C3%86%20Systematic%20TT%20BRK.ttf' failed to parse.
[N2WorkerA]: Cleaning up output file "\\?\%UserProfile%\AppData\Local\Temp\b57e223b-1fee-46c3-871b-e312b90f0969.msix".
[N2WorkerA]: MakeAppx : error: Failure at (CreatePackage( overwrite, hashAlgorithm, fileList, outputPath, manifestStream.Get(), forceCompressionNone, performanceOptions, encryptPackage, encryptionOptions, cgmPath, mainPackagePathForResourceExemption, makepriExeFullPath)) - 0x80080204 - The specified package format is not valid: The package manifest is not valid.
[N2WorkerA]: MakeAppx : error: Package creation failed.
[N2WorkerA]: MakeAppx : error: 0x80080204 - The specified package format is not valid: The package manifest is not valid.
My workaround for the issue had been to detect the font file and simply rename the file to have a valid pattern before adding to the manifest. The actual filename is not of importance except for filename conflict within the Windows/Fonts folder where they are traditionally installed to. (When containerized, we only have to worry about name conflict within that package). Applications reference the fonts using attributes internal to the file and not the filename, thus during the packaging process renaming the file and registering the renamed file in the AppXManifest works great.
Fonts with such names typically come from apps that are multi-platform and started out on Linux. The MMPT should either rename the file as part of the capture processing (best), or outright ignore the file with a warning added into the log file, but it should in any case produce a valid package. Of course, fixing the manifest validation would be the ideal solution, but if it hasn't happened after a couple of years I guess that ship has sailed!
Mar 31 2022 10:11 AM
Mar 31 2022 10:52 AM
@ShakersMSFT See file for a link.
Mar 31 2022 10:19 PM - edited Mar 31 2022 10:20 PM
Hi Timothy, can you please give me access to this file. Here's my alias : mridulgupta@microsoft.com
Apr 01 2022 05:08 AM
Dec 11 2022 10:42 PM
Solution@TIMOTHY MANGAN : MSIX Packaging Tool now supports the unusual fonts/non-windows fonts since the release in early August '22.
Dec 11 2022 10:42 PM
Solution@TIMOTHY MANGAN : MSIX Packaging Tool now supports the unusual fonts/non-windows fonts since the release in early August '22.