If somebody types a letter, then sets a font size of the letter to 99 or more, then chooses the font named "Flut Saus" (http://www.dafont.com/flutsaus.font), there will be an AV:
Project .... raised exception class EAccessViolation with message 'Access violation at address 0113EBB4 in module '...'. Read of address 4A9B1ED0'.
It is because of uninitialized variable Result in the function MaxFitSafe. The value of the variable is bigger than the length of the word.
As I can see, Result should be initialized here:

But it does not happen, because of function Windows.GetTextExtentExPointW. It returns False and does not calculate any other values.
The font Flut Saus is not only one that makes this error.
TRVWinGraphicInterface.GetTextExtentExPoint_W is a procedure so we cant check its result.
What can we do to prevent this error?

I am running into the same error. However in my case I don't have a font that large. I have a customer who just purchased a new computer that is getting this on all our reports.

We are performing a custom mail merge and displaying the results in a Scale Rich View. We are getting the AV on line 1895 in MaxFitSave where result is used as a index in the PRVWordArray.

What I can't figure out is why GetTextExtentExPoint is failing in the first place. If I can figure that out I can fix his machine. Since the code does not call GetLastError when GetTextExtentExPoint fails I stuck. Any ideas on what can cause the call to fail for a document that works fine on other machines?

Are you sure that this is AV, not a range check error?
For correct working, TRichView must be compiled without range checking.
In the new version of TRichView, it is by default, RVNORANGECHECK is defined in RV_Defs.inc

We did track this down to an install issue. We use the Arial Narrow font in our templates. The user had installed Office (which includes that font) but had not yet rebooted their computer.

The font lookup normally just falls back to Arial if the Narrow version cannot be found. It seems like the Office install put things in a weird state where the font was there but could not be used by GetTextExtentExPoint. That's my theory anyway. We rebooted the computer and it started working again.

I cannot reproduce this problem with flutSaus font (I tried both OTF and TTF versions, with font sizes up to 200pt).
However, I added a check on results of GetTextExtentExPoint. If it fails, the component will try using GetTextExtentPoint32. If it fails, the component assumes zero size for the text. No AV should occur any more.