The use of a fallback font seems to cause a state where the original font can't be set

[carlmanaster]

Describe the bug

After writing a string which requires use of the fallback font, the pdf is left in a state where the current font is the fallback font and setting the font to the primary font no longer works. You can, however, set to a third font and then back to the primary font. The test case below demonstrates the problem

Error details
There is no error message; it is simply that set_font() to the original font does not change the value of current_font.

Minimal code

def test_fallback_font_use_invalidates_subsequent_set_font():
    pdf = FPDF()
    pdf.add_page()
    pdf.add_font('primary', "", FONT_PATH / 'NotoSansThai-Regular.ttf', uni=True)
    pdf.add_font('fallback', "", FONT_PATH / 'NotoSansCJK-Regular.ttc', uni=True)
    pdf.add_font('spare', "", FONT_PATH / 'PlusJakartaSans-Regular.ttf', uni=True)
    pdf.set_font('primary')
    pdf.set_fallback_fonts(['fallback'], exact_match=True)

    mixed_font_string = '3 มิ.ย. 2025' # some glyphs from primary and some from the fallback font

    # we can switch between fonts
    assert pdf.current_font.fontkey == 'primary'
    pdf.set_font('spare')
    assert pdf.current_font.fontkey == 'spare'
    pdf.set_font('primary')
    assert pdf.current_font.fontkey == 'primary'

    pdf.cell(0, 10, mixed_font_string)

    # the mixed font string leaves us with the fallback font as the current font
    assert pdf.current_font.fontkey == 'fallback'
    # and we can still switch to another font
    pdf.set_font('spare')
    assert pdf.current_font.fontkey == 'spare'
    pdf.set_font('primary')
    assert pdf.current_font.fontkey == 'primary'

    pdf.cell(0, 10, mixed_font_string)

    # the mixed font string leaves us with the fallback font as the current font
    assert pdf.current_font.fontkey == 'fallback'
    # but we can no longer switch to the original primary font
    pdf.set_font('primary')
    assert pdf.current_font.fontkey == 'primary' # fails; it is still "fallback"

Environment
Please provide the following information:

• Operating System: Mac OSX
• Python version: Python 3.13.3
• fpdf2 version used: fpdf2==2.8.3

[Lucas-C]

Thank you for this excellent detailed bug report 👍

I tried to reproduce it using the test fonts we already have in this repository, by adding the following test to test/fonts/test_font_fallback.py:

def test_fallback_font_use_invalidates_subsequent_set_font_ok():
    pdf = FPDF()
    pdf.add_page()
    pdf.add_font(family="Roboto", fname=HERE / "Roboto-Regular.ttf")  # primary
    pdf.add_font(family="Roboto", style="B", fname=HERE / "Roboto-Bold.ttf")
    pdf.add_font(family="DejaVuSans", fname=HERE / "DejaVuSans.ttf")  # fallback
    pdf.add_font(family="Quicksand", fname=HERE / "Quicksand-Regular.otf")  # spare
    pdf.set_font("Roboto", size=15)
    pdf.set_fallback_fonts(["DejaVuSans"], exact_match=True)

    # we can switch between fonts
    assert pdf.current_font.fontkey == "roboto"
    pdf.set_font("Quicksand")
    assert pdf.current_font.fontkey == "quicksand"
    pdf.set_font("Roboto")
    assert pdf.current_font.fontkey == "roboto"

    write_strings(pdf)  # some glyphs from primary and some from the fallback font

    assert pdf.current_font.fontkey == "roboto"
    pdf.set_font("Quicksand")
    assert pdf.current_font.fontkey == "quicksand"
    pdf.set_font("Roboto")
    assert pdf.current_font.fontkey == "roboto"

    write_strings(pdf)  # some glyphs from primary and some from the fallback font

    assert pdf.current_font.fontkey == "roboto"
    pdf.set_font("Roboto")
    assert pdf.current_font.fontkey == "roboto"

Interestingly it does not reproduce your bug.
Does it depend on the position of the characters in the string rendered?

[andersonhc]

I got the fonts from google fonts and executed the minimal code example but I can not reproduce the problem. After the call to fpdf.cell the fontkey is still 'primary'

I am running python 3.13.4, fpdf2 2.8.3, but on Windows.

[carlmanaster]

Thank you for the prompt responses.

I wonder if the character order does matter. The string I'm using, 3 มิ.ย. 2025, breaks down into the following chunks:
[('fallback', '3 '), ('primary', 'มิ'), ('fallback', '.'), ('primary', 'ย'), ('fallback', '. 2025')], and it may be that because it ends in a fallback character it leaves the system in a state where the current font is the fallback font. I don't understand why you're unable to reproduce the problem with the provided text, but perhaps the behavior differs between Mac and Windows.

[carlmanaster]

If I replace the string with one which includes only a single fallback-font character, 3, for me the behavior is the same as using the mixed-font string. If I replace it with one which includes only a single primary-font character, ม, it fails instead on the assertion following the cell() call, because it has (understandably) not changed the current font to be the fallback font.

[Lucas-C]

I wonder if the character order does matter. The string I'm using, 3 มิ.ย. 2025, breaks down into the following chunks:
[('fallback', '3 '), ('primary', 'มิ'), ('fallback', '.'), ('primary', 'ย'), ('fallback', '. 2025')], and it may be that because it ends in a fallback character it leaves the system in a state where the current font is the fallback font.

I do not think so, because the unit test I shared uses write_strings() from test/fonts/test_font_fallback.py that renders a string whose last character is also from the fallback font, but the bug you reported does not appear...

I wonder if it could be related to the fonts used?

@carlmanaster would you be able to reproduce this bug with other fonts? Could it be related to ligatures or another "special" font property?

To be clear: I think this is indeed a bug with fpdf2, I'm just looking for a clear minimalist case that would make the origin of this bug obvious, so that we could easily pinpoint its origin in the code, and then fix it.

@carlmanaster: is it Vietnamese text that you are tring to render?
I don't known much about non-latin languages, sorry 😅
In the past we had fpdf2 contributors who tested Thai text rendering, and we have unit tests using the Waree font.
I wonder if this bug could be reproduced with one of the fonts already present in this repo test/fonts/ directory.

Of course this bug may be specific to some fonts / languages, and we could introduce unit tests with new fonts, like the one you provided.