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.

Sign up for GitHub

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

Jump to bottom

tsMuxeR on macOS - unable to change subtitle font color #507

Closed
priitv8 opened this issue Dec 16, 2021 · 2 comments · Fixed by #536
Closed

tsMuxeR on macOS - unable to change subtitle font color #507

priitv8 opened this issue Dec 16, 2021 · 2 comments · Fixed by #536
Assignees
@xavery
Labels
bug Something isn't working

Comments

@priitv8
Copy link

priitv8 commented Dec 16, 2021

On macOS (macOS 12.1 (21C52)) - i am unable to change the color of subtitles generated from SRT file.
Whatever I set in both font color dialog and/or color dialog, has no effect, even though the color code is changed in UI.
Generated PGS subtitles are always of some turquoise color, see the linked screenshots below.
Also, closing the color picker dialog in the font dialog crashes tsMuxeR GUI completely.
https://www.upload.ee/image/13720632/Screenshot_2021-12-16_at_16.23.59.png
https://www.upload.ee/image/13720633/Screenshot_2021-12-16_at_16.28.31.png
@jcdr428 jcdr428 added the bug Something isn't working label Dec 19, 2021
@xavery
Copy link
Contributor

xavery commented Jan 3, 2022

Generated PGS subtitles are always of some turquoise color, see the linked screenshots below.

Can confirm this one. The selected colour was a greenish 0xff2cd814 here.

Also, closing the color picker dialog in the font dialog crashes tsMuxeR GUI completely.

Not reproducible on my 12.1/21C52 VM with the latest nightly at the time of writing (2022-01-03-02-08-49).

@xavery xavery self-assigned this Jan 3, 2022
@xavery xavery mentioned this issue Jan 3, 2022
Merged
xavery added a commit that referenced this issue Jan 3, 2022
@xavery
Fix incorrect colour value interpretation in the FreeType renderer (#536
e0279f3 
)

BIG_ENDIAN might be defined by system headers, and it apparently is on both
Linux and recent macOS versions. Get rid of this completely, replace the union
by a struct and use endianness-independent constructs to obtain the values of
individual colour channels.

Also fix some minor warnings in the renderer code.

Fixes #507.
@xavery
Copy link
Contributor

xavery commented Jan 3, 2022 •
edited

Thanks. The fix for the colour issue will be included in today's (2022-01-04) nightly. Please open a new issue for the picker dialogue crash if it persists with the latest build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@xavery xavery

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix incorrect colour value interpretation in the FreeType renderer justdan96/tsMuxer
3 participants
@xavery @priitv8 @jcdr428