To fix compile error for pyhton-binding error, it maybe better to use char* instead of uchar*.

Two functions reference different Freetype APIs. It would be better to have one or the other in common.

• Idea1) To use FT_Open_Face() for file and memory.
  • both functrions construct FT_Open_Args for file and memory.
  • new helper function receives FT_Open_Args and idx.
• Idea2) To use FT_New_Face() for file, and to use FT_New_Memory_Face() for memory.

The docs for FT_New_Face and docs for FT_New_Memory_Face say explicitly to use FT_Open_Face for both loading from file or buffer. My PR was specific to adding more functionality, so i didnt want to change old code in the same PR.

Thank you for your comment. It is OK. I think there is no problem.
In this pull-request, the FreeType function to be called was switched with an additional commit, so I confirmed the intention. thank you very much !!

I think to check pBuf and bufSize is needed.

yes but i do not want to assert.
i think both loading functions should return a result indicating if the loading was successful.
loading from file is an inherently failable i/o operation, so asserting there is very bad practice imo.

The reason why the loadFontData() function has no return value is because there is no way to recover if this function fails. If this function returns some errors, I believe it is difficult/hard to do anything. Is it better to continue with missing drawing ?

And If an inappropriate/invalid argument is set, it would be better to use CV_Assert() to indicate that there is a problem with the user program implementation/calling.

• If pBuf == nullptr and/or bufSize == 0 are invalid input. (We can omit to check bufSize.)
• In other case, if pBuf[0...bufSize] are invalid/broken font data, we expects Face_Open_args() will be return with failed.　It will be captured with CV_Assert().
• In other case if pBug[] buffer is smaller than bufSize, we cannot do anything. Only what we can do is user-application handle it correctly.

You could recover by trying to load another font. A lot of cpp programs (including all of mine) have exceptions disabled, by asserting you remove their option to handle it in a way they want to. If a user wants to, he can still assert the return value

1. I think it is difficult to use another/alternative fonts.

• Cases where header data is corrupted can be caught at loadFontData() stage. This is a case where clearly incorrect data such as image data is specified.
• Cases where glyph data is corrupted cannot be caught until the putText() stage, which reads and renders the glyph data.(When glyph data of A is broken, if A is not contained strings for putText(), there are no problem.)

With your design, that means if putText() failed, we should re-call loadFontData() with another font and retry to call putText(). I think it is too complex.

2. Exception handling is a prerequisite for using OpenCV. Following is OpenCV Introduction Error Handling Section section.

OpenCV uses exceptions to signal critical errors. When the input data has a correct format and belongs to the specified value range, but the algorithm cannot succeed for some reason.