moi15moi

@justvanrossum Have you missed anthrotype message?

I am not 100% sure if it does what it need. There a difference in length between the cmap and the maxp.numGlyphs. ```py from fontTools.ttLib.ttFont import TTFont ttFont = TTFont("PURIB10.TTF")...

> > I am not 100% sure if it does what it need. > > It would be helpful if you try: apply the patch, and see if the error...

To reproduce the problem, use this .ass and this font [nyala.zip](https://github.com/libass/libass/files/15096385/nyala.zip) ``` [Script Info] ; Script generated by Aegisub 9706-cibuilds-20caaabc0 ; http://www.aegisub.org/ ScriptType: v4.00+ WrapStyle: 0 PlayResX: 1280 PlayResY: 720...

I tested this PR. The first commit does fix the segmentation fault, but the second doesn't.

I may be wrong, but I think it is because aegisub support files encoded in UTF-8 with BOM. It doesn't support file in UTF-8 without BOM.

The beta is now available: https://www.python.org/downloads/release/python-3140b1/

I tested with [IDWriteFontFallback::MapCharacters](https://learn.microsoft.com/en-us/windows/win32/api/dwrite_2/nf-dwrite_2-idwritefontfallback-mapcharacters) and it also return no font, so it isn't the IDWriteTextLayout "technique" that doesn't always work.

Now (windows version 10.0.19045.6332), VSFilter display the character correctly, but libass doesn't. I guess microsoft fixed GDI, but not dwrite.

Note that even if Fontcollector is in python, there is still a way to communicate with a python program with [PythonNet](https://github.com/pythonnet/pythonnet). > For super reliable ASS _parsing,_ though, I simply...