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 patch 21 written by Stefan Pöschel on 2019-01-01
When parsed enhanced Teletext features are flushed using enhance_flush in teletext.c, specific processing is applied to the internally used unicode representation of graphic characters (G1 and G3 charsets): Depending on whether the underlined flag is set or not, the 0x20 bit of the private unicode value is set or reset. Regarding G1 this switches between the separated and the contiguous version of a character (both are included in the supplied WST font file).
For each G3 character however, there is no such separate/contiguous distinction and hence only one character version present in the font file, as the underlined flag has no meaning here. So currently the described processing actually modifies the value of the desired chracters and leads to incorrect rendering.
Please find a patch attached that fixes the described behaviour. Note that I haven't entirely checked the internal meanings of:
es->ac.unicode
es->ac.underline
es->mac.unicode
es->mac.underline
So there may be a more elegant way to do this. It could also make sense to move unicode < 0xEF00 to a separate function.
Currently this bug affects rendering of the Level 2.5 page 100 of the German TV station PHOENIX, which uses a sophisticated combination of DRCS, G1 and G3 characters to create a less pixelated version of the station logo. In this case the G3 character 0x50 is incorrectly rendered as 0x70, as the 0x20 bit is set by the described processing.
Please see the attached screenshots for the rendering result before/after the patch is applied (using VLC).
SourceForge patch 21 written by Stefan Pöschel on 2019-01-01
When parsed enhanced Teletext features are flushed using enhance_flush in teletext.c, specific processing is applied to the internally used unicode representation of graphic characters (G1 and G3 charsets): Depending on whether the underlined flag is set or not, the 0x20 bit of the private unicode value is set or reset. Regarding G1 this switches between the separated and the contiguous version of a character (both are included in the supplied WST font file).
For each G3 character however, there is no such separate/contiguous distinction and hence only one character version present in the font file, as the underlined flag has no meaning here. So currently the described processing actually modifies the value of the desired chracters and leads to incorrect rendering.
Please find a patch attached that fixes the described behaviour. Note that I haven't entirely checked the internal meanings of:
So there may be a more elegant way to do this. It could also make sense to move unicode < 0xEF00 to a separate function.
Currently this bug affects rendering of the Level 2.5 page 100 of the German TV station PHOENIX, which uses a sophisticated combination of DRCS, G1 and G3 characters to create a less pixelated version of the station logo. In this case the G3 character 0x50 is incorrectly rendered as 0x70, as the 0x20 bit is set by the described processing.
Please see the attached screenshots for the rendering result before/after the patch is applied (using VLC).
fix_accidental_G3_char_modification.patch.txt
Rendering before patch
![zvbi_before](https://user-images.githubusercontent.com/32490787/191275925-8686f022-7e9f-4873-956d-4697dec9f110.png)
Rendering after patch
![zvbi_after](https://user-images.githubusercontent.com/32490787/191275951-6dfc99fc-b6b5-4ba4-aacb-e9803886fb5a.png)
I just wanted to ask if there is something new here meanwhile.
The text was updated successfully, but these errors were encountered: