http://bugs.winehq.org/show_bug.cgi?id=25717
Summary: Japanese fonts sometimes shifted to the left Product: Wine Version: 1.3.11 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: gdi32 AssignedTo: wine-bugs@winehq.org ReportedBy: galtgendo@o2.pl
Created an attachment (id=32764) --> (http://bugs.winehq.org/attachment.cgi?id=32764) output with WINEDEBUG=+font
After I set up new set of font overrides (first app I encountered, that was looking up MSPGothic by its Japanese name), I ran into a strange effect.
While fonts in menus were rendered correctly (well, AFAICT), glyphs in other places were shifted a bit to the left, as shown on the screenshot.
Attaching log from WINEDEBUG=+font first.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl 2011-01-07 19:16:26 CST --- Created an attachment (id=32765) --> (http://bugs.winehq.org/attachment.cgi?id=32765) small screenshot
For searching the log: those two short words on the screenshot are はい and いいえ.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine-bugs@winehq.org Component|gdi32 |directx-d3dx9
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl 2011-01-20 14:25:51 CST --- As the problem doesn't seem to affect dialogs nor gdi32 rendered text after all, changing component to d3dx9, as it seems it only happens there.
Perhaps something like the transformation in WineEngGetGlyphOutline (gdi32) is required here ?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl 2011-01-21 11:49:43 CST --- While I still 100% confirm it's a d3d problem, further investigation suggests it's font semi-independent, cause if there's no font to display, the "missing glyph" boxes seem shifted to the left too.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl 2011-01-23 12:52:50 CST --- After more digging, it might be something on gdi32/winex11 side after all.
Looking at the font debug, the problem may lay in that that sometimes a font that was created with charset=128 every once in awhile gets reopened with charset=0 -that would mess up spacing. I'm talking about lines like: trace:font:CreateFontIndirectExW (-22 0 0 0 36 0 0 0 0) L"\ff2d\ff33 \30b4\30b7\ 30c3\30af" => 0xcb0 for "System" font. I can't quite tell, where exactly that happens - in gdi32 or in winex11.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-d3dx9 |gdi32
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl 2011-01-31 05:58:09 CST --- Last week, my search took a different turn, then stalled a bit.
Before it stalled, I learned, that there is a problem with the way wine handles freetype autohinting, as the font, that I favor looks (IPAMona set) about the same in freetype demo as the one, one of the devs prefers (Ume set), as long as autohinting is on. If it's not, the glyphs are a bit square.
Still in process of figuring out how to get around it, but I set component back to gdi32.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl 2011-01-31 13:32:20 CST --- It seems an important part of the problem is the fact, that despite all of Replacement and FontSubstitutes, once MS Shell Dlg is substituted by MS UI Gothic, IPAMonaPMincho gets chosen by WineEngCreateFontInstance, instead of IPAMonaUIGothic. Something seems to break if substitution is indirect.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl 2011-02-01 07:02:26 CST --- OK, the former part is much more simple: wine doesn't handle indirect substitution at all. That means the chain of i.e. MS Shell Dlg -> MS UI Gothic -> IPAMonaPMincho gets broken. Direct substitution is obviously out of the question here, as MS Shell Dlg is the font, that gets overwritten upon locale change.
The second part seems much more tricky...
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|gdi32 |gdiplus
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl 2011-02-01 18:37:57 CST --- Final results for today: - part one is confirmed and a pure gdi32 problem - part two is a bug in GdipDrawString: if I add 4 to args.drawbase.x, for this particular font size (16) it moves the glyph to a more or less correct position ("4" is obviously a magic number, have yet to figure out where to get the real value from)
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl 2011-02-01 21:42:06 CST --- There's also one more thing, once again gdiplus only: I can only see the text if I set OffscreenRenderingMode to "backbuffer", with "fbo" I can't see the text at all.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-02 00:28:05 CST --- (In reply to comment #8)
- part two is a bug in GdipDrawString:
if I add 4 to args.drawbase.x, for this particular font size (16) it moves the glyph to a more or less correct position ("4" is obviously a magic number, have yet to figure out where to get the real value from)
Does installing native gdiplus with winetricks help with #2?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl 2011-02-02 09:13:05 CST --- Actually, for whatever the reason, WINEDLLOVERRIDES="gdiplus=n" ends up as a crash.
Minor corrections to previous comments: - the substitution chain is actually MS Shell Dlg -> MS UI Gothic -> IPAMonaUIGothic, IPAMonaPMincho is what I get, due to wine doing just the first step - with "fbo", text does show in some of the contexts, but not in the other (don't know, in what way they differ)
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #12 from Vincent Povirk madewokherd@gmail.com 2011-02-02 10:27:36 CST --- Try 'winetricks fontfix'.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #13 from Rafał Mużyło galtgendo@o2.pl 2011-02-02 13:25:58 CST --- fontfix won't do a thing, as: 1. it's against arphic fonts 2. my arphic fonts are in a ttc, not ttf - it's 0.2.20080216.1 version
Anyway, I managed to find something, that I was able to turn into a working example, but no luck - plain GdipDrawString works correctly, it's something about context transforms.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-02 22:40:29 CST --- So, does installing native gdiplus with winetricks help with #2? If it does then it's really a gdiplus bug, if it doesn't then the problem is somewhere else.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #15 from Rafał Mużyło galtgendo@o2.pl 2011-02-03 07:52:25 CST --- As I already told, for whatever the reason, "native gdiplus"=="crash".
But there's an odd part (all of it with builtin gdiplus, obviously): in the part I'm testing, there's sort of 'general context', that seems to take the whole window and a 'popup window' (not really a window, just an area, that calculates its size as if it were a separate window);
if the native font is used, glyphs show correctly without changes in general context, but not in the popup, with substitution, both parts have moved glyphs;
however, that "4" works just as good for both, though perhaps it simply doesn't affect general context, cause I add it only in '!format || format->align == StringAlignmentNear' case;
And to repeat myself: in other non-gdiplus apps, the font is fine.
New WINEDEBUG="+font,+gdiplus" logs follow.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #16 from Rafał Mużyło galtgendo@o2.pl 2011-02-03 07:58:58 CST --- Created an attachment (id=33111) --> (http://bugs.winehq.org/attachment.cgi?id=33111) WINEDEBUG="+font,+gdiplus" - substituted
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #17 from Rafał Mużyło galtgendo@o2.pl 2011-02-03 08:00:37 CST --- Created an attachment (id=33112) --> (http://bugs.winehq.org/attachment.cgi?id=33112) WINEDEBUG="+font,+gdiplus" - native
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #18 from Rafał Mużyło galtgendo@o2.pl 2011-02-03 08:08:43 CST --- To make things more interesting, general context is affected by fbo/backbuffer switch, popup is not (in either case, it displays the text).
http://bugs.winehq.org/show_bug.cgi?id=25717
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|wine-bugs@winehq.org | Component|gdiplus |-unknown
--- Comment #19 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-03 09:33:12 CST --- (In reply to comment #15)
As I already told, for whatever the reason, "native gdiplus"=="crash".
Then you need to fix that first before claiming that it's a gdiplus bug, there is no need to guess the component.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #20 from Rafał Mużyło galtgendo@o2.pl 2011-02-03 11:27:35 CST --- That crash with native happens the moment gdiplus would draw the first string (as it's not used before) and a backtrace of: wine: Unhandled page fault on read access to 0x00000028 at address 0x5a94ee (thread 0033), starting debugger... Unhandled exception: page fault on read access to 0x00000028 in 32-bit code (0x005a94ee). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:005a94ee ESP:0032d000 EBP:00000000 EFLAGS:00210246( R- -- I Z- -P- ) EAX:00000000 EBX:00007fff ECX:00000000 EDX:00000000 ESI:009e5518 EDI:00000000 Stack dump: 0x0032d000: ffc0c0c0 009e5518 009e5518 00004081 0x0032d010: 00000000 7efb6209 00000043 000002ec 0x0032d020: b7641640 b7620db8 00000025 b76413b8 0x0032d030: b7620ca4 b7620f92 000002f0 00000002 0x0032d040: 000003d8 00000fff 000006c8 01c02000 0x0032d050: 0041b000 b7641380 000002ec 00000000 Backtrace: 0x005a94ee: movl 0x28(%edx),%eax
is not exactly helpful (at least not for me)
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #21 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-04 03:31:12 CST --- (In reply to comment #20)
That crash with native happens the moment gdiplus would draw the first string (as it's not used before) and a backtrace of: wine: Unhandled page fault on read access to 0x00000028 at address 0x5a94ee (thread 0033), starting debugger... Unhandled exception: page fault on read access to 0x00000028 in 32-bit code (0x005a94ee).
Looks like a usual gdiplus crash when it tries to parse the arphic fonts. Have a look slightly before the crash which font file is it, and move it out of the reach.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #22 from Rafał Mużyło galtgendo@o2.pl 2011-02-04 07:19:57 CST --- Well, it's a bit hard to tell which font is at fault, other than it's not arphic set. The crash seems to happen on "System" font and the only interesting part about it, that I can find in the logs are those L"" named fonts in Tahoma creation.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #23 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-04 08:27:11 CST --- Please attach a +relay,+seh,+tid log (compressed with bzip2 -9).
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #24 from Rafał Mużyło galtgendo@o2.pl 2011-02-04 09:18:05 CST --- Created an attachment (id=33131) --> (http://bugs.winehq.org/attachment.cgi?id=33131) log of the crash
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #25 from Rafał Mużyło galtgendo@o2.pl 2011-02-04 09:20:22 CST --- Created an attachment (id=33132) --> (http://bugs.winehq.org/attachment.cgi?id=33132) analogical log with builtin gdiplus
Once past the crash point, I simply quit.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33131|text/plain |application/bzip2 mime type| |
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #26 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-07 06:50:12 CST --- (In reply to comment #24)
Created an attachment (id=33131)
--> (http://bugs.winehq.org/attachment.cgi?id=33131) [details]
log of the crash
The log looks strange, there is no a single kernel32 or user32 call there, did you filter it somehow?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #27 from Rafał Mużyło galtgendo@o2.pl 2011-02-07 10:26:17 CST --- Created an attachment (id=33182) --> (http://bugs.winehq.org/attachment.cgi?id=33182) a bit more verbose log - crash only
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #28 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-07 22:28:14 CST --- (In reply to comment #27)
Created an attachment (id=33182)
--> (http://bugs.winehq.org/attachment.cgi?id=33182) [details]
a bit more verbose log - crash only
There is no crash in this log, it looks like log the was truncated.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33182|0 |1 is obsolete| |
--- Comment #29 from Rafał Mużyło galtgendo@o2.pl 2011-02-08 07:52:13 CST --- Created an attachment (id=33193) --> (http://bugs.winehq.org/attachment.cgi?id=33193) a non truncated log
Oops, I've got a wacky partition layout and the log went into one that was almost full - it went to full then.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #30 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-08 09:48:11 CST --- (In reply to comment #29)
Created an attachment (id=33193)
--> (http://bugs.winehq.org/attachment.cgi?id=33193) [details]
a non truncated log
Oops, I've got a wacky partition layout and the log went into one that was almost full - it went to full then.
What application did you run to create this log? The log still looks incomplete to me.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #33193|0 |1 is obsolete| |
--- Comment #31 from Rafał Mużyło galtgendo@o2.pl 2011-02-08 10:33:51 CST --- Created an attachment (id=33194) --> (http://bugs.winehq.org/attachment.cgi?id=33194) a more standard log
I had settings in Debug, that were far from default ones, this log is much closer.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #32 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-09 00:34:30 CST --- (In reply to comment #31)
I had settings in Debug, that were far from default ones, this log is much closer.
Once again, what application did you run to create this log? Something is wrong with your Wine prefix, do you have a z: drive mapping in it? Please remove your ~/.wine and start from scratch without changing anything in it.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #33 from Rafał Mużyło galtgendo@o2.pl 2011-02-09 07:54:17 CST --- Be a bit more clear next time. I don't have a z: drive, cause I removed it.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #34 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-09 10:15:00 CST --- (In reply to comment #33)
Be a bit more clear next time. I don't have a z: drive, cause I removed it.
Please don't do that, removing z: drive mapping breaks things like access to system fonts outside of ~/.wine for Windows applications or native components like gdiplus.dll.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #35 from Rafał Mużyło galtgendo@o2.pl 2011-02-09 11:01:52 CST --- (In reply to comment #34)
(In reply to comment #33)
Be a bit more clear next time. I don't have a z: drive, cause I removed it.
Please don't do that, removing z: drive mapping breaks things like access to system fonts outside of ~/.wine for Windows applications or native components like gdiplus.dll.
Part one of that statement seems incorrect: all of my fonts come from /usr/share/fonts/ subdirs and work just fine.
Please explain the other part.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #36 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-09 11:44:16 CST --- (In reply to comment #35)
I don't have a z: drive, cause I removed it.
Please don't do that, removing z: drive mapping breaks things like access to system fonts outside of ~/.wine for Windows applications or native components like gdiplus.dll.
Part one of that statement seems incorrect: all of my fonts come from /usr/share/fonts/ subdirs and work just fine.
They work fine only if used by Wine components.
Please explain the other part.
Windows applications and components need a DOS drive letter to correctly access files outside of ~/.wine. Z: drive mapping exists for a reason, please don't break existing Wine setup when reporting bugs.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #37 from Rafał Mużyło galtgendo@o2.pl 2011-02-09 12:29:49 CST --- IIRC, disagreement with z: existence is not limited to me only.
Also, this bug was not "native gdiplus crashes the app", but "builtin gdiplus mispositions the glyps". It would be nice if the native would work too, but the bug is still in the builtin.
So, any ideas about original problem ?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #38 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-09 12:47:10 CST --- (In reply to comment #37)
Also, this bug was not "native gdiplus crashes the app", but "builtin gdiplus mispositions the glyps". It would be nice if the native would work too, but the bug is still in the builtin.
That's just a pure guess. What makes you reluctant to create a not broken Wine prefix and test it?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #39 from Rafał Mużyło galtgendo@o2.pl 2011-02-09 13:58:41 CST --- Probably a strong conviction, that it won't help with the original problem...
that was proven correct - only thing that I learned here was that native gdiplus needs a z: drive and that playing with HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink is required for Tahoma to be spaced correctly in ja_JP.utf8 locale, otherwise font is spaced using Western script - I'd say it's an ugly bug, FontSubstitutes should be enough.
As I expected, native gdiplus handles the font correctly.
But in a meanwhile I came up with a better hack than one from comment 8: instead of adding random numbers, I substitute 'corners[0].x' with 'corners[0].x >= 0 ? corners[0].x : 0' in the same place.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #40 from Rafał Mużyło galtgendo@o2.pl 2011-02-09 14:04:16 CST --- BTW, that ugly bug from the previous comment is the real reason for 'part one' of comment 8 - I probably simply followed one of Aric's advices and didn't notice it worked, cause it didn't while I removed tahoma.ttf from /usr/share/wine/fonts for a different test (apps still worked, after I added a Replacement key for Tahoma).
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #41 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-09 22:55:14 CST --- So, just to clarify things: does native gdiplus alone without any other changes in the Wine prefix help?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #42 from Rafał Mużyło galtgendo@o2.pl 2011-02-10 05:54:58 CST --- Depends on your definition of "helps". Are the glyphs shifted to the left ? No. Are the glyphs spaced incorrectly without FontLink ? Yes, but that's not a gdiplus problem (probably pure gdi32). Is the backbuffer vs fbo issue still present ? Yes, but again - unlikely a gdiplus problem (winex11 one ?).
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #43 from Rafał Mużyło galtgendo@o2.pl 2011-02-10 06:02:03 CST --- To reclarify: shifting doesn't seem to affect menus, but spacing does, while parts affected by shifting seem to be spaced correctly.
http://bugs.winehq.org/show_bug.cgi?id=25717
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gdiplus
--- Comment #44 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-10 06:04:24 CST --- (In reply to comment #42)
Depends on your definition of "helps". Are the glyphs shifted to the left ? No. Are the glyphs spaced incorrectly without FontLink ? Yes, but that's not a gdiplus problem (probably pure gdi32). Is the backbuffer vs fbo issue still present ? Yes, but again - unlikely a gdiplus problem (winex11 one ?).
Please leave this bug for the glyph shifting (as the summary implies). If native gdiplus helps then this is a gdiplus bug.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #45 from Rafał Mużyło galtgendo@o2.pl 2011-02-10 07:22:15 CST --- Well, the FontLink problem does look a bit like bug 16325, but there was no activity in that bug for over a year and I still think, that while substituting by family name (as in FontSubstitutes) is a bit annoying, but to a point acceptable, substituting by file name isn't. And really, why FontSubstitutes doesn't have the same effect on spacing FontLink does ?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #46 from Rafał Mużyło galtgendo@o2.pl 2011-02-10 10:07:25 CST --- Created an attachment (id=33232) --> (http://bugs.winehq.org/attachment.cgi?id=33232) screenshot with hack
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #47 from Dmitry Timoshkov dmitry@codeweavers.com 2011-02-10 11:25:15 CST --- (In reply to comment #46)
Created an attachment (id=33232)
--> (http://bugs.winehq.org/attachment.cgi?id=33232) [details]
screenshot with hack
Please attach screenshot with native gdiplus instead (and no hacks), so we could compare the real results and not what you believe is correct.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #48 from Rafał Mużyło galtgendo@o2.pl 2011-02-10 12:15:51 CST --- Created an attachment (id=33233) --> (http://bugs.winehq.org/attachment.cgi?id=33233) same with native gdiplus
:roll: pure nitpicking As you may see, hack and native are about the same, glyph thickness aside.
Any better ideas than reviving that old bug for FontLink problem ?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #49 from Rafał Mużyło galtgendo@o2.pl 2011-02-16 16:19:10 CST --- Created an attachment (id=33317) --> (http://bugs.winehq.org/attachment.cgi?id=33317) patch for FontSubstitute problem
Seems that my reply to Dmitry's question got stuck in moderation, so attaching the patch here, so it doesn't get lost.
What I'm doing in this patch, wine is already doing, if substitutes are added in b->c, a->b order. The problem lies in that substitutions can't really be serialized, reverse checks are needed.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #50 from Rafał Mużyło galtgendo@o2.pl 2011-03-04 15:18:04 CST --- Just to show this bug ain't forgotten - update for wine 1.3.15: - it seems the changes that Dmitry made in a different place were as effective as mine; fonts *seem* to be correctly substituted now - as for the two other problems: no change
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #51 from Vincent Povirk madewokherd@gmail.com 2011-03-17 15:57:41 CDT --- Possibly relevant: http://support.microsoft.com/kb/307208, see "How to Display Adjacent Text" section near the end.
We don't do any of the crap listed there, and reading about it fills me with hate. But I'll have to think about how we can alter the glyph positions to match native, along with supporting complex scripts and DrawDriverString/MeasureDriverString.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #52 from Vincent Povirk madewokherd@gmail.com 2011-03-17 16:02:45 CDT --- Please note that I've done no investigation to determine whether this is related to the padding at all. It could be something completely different. Maybe this program does what's required to turn it off.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #53 from Rafał Mużyło galtgendo@o2.pl 2011-03-18 17:29:48 CDT --- Well, for the moment, it's hard to tell whether it's the right direction or not. Regardless, thanks for the effort.
Anyway, 1.3.16 offered no changes here, though it improved a different case quite a bit (furigana (at least it seems that's it) isn't displayed there correctly, but at least most of the text is displayed now - still it floods with 'fixme:d3d_surface:IWineD3DBaseSurfaceImpl_Blt Filter WINED3DTEXF_LINEAR not supported in software blit.' but that's a matter for a different bug, should I file one).
Well, uniscribe is a fairly recent addition, before it internationalization on the fonts side had to be lacking.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #54 from Rafał Mużyło galtgendo@o2.pl 2011-04-15 15:29:43 CDT --- So, today 1.3.18 has brought a change...in fbo handling. Now, while all the warnings are still there and additionally upon closing err:d3d:context_set_current Failed to make GL context 0x136f70 current on device context 0x60c, last error 0x6. err:d3d:context_acquire Failed to activate the new context. is printed, OffscreenRenderingMode=fbo does not longer mean "no text". It seems to be the same as 'backbuffer' now.
Unfortunately, no change in the gdiplus problem.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #55 from Rafał Mużyło galtgendo@o2.pl 2011-05-27 17:25:48 CDT --- Status update for 1.3.21: as promising as "gdiplus: Change the sign we use for origin.x in DrawDriverString." sounded, no change in regard of shifted glyphs happened.
OK, so that *was* a completely different function, but it still sounded alike to my hack-fix.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #56 from Rafał Mużyło galtgendo@o2.pl 2011-06-22 19:17:35 CDT --- Created an attachment (id=35242) --> (http://bugs.winehq.org/attachment.cgi?id=35242) screenshot with gdiplus from wine 1.3.22
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #57 from Rafał Mużyło galtgendo@o2.pl 2011-06-22 19:20:15 CDT --- Created an attachment (id=35243) --> (http://bugs.winehq.org/attachment.cgi?id=35243) same portion with 'corners[0].x >= 0 ? corners[0].x : 0;' hack
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #58 from Rafał Mużyło galtgendo@o2.pl 2011-06-22 19:46:15 CDT --- Created an attachment (id=35248) --> (http://bugs.winehq.org/attachment.cgi?id=35248) same portion with '- corners[0].x' hack
Inspired by the above mentioned commit, I checked a different hack.
These screenshots are the results with IPAMona font. They were made in what I called 'general context'.
Now, the funny part is that I've made a few tests with native font too and results were a bit silly: - pure 1.3.22 was OK in 'general context', shifted to the left in that small dialog from previous screenshots - with '- corners[0].x', 'general context' was shifted to the *right*, but the dialog looked correct - with 'corners[0].x >= 0 ? corners[0].x : 0;' hack, both looked OK
So, it seems it's not quite font related after all.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #59 from Rafał Mużyło galtgendo@o2.pl 2011-07-08 16:01:26 CDT --- Well, wine 1.3.24 is here and it's one step forward, one step back. As I mentioned on IRC, "gdiplus: Use DrawDriverString to draw the text in DrawString." commit fixed font positioning, but backbuffer vs fbo makes a difference again.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #60 from Rafał Mużyło galtgendo@o2.pl 2011-07-09 02:53:03 CDT --- ...and the winner is (after a bisect)... cd96c59d9168fbda25536d328edb24c0bc0e5139 wined3d: Track framebuffer changes.
This might be tied to the warnings wine spits repeatedly regardless of this commit: err:d3d:loadVertexData >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glBindBufferARB @ state.c / 4319 err:d3d:loadVertexData >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glBindBufferARB @ state.c / 4319 err:d3d_draw:drawStridedSlow >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glEnd and previous calls @ drawprim.c / 309
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #61 from Henri Verbeet hverbeet@gmail.com 2011-07-09 11:42:49 CDT --- Please create a new bug for that.
http://bugs.winehq.org/show_bug.cgi?id=25717
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #62 from Dmitry Timoshkov dmitry@baikal.ru 2011-07-09 12:23:58 CDT --- (In reply to comment #59)
Well, wine 1.3.24 is here and it's one step forward, one step back. As I mentioned on IRC, "gdiplus: Use DrawDriverString to draw the text in DrawString." commit fixed font positioning, but backbuffer vs fbo makes a difference again.
This bug is about gdiplus, it's fixed then.
http://bugs.winehq.org/show_bug.cgi?id=25717
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #63 from Alexandre Julliard julliard@winehq.org 2011-07-22 12:45:21 CDT --- Closing bugs fixed in 1.3.25.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|FIXED |
--- Comment #64 from Rafał Mużyło galtgendo@o2.pl 2011-07-22 16:41:39 CDT --- Actually, while it was working in 1.3.24, in 1.3.25 it's broken again.
Here's the kicker: the commit that broke it was "gdiplus: Fix use of uninitialized memory.".
The comment in the mail was "I have no idea how this ever worked even a little."...well, I'm not laughing.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #65 from Rafał Mużyło galtgendo@o2.pl 2011-07-22 16:55:32 CDT --- Apparently, "uninitialized" here meant "zero-initialized", as if I set 'args.x = 0;' (which was what most likely my hack-fix did), glyphs are are displayed correctly.
http://bugs.winehq.org/show_bug.cgi?id=25717
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #66 from Dmitry Timoshkov dmitry@baikal.ru 2011-07-23 22:47:33 CDT --- Please open a separate bug report with appropriate regression test results, this one is fixed.
http://bugs.winehq.org/show_bug.cgi?id=25717
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #67 from Dmitry Timoshkov dmitry@baikal.ru 2011-07-23 22:47:50 CDT --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=25717
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|FIXED |
--- Comment #68 from Vincent Povirk madewokherd@gmail.com 2011-07-27 10:57:00 CDT --- It's appropriate to reopen this bug. The original "fix" only worked better by coincidence.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #69 from Rafał Mużyło galtgendo@o2.pl 2012-06-30 02:31:36 CDT --- ...so, have left it alone awhile ago.
With wine 1.5.7, the bug is still present, though I'm not quite sure where would be the proper place for my hack atm., as due to all the changes, the old place is gone.
The notable change is that the presence of Windows fonts no longer makes a difference in glyph position.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #70 from Rafał Mużyło galtgendo@o2.pl 2012-06-30 03:24:00 CDT --- Created attachment 40796 --> http://bugs.winehq.org/attachment.cgi?id=40796 new hack for glyph position
...OK, I came up with a new hack, but... Well, if I look at the screens, it works, if I look at the code, there's no reason it should.
Unless gdiplus graphics context somehow already caries the shift (kinda like when in gdk_draw_layout you needed to pass font ascent explicitly (it drew on baseline), while in pango_cairo_show_layout works with upper corner of layout).
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #71 from Rafał Mużyło galtgendo@o2.pl 2012-06-30 05:33:28 CDT --- ...well, the hack works in that app, but breaks the others. Still, figuring out where the additional offset comes from should help with this bug.
...the catch being that it seems GdipDrawString already receives those incorrect offsets at the start, so it's hard to tel where to go back.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40796|0 |1 is obsolete| |
--- Comment #72 from Rafał Mużyło galtgendo@o2.pl 2012-06-30 12:43:35 CDT --- Created attachment 40810 --> http://bugs.winehq.org/attachment.cgi?id=40810 a hack that breaks less
Bah... I basically went and recreated my old hack (though it's likely a bit more wrong this time - I think I didn't get context scaling right). But this time I think I have an explanation: http://msdn.microsoft.com/en-us/library/windows/desktop/ms534181(v=vs.85).as... the part of interest might be "StringFormatFlagsNoFitBlackBox" description; if I'm reading it right, if that flag is unset (like by default), the string needs to be measured and if it slips out of the bounding box, it should at very least be pushed back (with regard to alignment type) if possible.
As the rectangles passed to GdipDrawString are (after selecting the relevant font (16pt, AFAICT)) (-2.67, 0, 0, 0) they're treated as unclipped, so to combine them properly with clip region, they need to be shifted.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40810|0 |1 is obsolete| |
--- Comment #73 from Rafał Mużyło galtgendo@o2.pl 2012-06-30 13:46:02 CDT --- Created attachment 40811 --> http://bugs.winehq.org/attachment.cgi?id=40811 a hack that breaks less (corrected a typo)
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #74 from Rafał Mużyło galtgendo@o2.pl 2012-07-04 15:08:11 CDT --- I've just looked at Dmitry's recent patches (#87920, #87921, #87922).
I won't say they fix the problem, so it doesn't end up with another block like comments 61-68, but the outlook is good.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #75 from Rafał Mużyło galtgendo@o2.pl 2012-07-05 11:53:54 CDT --- Bah, disregard previous comment - once again I was seeing things.
...
Actually, I simply forgot to revert my hack before testing.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #76 from Rafał Mużyło galtgendo@o2.pl 2012-08-31 16:38:34 CDT --- I would like to give an update in regard of 1.5.11, but a few wine releases ago a variation of bug 21926 (or perhaps bug 22459) has resurfaced and the only thing I see now is a black window followed by a crash shortly after fixme:d3d_surface:surface_allocate_surface No GL internal format for format WINED3DFMT_D16_UNORM.
So, r200 is an outdated card model, but is that a reason to completely break it ?
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #77 from Rafał Mużyło galtgendo@o2.pl 2012-08-31 16:42:03 CDT --- ...correction, I meant today's release - 1.5.12.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #78 from Rafał Mużyło galtgendo@o2.pl 2012-10-15 12:03:11 CDT --- So again, a bit more with 1.1.15. On a hunch, I've tried backbuffer again. As opposed to fbo (which still produced just a black window now), it displays nearly everything it should...except for the text.
The very first commit that breaks things is commit 889be9d447329994f009726d4e79a2fb3772e456. It's not the one that makes text invisible, but it scales the glyphs into much too large size. I suspect, that one of the later commits simply uses that wrong size to move the glyphs outside their drawing boxes, making them invisible.
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #79 from Rafał Mużyło galtgendo@o2.pl 2012-10-15 13:42:25 CDT --- ...however, the commit that makes glyphs invisible is 1418cd796cf00636db3e75df25645e235a1a845d (gdiplus: GdipMeasureCharacterRanges shouldn't treat empty layout rectangle as infinite bounds.)
But it seems the final commit that broke things was bfa35f37a7687cdae338ad9837fc595afb2df2b6 (gdiplus: Add support for StringFormatFlagsNoClip.)
The funny part is that before that commit, with the two previously mentioned reverted, glyphs were positioned correctly - the shift was gone.
Two notes: - odd, that this game seems to be a counter example to most of the tests wine has (or has recently acquired) - one of those commits is about infinite bounds, the other about a NoClip flag...; coincidence ?
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #40811|0 |1 is obsolete| |
--- Comment #80 from Rafał Mużyło galtgendo@o2.pl 2012-10-15 14:07:56 CDT --- Created attachment 42141 --> http://bugs.winehq.org/attachment.cgi?id=42141 hack (once again) updated
Rechecking what I've just posted, it seems following revert/hack is sufficient. Obviously, it will break newly "added" StringFormatFlagsNoClip.
Could this be a bad convert ?
Black window is most likely independent and most likely r200 related.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #42141|0 |1 is obsolete| |
--- Comment #81 from Rafał Mużyło galtgendo@o2.pl 2012-10-15 16:13:53 CDT --- Created attachment 42146 --> http://bugs.winehq.org/attachment.cgi?id=42146 hack (once again) polished
I've tried to add elements of StringFormatFlagsNoClip support to the hack - except for the part I'm missing, this should be very near the state of wine 1.5.15.
It seems I'm only moving a block of code from one place to another, but it still makes a difference.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #42146|0 |1 is obsolete| |
--- Comment #82 from Rafał Mużyło galtgendo@o2.pl 2012-10-26 21:19:44 CDT --- Created attachment 42270 --> http://bugs.winehq.org/attachment.cgi?id=42270 hack at clipping
As 1.5.15 brought no change, I've decided to do to a bit of wacky testing and finally the new hack became something quite simple, even if a bit surprising.
This might even be a valid patch.
http://bugs.winehq.org/show_bug.cgi?id=25717
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #83 from Rafał Mużyło galtgendo@o2.pl 2012-12-10 10:44:17 CST --- The logic fix (based on the last hack) went into 1.5.17. Combined with the margin patches that allowed for it, it makes the display correct.
It still works in 1.5.19.
I do hope it's really and permanently fixed this time.
fbo vs backbufer is being handled in a different bug (mostly by providing a workaround, but with an r200 it's unfortunately good enough).
http://bugs.winehq.org/show_bug.cgi?id=25717
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |48a2b48e16d751e0ddb72cb4e67 | |29b943e018001
http://bugs.winehq.org/show_bug.cgi?id=25717
--- Comment #84 from Rafał Mużyło galtgendo@o2.pl 2012-12-10 18:12:04 CST --- Actually, the bug was most likely fixed by 89ab0e4b12a09c119748f16139eacbbe4560e738, but my logic patch was needed to fix the things that commit bfa35f37a7687cdae338ad9837fc595afb2df2b6 broke.
http://bugs.winehq.org/show_bug.cgi?id=25717
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1|48a2b48e16d751e0ddb72cb4e67 |89ab0e4b12a09c119748f16139e |29b943e018001 |acbbe4560e738
http://bugs.winehq.org/show_bug.cgi?id=25717
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #85 from Alexandre Julliard julliard@winehq.org 2012-12-21 13:29:00 CST --- Closing bugs fixed in 1.5.20.
-
wine-bugs＠winehq.org