Azure OCR struggles to recognize the symbol "ë"

Marco Nijmeijer 60 Reputation points
2026-08-27T12:02:35.0133333+00:00

The attached PDF contains the word "cliënt" in the sizes 11, 12, 14, 16 and 18 points. Processing this with Azure Document Intelligence OCR (using the OCR Read model, api version 2024-11-30), it recognizes the "ë" for the 16 points version, but not for the other sizes. For the other sizes, the "ë" is returned as an "e".

Using the "high resolution" option, the "ë" is recognized in the 12 points version only.

It helps to specify that the language is Dutch (with the option "locale = 'nl'" in the api call). In that case, the symbol "ë" is recognized for 11, 12 and 18 points, using the "high resolution" option.

This does not seem to make much sense. You would expect that if the "ë" is recognized for a particular size, it is also recognized for larger sizes. And, to be honest, I would expect OCR to be good enough to recognize "ë" in all cases. Anyways, this seems a point where improvement is possible.

E with trema.pdf

Azure Document Intelligence in Foundry Tools
Answer accepted by question author
Pavan Kumar Purilla 410 Reputation points Microsoft External Staff Moderator
2026-09-02T07:50:52.2966667+00:00

Hi Marco Nijmeijer,

We discussed your latest findings with our Backend team. Based on their further investigation, they have confirmed that this is a character recognition issue with the Document Intelligence OCR/Read model, specifically affecting the recognition of the “ë” character in certain scenarios.

The PG team clarified that, for this particular recognition issue, enabling High Resolution or Language Detection does not address the underlying behavior. Therefore, the inconsistent recognition of “ë” at different font sizes can still occur even when Dutch (nl) is specified.

At this time, the PG team recommends trying Azure Content Understanding, where improvements have been made to the recognition algorithms. This may provide better recognition of characters with diacritics such as “ë” and could help address the behavior you are experiencing.

Could you please test the same document using Content Understanding and let us know whether the character is recognized correctly across the different font sizes?

We are also continuing to validate the behavior against the latest available version to ensure there are no regressions.

We appreciate your detailed testing and feedback. Please share the results of the Content Understanding test, and we will continue to work with the PG team based on the outcome.

We tested the latest AR model, and the results look good. No regression issues were observed during testing.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Muhammad Bilal Khan 0 Reputation points
    2026-09-03T09:36:52.2066667+00:00

    This looks like an OCR recognition limitation rather than an issue with the Dutch character itself.

    The fact that "ë" is correctly recognized at some font sizes but returned as "e" at others can happen because OCR recognition is based on the visual features of the glyph, including the small diaeresis marks. The two dots can become difficult to distinguish from noise, anti-aliasing, compression, or other marks depending on the rendered resolution.

    A few things are worth trying:

    Specify the document language as Dutch (nl), as you already observed. Language hints can improve recognition of language-specific characters.

    Try the high-resolution/read option when the source PDF contains sufficiently detailed text.

    If possible, test with the original PDF rather than a scanned or rasterized version, since converting text to an image can reduce the distinction between e and ë.

    If you control the PDF generation, try using a higher-quality rendering/resolution and an embedded Unicode font.

    For a production workflow, consider applying a validation step for known Dutch words where e and ë can be confused.

    Your observation that recognition changes with font size is useful feedback for Microsoft. In particular, the fact that a larger font does not consistently produce better recognition suggests that this is not simply a resolution problem.

    I would recommend including the sample PDF, the exact API request (with any language/high-resolution settings), and the OCR JSON response when reporting this to Microsoft. That gives the Document Intelligence team enough information to reproduce the behavior and determine whether it is a model limitation or a bug.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.