Fonts for hanzi have ten-of-thousands of glyphs without any problems. Biggest file-size I've seen is about 55MB.

Trixie HD Pro Heavy is 16MB. It can slow things down, but behaves normally otherwise.

If I remember well, Arial has 22MB. My preoccupation is : Is a 4MB open type featured font more dangerous than a 8MB non open-type featured ? If a true type font with thousands of gliphs works well, one open-type with multiple programming maybe dont works so well. I am concerning too because my font seems to has much kb, in comparison with simmilar fonts, considering the proportion between number of gliphs and total MBs

What do you mean by 'dangerous' and what sort of problems are you envisaging?

I want mean problems like did slow the system where the font is running. Or, for example, a crash (hypothetical, I never see one) in the use of the font. Does exists limit about the number of interations in the open type programming? Sometimes, some fonts don't works well in CorelDraw, for example. The size of the otf file is not a problem in this case? I dont' know, my feeling is something hard to explain, something like a fear to grow up a font into it don't work like before, when it's was plus small

There are a number of different factors that can increase the byte size of a font significantly, independent of something obvious like the number of glyphs in a font. One is the UPM size: the higher the UPM value, the greater the number of coordinates that will involve 3 or 4 digit values instead of 2 or 3 digit values, ergo a more bytes. Another is outline complexity, i.e. the number of points used to define the outlines: more points equals more bytes. Another is the number and complexity of OpenType Layout lookups.

What matters in all these cases, in terms of functionality, is not the byte size of the font but the processing that have to be applied, e.g. rasterising a complex outline or performing iterative contextual GPOS positioning lookups, and how these fast these processes can be performed.

Generally speaking, the kind of processing memory limitations that would once have made some of this issues critical have been resolved through increased computing power and optimisation of processes. As an example, when Adobe first digitised Jovica Veljovic's Ex Ponto typeface in Type 1 format, they had to spend a lot of time figuring out how to be true to the complexity of the design while not overloading the capabilities of the raster imaging machines of the time. This would not be an issue today because so much more processing memory is available. As another example, when I made the first version of the SBL Hebrew font it was incredibly slow in e.g. Word because of the number of contextual GPOS lookups for Biblical Hebrew, but Microsoft were able to optimise the Uniscribe layout engine code in the next release of Windows and Office, and the font worked 20 times faster.

I doubt if you are hitting anything that I would consider a dangerous threshold.

As for CorelDraw...

Thanks Hudson. I'm calmer now. I already suspected which the number of points is a parcel of the equation. Like the font in case is a script, I am working in a overall revision to cut the excess of points,while I make new gliphs