Apply system code-page encoding to CheckBox and Popup strings on Windows#105
Apply system code-page encoding to CheckBox and Popup strings on Windows#105zzzzzz9125 wants to merge 3 commits into
Conversation
…on strings on Windows
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
This PR adds Windows-specific string encoding so parameter labels and popup options render correctly when using non-ASCII translations (by converting UTF-8 to the system code page).
Changes:
- Added helpers to encode UTF-8 strings into a system-code-page
CString(Windows) while keeping UTF-8 behavior on non-Windows. - Updated parameter label setters and popup option building to use the new encoding behavior on Windows.
- Updated macro-generated setters to use the same encoding path and adjusted short-string length validation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| after-effects/src/pf/parameters.rs | Introduces Windows code-page encoding helpers and applies them to checkbox labels and popup options. |
| after-effects/src/macros.rs | Switches macro-generated string setters to use the encoding helper and updates short-string length checking. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| paste::item! { | ||
| pub fn [<set_ $name>](&mut self, v: &str) -> &mut Self { | ||
| self.$name = CString::new(v).unwrap(); | ||
| self.$name = encode_to_system_cstring(v); |
| pub fn [<set_ $name>](&mut self, v: &str) -> &mut Self { | ||
| assert!(v.len() < 32); | ||
| let cstr = CString::new(v).unwrap(); | ||
| let cstr = encode_to_system_cstring(v); |
| use std::ffi::OsStr; | ||
| use std::os::windows::ffi::OsStrExt; | ||
| unsafe { | ||
| use windows_sys::Win32::Globalization::{WideCharToMultiByte, CP_OEMCP}; |
| let len = WideCharToMultiByte( | ||
| CP_OEMCP, 0, wstr.as_ptr(), wlen, |
| /// Convert a UTF-8 string to a `CString` encoded in the system code page | ||
| /// (e.g. CP936/GBK on Chinese Windows). On macOS this is a no-op since the | ||
| /// system uses UTF-8 natively. | ||
| fn encode_to_system_cstring(s: &str) -> CString { |
| #[cfg(target_os = "windows")] | ||
| { | ||
| let bytes = encode_to_system_bytes(s); | ||
| CString::new(bytes).unwrap_or_else(|_| CString::new("").unwrap()) |
| } | ||
| #[cfg(not(target_os = "windows"))] | ||
| { | ||
| CString::new(s).unwrap_or_else(|_| CString::new("").unwrap()) |
| } | ||
| encoded.extend_from_slice(&encode_to_system_bytes(opt)); | ||
| } | ||
| self.options = CString::new(encoded).unwrap(); |
|
@zzzzzz9125 I reviewed and vet-compiled this on both Windows targets ( Approving in principle. A few non-blocking polish items before this lands:
Note: maintainer-edits is off on this PR, so I can't push these tweaks to your branch directly. Could you either enable "Allow edits by maintainers" or apply the tweaks and lift the draft once your Premiere Pro/Ae 26.2 testing is done? Happy to merge as soon as it's marked ready. |
… ShortString truncation
|
@virtualritz Sorry for the late reply. I've made a new commit as per your request. Originally, I planned to complete the testing for 26.2 within these few days, but unfortunately, my PC got waterlogged accidentally and can't work now. So, it's actually still half-repaired. Regarding the new issue of 26.2, you can see another guy's repo: AE UTF8 Fixer. In short, AE 26.2 has changed the way of reading strings (from ANSI to UTF-8). So, the current fix of mine will actually cause problems with 26.2. I don't recommend merging it into the main branch at this time, so the status is still a draft. I will continue to complete it once my PC is repaired, maybe a few days later. Thank you for your patience! |
Hi,
I'm the maintainer of VideoFX-rs and zzzFX, downstream projects that use this crate to build After Effects / Premiere Pro plugins with localized parameter UI.
The bug
When the plugin runs on Chinese (or Japanese / Korean) Windows, parameter names on the left side of the Effect Controls panel display correctly, but checkbox labels and popup menu items on the right side show garbled text. e.g.
反转颜色becomes鍙嶈浆棰滆壊.Wrong text:
Correct text after the fix:
Root cause
ParamDef::set_name()has always applied system-code-page encoding for the inlinename[32]array — on Windows it goes throughWideCharToMultiByte(CP_OEMCP, ...), so the host receives bytes it can interpret correctly.CheckBoxDef::set_label(),PopupDef::set_options(), and theimpl Stringsetter generated bydefine_param_wrapper!do not apply this conversion. They pass raw UTF-8 bytes to the host viaCString::new(). The host interprets those bytes as system-code-page (e.g. CP936/GBK on Chinese Windows), so each multi-byte UTF-8 sequence maps to multiple wrong characters.This is a Windows-only issue. macOS uses UTF-8 natively.
The fix
Added two helpers (
encode_to_system_cstring()andencode_to_system_bytes()) that replicate the existing encoding logic fromset_name(), then applied them where they're needed.Caveats
This is still a draft because:
When I have free time later, I'll conduct tests on other versions and eventually change the status from
drafttoready for review.