[milescoviello]

What

A new GuestFontStyleFrame.cpp (registered in libSceFont/CMakeLists.txt like the other font tests) covers the style frame calls: an uninitialized frame is rejected, sceFontStyleFrameInit sets 72 dpi, a scale set in pixels reads back in points through the dpi (and the reverse), UNSET_PARAMETER comes back for each property before it is set and after it is unset, the slant is clamped to 1, the weight to a 0.04 delta around 1, and a weight mode other than 0 is rejected.

Until now no test called it.

Changed: core/libs/prx/libSceFont/CMakeLists.txt, core/libs/tests/GuestFontStyleFrame.cpp. Test only, no change to the library.

Tested

Linux (Ubuntu 26.04, GCC 15.2), Release: cmake --build build --target guest_font_style_frame_tests and ctest -R '^guest_font_style_frame$' --repeat until-fail:3 pass on this branch, which is current main plus the test. tools/check_conventions.py --base upstream/main passes.

Windows (run by maskym: Windows 11, i7-12700K, WinLibs GCC 15.2.0, Release, with other open PRs merged in): guest_font_style_frame passes (comment).

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

🤖 Generated with Claude Code

[MarcZX10]

I checked the new test against the current Style.cpp implementation. The assertions cover initialization, unset/get behavior, pixel/point conversion after changing DPI, optional output pointers, clamping, invalid weight mode, and unset behavior; the expected results match the implementation. The target is registered consistently with adjacent font tests, and diff --check is clean. The author reports the exact target passed three consecutive Linux runs; conventions, eligibility, intake and labels checks pass. I could not independently run the target locally.

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 8250	core/libs/prx/libSceFont/CMakeLists.txt
PR 12018	core/libs/prx/libSceFont/CMakeLists.txt
PR 12025	core/libs/prx/libSceFont/CMakeLists.txt

[maskym]

Windows result for head 984b53cdb9, merged into main 2ee8e9751a (the PR's Tested section names no Windows run).

Host: Windows 11 26300, Intel i7-12700K, WinLibs GCC 15.2.0 (x86_64-ucrt-posix-seh, r6), Release, BUILD_TESTING=ON, Ninja. Build clean.

The tree also carried the open PRs #11172, #10780, #10729, #11614, #10631, #10582, #11584, #11572, all merged cleanly, so the run is a joint one; the tests of this PR are guest_font_style_frame. Together with the whole libc, CesCs, Font, FreeType, LibreSsl3 and NpUniversalDataSystem suites those tests belong to: 160/160 passed, this PR's in 0.04 s; the AudioOut suite separately 21/21. Not run on a PS5.

AI-assisted: yes (Claude Code), the runs and the numbers above are from this machine.

[milescoviello]

@maskym thanks for the Windows run. I've added it to the Tested section.

AI-assisted: yes (Claude Code)

[THEMANnt]

Reviewed 984b53cdb97a8057da571480aa9c7c6715ab486c — approve. The new font-style fixture covers uninitialized/unset states, pixel/point conversion and DPI, null outputs, slant limits and weight validation/clamping. It is linked to the real font library and registered in CTest.

Windows/GCC 15.3 Release native validation from pinned sources: head: 1 passed, 0 skipped; guest_font_style_frame; author base was source-compared: production sources are unchanged; its runtime was not built or executed for this review. This changes test coverage, not production behavior, so an old-production failure is not required. The build reuses matching dependency source pins and the existing FFmpeg package; no full product or game execution is claimed.