ASS header PlayRes is dropped when the script uses CRLF, so every \pos normalizes against the 384x288 default

[rrgomes]

Embedded ASS with \pos lands off-picture. Text and timing are correct; the placement is not. An anchor the script puts at 90% of frame height arrives at the host as 1.5.

The source: a 706x480 H.264 title in Matroska with one embedded ASS track, 2040 dialogue lines, every one carrying {\an1\pos(x,432)}. The header declares PlayResX: 718 / PlayResY: 480.

What reaches the host for {\an1\pos(298,432)} is align=1 pos=(0.7760, 1.5000). Expected (298/718, 432/480) = (0.4151, 0.9000). Observed is (298/384, 432/288), the spec default PlayRes, so the declared one was never read.

Cause

SubtitleRectText.playRes(fromASSHeader:) splits the header on \n and then trims with CharacterSet.whitespaces, which contains space and tab but not \r. ASS headers are conventionally CRLF, and this track's CodecPrivate is:

00000030: 6f72 6d61 6c0d 0a50 6c61 7952 6573 583a  ormal..PlayResX:
00000040: 2037 3138 0d0a 506c 6179 5265 7359 3a20   718..PlayResY: 
00000050: 3438 300d 0a54 696d 6572 3a20 3130 302e  480..Timer: 100.

So the line is "PlayResX: 718\r". The hasPrefix check passes, and then Double("718\r") returns nil. Both lookups fail, the guard returns nil, and both SubtitleDecoder and EmbeddedSubtitleDecoder keep defaultASSPlayRes.

Running the function exactly as written:

CRLF header -> nil            (falls back to 384x288)
LF header   -> 718.0x480.0

Why the tests do not catch it

Every PlayResX fixture in Tests/ is a Swift multi-line string literal, so LF only. The one CRLF fixture, ASSScriptBuilderTests.swift:54, exercises ASSScriptBuilder rather than this parser.

Fix

.whitespacesAndNewlines at SubtitleRectText.swift:79 and :81. They are the only .whitespaces trims in that file's header path; lines 21 and 66 already use the newline-inclusive form.

Blast radius

Any ASS or SSA track whose header is CRLF, which is the common case for muxed subtitles. It fails silently: a \pos normalized against 384x288 instead of a declared 1920x1080 lands at 5x the intended coordinates, and anything past 1.0 leaves the picture entirely, which looks exactly like a cue that never arrived rather than like a misplaced one. Tracks that declare no PlayRes are unaffected, since 384x288 is then the correct basis, as are tracks whose declared PlayRes happens to be 384x288.

This is also why the bug was invisible before 5.28.1: insertCueSorted dropped placement on everything entering the retained store, so on the drained embedded path the wrong coordinates never reached a host at all and the cue rendered unplaced. Retaining placement is correct, and it is what surfaced this.

On our side

We now ignore an anchor outside [0, 1] and fall back to alignment-only placement, on the reasoning that an out-of-range anchor means the normalization basis was wrong rather than that the source asked for an off-picture caption. That is worth having regardless of this fix, because a cue drawn off-picture is indistinguishable from one that never arrived, which is an expensive thing to debug. It is a fallback, not a substitute: with the basis wrong the cue is still in the wrong place, just a visible one.

Version

Observed on 6.1.0 (fa2a5132). Confirmed still present at 6.1.3: the surrounding file changed substantially for the teletext work, but playRes(fromASSHeader:) itself is unchanged.

[superuser404notfound]

Confirmed and fixed in #265. Thanks for taking it all the way to the line, that report needed no reproduction work beyond running the parser against a CRLF header.

One thing the report does not cover: a lone-CR header was broken too, and by a second mechanism. split(separator: "\n") collapses such a header into a single line, so swapping the trim to .whitespacesAndNewlines alone would still have missed it. The split now goes through Character.isNewline, which treats CRLF as one separator and covers all three conventions.

Changed the contract as well as the parse: SubtitleTextPlacement.position no longer documents a [0, 1] range. A script can anchor outside the frame on purpose, so that was a promise the engine cannot keep, and clamping or dropping such an anchor engine-side would hide the next wrong basis exactly the way this one hid. Ignoring an out-of-range anchor and falling back to alignment-only is a sound policy for a host that cannot draw off-picture, and it stays a host decision.

The new tests carry their line endings explicitly, for the reason noted: every existing PlayRes fixture was a Swift multi-line literal, so the entire class of failure was invisible to the suite. Red before the fix with the numbers from the report (y at 1.5 instead of 0.9), green after, full suite green.

Will follow up here once this ships in a release.

[superuser404notfound]

Shipped in 6.2.1 (4e281c9). No API change, no source change to adopt it.

Leaving this open for a retest on the original title rather than closing it on my own reading of the parser.

[rrgomes]

Retested on 6.2.1 against the original title. The cues render and are correctly positioned relative to the on-screen action — [SubPlacement] reports the anchor at (0.4151, 0.9000), which is \pos(298,432) against the declared 718x480, where it previously read (0.7760, 1.5000).

Thanks for catching the lone-CR case. Our proposed fix was the trim alone, which would have left that broken, and we would not have found it — the file that prompted the report is CRLF.

Noted on the contract change, and it matches what we do: the out-of-range anchor now falls back to alignment-only rather than being honored, on the grounds that this host cannot draw off-picture. We have kept that in place rather than treating it as a workaround for this bug, since it also keeps a wrong basis visible as a cue moving to a corner instead of vanishing.

[superuser404notfound]

Retest confirmed on 6.2.1, closing.

(0.4151, 0.9000) is exactly what \pos(298,432) against a declared 718x480 should produce, so the basis is right rather than merely closer.

Thanks for the report and for going back to the original title to verify it. Pinning the failure to the trim is what made it worth reading the split on the line below, which is where the lone-CR variant was hiding. Fixing what a report literally says is usually not enough, but a report that localizes the defect that precisely is what makes the neighbourhood check possible at all.

Good to hear the alignment-only fallback stays in place as a policy and not as a workaround. That is the same reasoning that took the [0, 1] promise out of the contract: a cue that walks into a corner is a visible wrong basis, a cue drawn off-picture is indistinguishable from one that never arrived, and that ambiguity is precisely what made this defect need a report to surface.