sceFontWritingInit took a reference on the string's host character
storage and kept it in the caller's SceFontWriting bytes. Only a later
sceFontWritingInit on the same, unchanged bytes dropped it, so every
string drawn with a fresh, zeroed or overwritten writing leaked its
characters, and re-initialising both copies of a copied writing dropped
its one reference twice. A SceFontWriting has no teardown export, so it
is plain caller memory and cannot own anything.
sceFontCreateString now allocates the characters through the string's
FontMemory, as it already did the string, so no character pointer the
guest receives points into host memory. sceFontDestroyString clears
the string's magic and frees both, and a failed create clears it before
freeing the string. A writing keeps only a pointer to its string and
checks the magic on every step, so after the destroy its steps return
null unless that memory holds the magic again, as when a new string is
allocated there. An init that fails after resetting the writing still
leaves it stepping nothing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A string created from a text source in the default horizontal form (0x10)
reported 0x10. TEKKEN: DARK RESURRECTION (PPSA31371) passes the reported form
to sceFontCreateWritingLine, which only accepts 0x11 and 0x12, so the call
failed and the layout width was 0.
On firmware 13.42 sceFontCreateString decides the direction for a default-form
source and sceFontStringGetWritingForm returns the stored form. The string
gets 0x12 when its first strong character is left to right, 0x11 when it is
right to left, and 0x12 when it has none. Left-to-right and right-to-left marks
count as strong, embeddings and overrides do not, and text between an isolate
initiator and its PDI is skipped. Explicit 0x11 and 0x12 sources keep their
form.
The test follows the table reported on the pull request. Which characters are
strong is decided by Unicode block ranges here, not by the full bidi class
tables.
sceFontOpenFontFile resolves guest paths, so a host-absolute temporary
path resolved beneath the run directory on Linux.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
sceFontCharactersRefersTextCodes fills a 64-byte FontTextCodes with the
order and code of a text character and keeps the current, start and
term characters at +0x28, +0x30 and +0x38. The traversal follows the
PS4 11.00 libSceFont.sprx disassembly posted in the review of #4050,
which implemented the same rules: Refers never compares the character
with the term and returns null for a clustered or synthetic character,
sceFontTextCodesStepNext returns null at the term after visiting it,
sceFontTextCodesStepBack returns null at the start character, and both
steps skip synthetic characters. Null from StepNext at the end of the
chain and from StepBack at the head of the chain is assumed and not
covered by the report.
The signatures follow Orbital's IDA type database and SharpProspero. A
null cursor or output returns null as in KytyPS5; a null text character
throws. guest_font_tests gets configure_windows_unwind so the expected
exception reaches the test on Windows.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
The call was an unimplemented stub. It now writes syllable state 0 and
returns OK for every character outside the Thai block, where a PS4
firmware 11.00 libSceFont measures 1, 3 or 4; Thai characters throw as
not implemented. A null character or result returns
SCE_FONT_ERROR_INVALID_PARAMETER, and a null character writes 0 to a
non-null result, as measured. The signature follows SharpProspero.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
The second argument is an out pointer to the writing's letter step, as
KytyPS5 and the SharpProspero bindings declare it. It was filled as a
letter step struct, which wrote 64 bytes over the caller's 8-byte
pointer. The letter step now lives in the writing and the call stores
its address, or null when there is no current step.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
sceFontSetScriptLanguage, sceFontGetScriptLanguage,
sceFontSetTypographicDesign and sceFontGetTypographicDesign threw. With
the signatures SharpProspero declares, a font handle now keeps the
language set for each script and the feature set for each typographic
design, under the handle's lock, and returns them, with 0 for one never
set. They do not change shaping or rendering yet; TechnicalDebt records
the assumptions.
Claude-Session: https://claude.ai/code/session_012SLQbhAiexxW6TtjYToW8a
(cherry picked from commit c4dcbe4403dc635fde2a823dec311a939816cefc)
Detach the device cache buffer attached by sceFontAttachDeviceCacheBuffer. The signature is taken from the IDA type database of Orbital: it takes the library, a pointer to receive the buffer and a pointer to receive its size. When no cache buffer is attached, it reports NOT_ATTACHED_CACHE_BUFFER. If the library allocated the buffer itself and no buffer pointer is passed, the memory is freed. The owned bit is cleared and device_cache_buf is reset to null.
PPSA01325 stops on sceFontGlyphDefineAttribute right after generating a character glyph: it sets attribute 0x11 to 0 on that glyph, deletes it without using it, and draws the character with sceFontRenderCharGlyphImageHorizontal. The meaning of the attributes is unknown, so the call checks the glyph and ignores the rest; TechnicalDebt lists it under silent stubs.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01UTjpbMX7BUFMZZaxJE98zV
Dean