[Bug 46685] New: AviUtl: Can' t specify 4 digits number as image size in new project dialog.
https://bugs.winehq.org/show_bug.cgi?id=46685
Bug ID: 46685 Summary: AviUtl: Can't specify 4 digits number as image size in new project dialog. Product: Wine Version: 4.0-rc3 Hardware: x86 URL: http://spring-fragrance.mints.ne.jp/aviutl/aviutl_plus _20120619.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs@winehq.org Reporter: sagawa.aki+winebugs@gmail.com Distribution: Ubuntu
AviUtl is a Japanese AVI file editing tool. In the new project dialog, a user can't specify 4 digits number as image size on Wine. Needless to say, it's possible on native.
How to reproduce: 1. Download aviutl_plus_20120619.zip from http://spring-fragrance.mints.ne.jp/aviutl/ 2. Unzip it. 3. Launch aviutil.exe in Japanese locale, i.e. LANG=ja_JP.UTF-8 wine aviutl.exe 4. Choose [設定]-[拡張編集の設定] (Settings-ExEdit Settings), then the window titled 拡張設定 (ExEdit) will be shown. 5. Right click the time-line part on the window and choose [新規プロジェクトの作成] (Create new project). New dialog will appear.
Expected behavior: * As 画像サイズ (image size), we can specify 4 digits number, e.g. 1280.
Actual behavior: * we can specify only 3 digits number, e.g. 128, and can't specify more digits as image size.
https://bugs.winehq.org/show_bug.cgi?id=46685
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #1 from Sagawa sagawa.aki+winebugs@gmail.com --- I'm working on it. It's related to edit control margins.
https://bugs.winehq.org/show_bug.cgi?id=46685
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com --- Could this be related to bug 30746 and not margins?
https://bugs.winehq.org/show_bug.cgi?id=46685
--- Comment #3 from Sagawa sagawa.aki+winebugs@gmail.com --- No, the application uses MS UI Gothic, not Courier New. Even though I use Ume UI Gothic as an alternative, digits have the same advance widths compared with MS UI Gothic. So, it isn't glyph width issues.
https://bugs.winehq.org/show_bug.cgi?id=46685
--- Comment #4 from Nikolay Sivov bunglehead@gmail.com --- Alright, that's good if it's not font-dependent.
https://bugs.winehq.org/show_bug.cgi?id=46685
--- Comment #5 from Sagawa sagawa.aki+winebugs@gmail.com --- Created attachment 63828 --> https://bugs.winehq.org/attachment.cgi?id=63828 demonstrates WM_SETFONT margin settings with modified font.
The attachment contains Edit control test case, dlls/user32/edit.c replacement, and modified Wine's Tahoma font named TahomaMod.
TahomaMod has following glyphs: U+0041 - U+005A: ordinary `A' glyph. U+00FF: crafted `j', its left side bearing (LSB, aka A spacing in ABC) is -22. U+0100: ditto, LSB is -25. U+F8F3: ditto, LSB is -20. (CP932's \xff is converted into U+F8F3) and, MinLeftSideBearing in hhea table is -25.
Test case shows following output on native (Windows 10): edit.c:1683: TahomaMod(128): got 22, 3; expected 22, 3 edit.c:1688: TahomaMod(128): got 3, 25; expected 3, 25 edit.c:1718: TahomaMod(128): got 20, 3; expected 20, 3 edit.c:1723: TahomaMod(128): got 3, 25; expected 3, 25
Line 1683 shows WM_SETFONT's margins in Unicode Edit control. 22 seems to be opposite in sign to U+00FF's LSB. U+0100's value (25) isn't used. Line 1688 shows EM_SETMARGINS(EC_USEFONTINFO) margins in Unicode Edit control. 25 seems to be opposite in sign to MinLeftSideBearing value. Line 1718 shows WM_SETFONT's margins in ANSI variant. 20 seems to be \xff's LSB (opposite in sign). It's not U+00FF's. Line 1723 shows EM_SETMARGINS(EC_USEFONTINFO) margins in ANSI variant. They're the same as Unicode variant value.
https://bugs.winehq.org/show_bug.cgi?id=46685
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |38d0a6cd59b4bc132c5d4408251 | |ce01bda281510
--- Comment #6 from Sagawa sagawa.aki+winebugs@gmail.com --- The patch is committed as 38d0a6cd59b4bc132c5d4408251ce01bda281510.
https://bugs.winehq.org/show_bug.cgi?id=46685
Oleg Kuznetsov oleg.kuznetsov@metamint.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oleg.kuznetsov@metamint.ru
--- Comment #7 from Oleg Kuznetsov oleg.kuznetsov@metamint.ru --- (In reply to Sagawa from comment #6)
The patch is committed as 38d0a6cd59b4bc132c5d4408251ce01bda281510.
This hash gives 404 error. Shouldn't it be f3dc99c8b1091789034dea9d91ec95869b14212b instead?
https://bugs.winehq.org/show_bug.cgi?id=46685
Sagawa sagawa.aki+winebugs@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1|38d0a6cd59b4bc132c5d4408251 |f3dc99c8b1091789034dea9d91e |ce01bda281510 |c95869b14212b
--- Comment #8 from Sagawa sagawa.aki+winebugs@gmail.com --- Yes, it's f3dc99c8b1091789034dea9d91ec95869b14212b. Thanks.
https://bugs.winehq.org/show_bug.cgi?id=46685
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.7.
-
wine-bugs＠winehq.org