ENH: expose font_file in Brain.add_text

[PragnyaKhandelwal]

Reference issue (if any)

Fixes #12543.

What does this implement/fix?

This PR exposes a font_file parameter in brain.add_text() and forwards it to the underlying PyVista add_text() call.

This allows users to pass a .ttf/.ttc font file for Unicode glyph rendering (for example, CJK characters and symbols), while preserving current behavior when font_file is not provided.

Additional information

Verification context:

1. Aligns with issue discussion where specifying font_file in PyVista resolves Unicode rendering for add_text().
2. Keeps scope minimal by exposing existing backend capability in the MNE API.

[wmvanvliet]

Really nice work! It would be nice to also test setting font_file as part of one of the unit tests.

[PragnyaKhandelwal]

Thanks for the review @wmvanvliet . I updated the backend to always pass font_file to Plotter.add_text, including None and added a unit test that checks both cases: font_file set to a non-None value and font_file=None.

[PragnyaKhandelwal]

I verified the checks failed....looks like the build_docs failure is due to the ci merge step issue not a doc/content failure from this pr

[PragnyaKhandelwal]

Hi @wmvanvliet and @drammock, just a quick note that I've addressed the feedback regarding the font discovery logic and documentation clarifications.
I've verified the font passthrough locally. Whenever you have a moment, I’m standing by for a final review or any further adjustments needed to get this merged!

[wmvanvliet]

One comment left unaddressed. Why are you using a kwargs dict instead of just passing the parameters to the function? Also, could you please disclose AI usage for this PR?

[PragnyaKhandelwal]

One comment left unaddressed. Why are you using a kwargs dict instead of just passing the parameters to the function? Also, could you please disclose AI usage for this PR?

Well good catch, @wmvanvliet. I’ve switched from kwargs passthrough to explicit parameter passing to match MNE style.
Also, yes, I used Gemini as drafting assistance for parts of this PR, then manually reviewed/edited the final changes. I should have disclosed this earlier and will do so clearly in future PRs.

[PragnyaKhandelwal]

At this point, only ci/circleci: build_docs is failing (looks like a CI timeout during docs build), while the other checks are passing. Could you please re-run that job when convenient?

[drammock]

looks like a CI timeout during docs build

actually, I suspect it was a network error; looks like the objects.inv file for SciPy failed to get properly fetched, causing all crossrefs to SciPy's API to fail. docs.scipy.org appears to be back up now, so I've restarted the job.

[drammock]

@wmvanvliet this LGTM. I've enabled auto-merge but IDK if it will actually work since you have a "request changes" review. Can you look again and approve if happy? (or, wait and see what automerge does in this case!)

[drammock]

looks like a CI timeout during docs build

actually, I suspect it was a network error; looks like the objects.inv file for SciPy failed to get properly fetched, causing all crossrefs to SciPy's API to fail. docs.scipy.org appears to be back up now, so I've restarted the job.

OK, it's not transient. Probably the objects.inv has moved. Will need to investigate.

[larsoner]

Could it be this, ~73% reliability lately?

scipy/docs.scipy.org#102 (comment)

[drammock]

Could it be this, ~73% reliability lately?

scipy/docs.scipy.org#102 (comment)

could be. Intersphinx registry has the correct URL, and I am able to download it manually.