Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix accidental G3 char modification #20

Closed
ileanadumitrescu95 opened this issue Sep 20, 2022 · 0 comments · Fixed by #55
Closed

Fix accidental G3 char modification #20

ileanadumitrescu95 opened this issue Sep 20, 2022 · 0 comments · Fixed by #55

Comments

@ileanadumitrescu95
Copy link
Contributor

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).

fix_accidental_G3_char_modification.patch.txt

Rendering before patch
zvbi_before

Rendering after patch
zvbi_after

I just wanted to ask if there is something new here meanwhile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant