You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SourceForge bug #195 written by Brian Enigma on 2013-09-30
I have some 3rd party content that uses mid-row codes to set italics. In those cases, it appears that words get concatenated with no spaces in between. As best as I can tell from the 608 specs, mid-row codes are invisibles that count as spaces. In the most basic sense, they cause the character to move one position to the right when received (e.g. EIA/CEA-608-B sections 7.4). They occupy a position (C.13) and can be backspaced over or otherwise erased (B.3, B.12, C.5). And when they're overwritten, they cause the rest of the line to revert to normal styles (C.7): "If, when a displayable character is received, it overwrites an existing PAC or mid-row code, and there are already characters to the right of the new character, these existing characters shall assume the same attributes as the new character. This adoption can result in a whole caption row suddenly changing color, underline, italics, and/or flash attributes."
At the very least, it seems like mid-row codes should advance the cursor. I don't know how common the deletion cases are (I'd assume not very) or how difficult they would be to implement (I'd assume very), but the basic cursor-advance case should probably be handled.
Attached: an SCC file and a sample driver app to parse and decode to text/html/png.
The following appears to fix the cursor-advance behavior, but I'm not familiar enough with the codebase to say whether this is the correct or best solution:
SourceForge bug #195 written by Brian Enigma on 2013-09-30
I have some 3rd party content that uses mid-row codes to set italics. In those cases, it appears that words get concatenated with no spaces in between. As best as I can tell from the 608 specs, mid-row codes are invisibles that count as spaces. In the most basic sense, they cause the character to move one position to the right when received (e.g. EIA/CEA-608-B sections 7.4). They occupy a position (C.13) and can be backspaced over or otherwise erased (B.3, B.12, C.5). And when they're overwritten, they cause the rest of the line to revert to normal styles (C.7): "If, when a displayable character is received, it overwrites an existing PAC or mid-row code, and there are already characters to the right of the new character, these existing characters shall assume the same attributes as the new character. This adoption can result in a whole caption row suddenly changing color, underline, italics, and/or flash attributes."
At the very least, it seems like mid-row codes should advance the cursor. I don't know how common the deletion cases are (I'd assume not very) or how difficult they would be to implement (I'd assume very), but the basic cursor-advance case should probably be handled.
Attached: an SCC file and a sample driver app to parse and decode to text/html/png.
sample.scc.txt
sccextractor.cpp.txt
Comments by Brian Enigma:
The following appears to fix the cursor-advance behavior, but I'm not familiar enough with the codebase to say whether this is the correct or best solution:
The text was updated successfully, but these errors were encountered: