Created attachment 41217 [details]
Output with wine-1.5.10 and dwrite.dll enabled

I can confirm that the text is invisible for me, as well, unless I disable dwrite.dll

Yeah, I'm aware of that and it's expected after I added some stubs yesterday.

In latest 1.5.9 version from git (wine-1.5.9-294-g0316a1b) Steam works fine without dwrite.dll disabling.

*** Bug 31380 has been marked as a duplicate of this bug. ***

wine Steam.exe -no-dwrite

made steam work again, disabling dwrite.dll did not help for me.
Arch Linux x86_64 3.5.0-2-ARCH wine 1.5.10

As others have stated, launching with 
wine Steam.exe -no-dwrite
solves the problem.

Launched with wine Steam.exe
http://i.imgur.com/n4WFph.png

Launched with wine Steam.exe -no-dwrite 
http://i.imgur.com/O1Ya4h.png

*** Bug 31395 has been marked as a duplicate of this bug. ***

The bug affects me as well. Disabling dwrite.dll solves the problem.

Yup, I can also confirm that. It was fine in 1.5.9. Using -no-dwrite is a workaround for this.

Confirmed by multiple users

I can also confirm it. Using -no-dwrite works for me too.

*** Bug 31419 has been marked as a duplicate of this bug. ***

*** Bug 31425 has been marked as a duplicate of this bug. ***

Described behavior confirmed here too. Arch Linux, wine-1.5.10.

This is a regression caused by including a builtin dwrite.dll in commit 3a724d58eba31666af3886d759371507f8cddd50

Until more of dwrite is implemented, I'm not sure there's much to do except the known workarounds

Sorry, I wasn't running the wine binary I thought I was. Reverting 0ccdda1262c84c3bab7fb1136ac97c92faf30830 actually fixes it.

Please attach plain terminal output running current git wine (no flags needed). Output from displaying login window is enough and will reduce log size.

Created attachment 41362 [details]
Current log

This is with wine-1.5.10-69-g6bfc07e

Confirmed in Arch Linux with Wine 1.5.10

Confirmed in Ubuntu 12.04 with Wine 1.5.11
workaround:
wine Steam.exe -no-dwrite

People,

please *STOP* confirming this bug, wine developers are perfectly aware of it.

Thank you.

I also am having serious issues. More than just no text (the "fix" does not work anymore for me).

I just updated whole computer (KDE/ArchLinux) and had to use the DLL fix to be able to update Steam. Once it was updated, it closed itself/crashed and upon reopening, no text. DLL fix no longer worked, AND SkyrimLauncher.exe crashes every time.

d'oh....

Note that when steam restarts itself (after an update), it doesn't apply the -no-dwrite flag, so a second manual restart with this flag is required.  I'm not seeing the problem reported by AG, and am also on Arch.

By the way, the severity of this problem is not "trivial", it is at best "minor":

    minor	For minor loss of functionality, or other problem where an easy workaround is present

    trivial	For a UI glitch that doesn't affect running of a program

Steam is unusable without the workaround, so "trivial" is inapplicable.

(In reply to comment #24)
> Note that when steam restarts itself (after an update), it doesn't apply the
> -no-dwrite flag, so a second manual restart with this flag is required.  I'm
> not seeing the problem reported by AG, and am also on Arch.
> 
> By the way, the severity of this problem is not "trivial", it is at best
> "minor":
> 
>     minor    For minor loss of functionality, or other problem where an easy
> workaround is present
> 
>     trivial    For a UI glitch that doesn't affect running of a program
> 
> Steam is unusable without the workaround, so "trivial" is inapplicable.

That's why do not use this flag. Just disable dwrite.dll in winecfg. This is workaround.

Does broken fonts in the overlay count? I've disabled dwrite.dll and using -no-dwrite flag but I still have messy overlay: http://i.imgur.com/ddX6c.png some text is missing and some graphical glitches are there, too (I didn't edited this screenshot at all to hide nicknames and such, it really looks like this). Wine 1.5.12. Steam works totally ok but the overlay doesn't and it looks bound since menus in the overlay lack text, too.

Hmm, after restarting TF2 everything is in place though overlay closes on moving mouse (that's another known bug, I know).

(In reply to comment #27)
> Hmm, after restarting TF2 everything is in place though overlay closes on
> moving mouse (that's another known bug, I know).

(In reply to comment #27)
> Hmm, after restarting TF2 everything is in place though overlay closes on
> moving mouse (that's another known bug, I know).

This is bug #24682 and it still unconfirmed.

Steam Big Picture doesn't work with disabled dwrite.DLL.

(In reply to comment #29)
> Steam Big Picture doesn't work with disabled dwrite.DLL.

Remove it then.

Wine 1.5.12, Arch x86. No text in Steam unless "wine Steam.exe -no-dwrite" is used.

(In reply to comment #30)
> (In reply to comment #29)
> > Steam Big Picture doesn't work with disabled dwrite.DLL.
> 
> Remove it then.

You might actually work on fixing this bug instead. I myself have another commit to try to revert when compiling wine.

(In reply to comment #30)
> (In reply to comment #29)
> > Steam Big Picture doesn't work with disabled dwrite.DLL.
> 
> Remove it then.

Apologies, that may have been unwise. I just hope there's some progress soon. I don't understand why this bug exists in the first place.

*** Bug 31715 has been marked as a duplicate of this bug. ***

Confirmed on Ubuntu 12.04

where can i find the place to disable dwrite help pls !

(In reply to comment #36)
> where can i find the place to disable dwrite help pls !

Run "wine Steam.exe -no-dwrite" from command line.

sorr y, but where is the command line?

There are several workarounds mentioned in the comments, please read them.

IMO, easiest is to run winecfg, go to libraries, and mark dwrite as "native" or "disabled"
Using steam.exe -disable-dwrite is also possible, but doesn't work when steam relaunches automatically or through the URL shortcuts.

(In reply to comment #38)
> sorr y, but where is the command line?

Run Konsole if you use KDE or gnome-terminal if you use Gnome, there is also lxterminal under LXDE. Navigate to directory containing Steam.exe and run command mentioned above.

ok guys, iv done everything you told me. winecfg>libraries> -dwrite disable

it still doesnt work for me, anyone know why?

It is not a user forum.

1.4.15 and still affected

Obviously Steam is a very popular application among Wine gamers.

This bug has been open 3 months now and spanned 6 releases, so Wine developers are not in a haste to apply a proper fix for the problem. Until that happens, why not just revert the dwrite patch that caused the regression in the first place?

(In reply to comment #44)
> Obviously Steam is a very popular application among Wine gamers.
> 
> This bug has been open 3 months now and spanned 6 releases, so Wine developers
> are not in a haste to apply a proper fix for the problem. Until that happens,
> why not just revert the dwrite patch that caused the regression in the first
> place?

Nikolay has been working in dwrite as you can see:
http://source.winehq.org/git/wine.git/history/HEAD:/dlls/dwrite

(In reply to comment #44)

Because the issue comes from dwrite.dll existing in the first place but not being good enough. There's still work being done on dwrite, so there is no reverting it at this point.

Apparently there's a way to disable it from UI, there's a checkbox in Interface tab of Settings.

How do you input -no-dwrite.dll?
 Where do i type that in?!

(In reply to comment #48)
> How do you input -no-dwrite.dll?
>  Where do i type that in?!

wine ./steam.exe -no-dwrite

OR

env WINEPREFIX=/your/steam/prefix winecfg
goto libraries tab and set dwrite.dll to disabled.

Confirming the issue on 1.5.17.

Also confirming the workaround in Fedora 17 x64.

i stll dont get it :XD someone help me please. maybe pictures or something please.

Created attachment 42847 [details]
My settings

these are the settings im on

or could anyone just upload a working version of their wineskin with steam and dwrite and all settings ready to go onto rapidshare or etc.

(In reply to comment #51)
> i stll dont get it :XD someone help me please. maybe pictures or something
> please.

Let me try to explain step by step:
0. You were told before: this is not the place for user support.
1. Find a mailing list or user forum. Start here: http://www.winehq.org/forums
2. Post your question there.
3. Get useful answers — Profit.

I don't want to be rude, but you aren't showing much respect by repeatedly posting here.

And to other prospective posters: the developers don't need "me too" updates, they have confirmed the issue. They explained that they need to finish a new feature before it will work. If this bothers you use the workaround, switch to wine stable, or wait in silence, but stop updating the bug.

Still happens on latest version

This problem still affects Wine 1.6rc4

This should be a blocker for the 1.6 release (it's a regression from 1.5.x).

(In reply to comment #56)
> This problem still affects Wine 1.6rc4
> 
> This should be a blocker for the 1.6 release (it's a regression from 1.5.x).

It's a new feature, so it's not considered a regression.

There's an easy workaround, disable dwrite.dll.

Steam ships with an option to disable dwrite from their options now.

(In reply to comment #57)
> It's a new feature, so it's not considered a regression.

It's a regression in a program that used to work before (a popular one at that).

Before the response was "this is an unstable Wine version, we will fix it later, downgrade to stable"

Doesn't this indicate a problem in Wine's release management, that regressions are introduced, fixes delayed and then never materialize. Finally a new *stable* version gets released that breaks a popular application, even though the bug was known for a year?

(See comment #54)
> the developers don't need "me too" updates,
> they have confirmed the issue. They explained that they need to finish a new
> feature before it will work. If this bothers you use the workaround, switch to
> wine stable, or wait in silence, but stop updating the bug.

(In reply to comment #57)
> It's a new feature, so it's not considered a regression.

Wow.  If you tried that line on the linux kernel, Linus would eat you alive.

What's the reason behind enabling this feature by default if it breaks one of the most popular apps? Why not make a temporary registry flag to ENABLE it (like DWORD EnableBuiltinDwrite) and DISABLE it by default so no one needs to get frustrated and google for the solution? I really don't see any improvement with this feature at its current state. I see a regression though. So until it can be really used without breaking anything it's wise to make it optional. I'd also like to propose disabling GLSL by default since the only thing it makes is stuttering and lowering FPS in games. Same reason.

(In reply to comment #60)
Issue trackers are for the developers' convenience. In this project, developers find it convenient to identify regressions when they are actually caused by issues in the code, rather than new features suddenly being used by the application. It's 100% irrelevant how Linus or anyone else might react in a different project.

As for disabling it by default, that's not going to happen. This bug only affects steam, and not only does steam have a flag to disable dwrite, dwrite.dll can also be disabled from winecfg.
If you install steam from winetricks, this is taken care of automatically. This is as convenient as it gets. More noise in this bug isn't going to make the devs change their mind.

The best things you can do to help it:
 - Buy crossover. The money goes to Wine devs; you might also be able to set up a bounty on this bug from there. Also I think dwrite might be disabled on Steam in crossover.
 - Actually work on this bug and submit hard code (I'm sure even tests would help).

For some reason though, I doubt you'll do either of those things because *disabling dwrite is extremely easy already* (and a hell of a lot easier than writing code or shelling out money). There's absolutely nothing wrong with that, but afterwards you can't come in here all entitled and expect devs to follow your will rather than how things arrange *them*.

Regardless, this will not make the 1.6 cut. Wine is in the release candidate stages and that's simply too late for major features like these.

(In reply to comment #61)
> What's the reason behind enabling this feature by default 

So users will test it by default. That is the purpose of the development branch: testing. 

> So until it
> can be really used without breaking anything it's wise to make it optional.

It is optional. Extremely easy ways to turn it off have already been pointed out.

(In reply to comment #63)
> > What's the reason behind enabling this feature by default 
> 
> So users will test it by default. That is the purpose of the development
> branch: testing. 

The what? We're not talking about "testing branches" here, we're talking about the 1.6.0 release, which is a stable release.

And what's the point of making users "test" something that's known to be broken for a year?

(In reply to comment #64)

> The what? We're not talking about "testing branches" here, we're talking about
> the 1.6.0 release, which is a stable release.
> 

Well, I think that gets into the question of what purpose, if any, the "stable" branch serves. From what I've observed, it seems to serve two purposes: a security blanket for users who need one, and a reason to impose a code freeze once in awhile. Nobody cares about the first reason except the silly people who fall into that category. As for the second reason, since the issue here is completing an incomplete new feature, I suspect that code freeze means it can't be worked on until after 1.6 is released.  

> And what's the point of making users "test" something that's known to be broken
> for a year?

Incomplete is not the same as broken. New features are added to Wine in small parts, so each part can be tested and problems identified early, before something else is added that depends on behavior that turns out to be a real bug. In practice, this means that for a period of time when a new feature is being introduced, fixing one problem just leads you to next. That's what happened in this case--the first bug was a crash. 

(In reply to comment #59)
> 
> Before the response was "this is an unstable Wine version, we will fix it
> later, downgrade to stable"
> 

I don't know where you imagine you saw the advice to downgrade to the stable release, but it's nowhere in this bug report.

Tried to find good words for a while now - did not find them - anyway:

I want to start with a question that hopefully brings us a step ahead:

What can we (the community) deliver to fix the bug? Logs, debug output? 
(Don't tell me to send a patch, I want a serious answer. I think there are people out there who know gdb and similar things but not the (dwrite) wine code.)

I think this is the place to work on bugs, independet when they will be fixed.

So I'm sorry that I mention my own opinion in the following lines, but I found some points that took my breath.

@ Jerome
> It's 100% irrelevant how Linus or anyone else might react in a
different project.
He just forgot the <sarcasm> quotes. Me too.

> Wine is in the release candidate stages and that's simply too late for major features like these.
Of course. Following this strictly, incomplete features should be disabled!

> As for disabling it by default, that's not going to happen.
Your last statement is contrary to this statement.

@Rosanne:
> Well, I think that gets into the question of what purpose, if any, the "stable" 
> branch serves. From what I've observed, it seems to serve two purposes: a
> security blanket for users who need one, and a reason to impose a code freeze
> once in awhile. Nobody cares about the first reason except the silly people
> who fall into that category.

<sarcasm on> This category does not exits since they do not get a security blanket since there is no difference between wine dev and wine stable <sarcasm off>

> As for the second reason, since the issue here is
> completing an incomplete new feature, 
> I suspect that code freeze means it can't
> be worked on until after 1.6 is released.  

And now I found a contrary in your statment, too. What does "code freeze" mean?
For me it means: All known bugs should be worked on and new features cannot go in the new release.
On the one hand you can say this is an existing feature since 1.5.10, so it should be fixed for 1.6. On the other hand you can say this is a new feature. But then it should be disabled in 1.6 since incomplete new features cannot go in 1.6. That does the code freeze tells us.

Please open a forum thread for further discussions. Let's try to keep this bug report clear from now on.

(In reply to comment #62)
> It's 100% irrelevant how Linus or anyone else might react in a
> different project.

In Linux, and any reasonable project, a feature that turns out to be broken gets immediately disabled until it's fixed.

*** Bug 35638 has been marked as a duplicate of this bug. ***

OK I FOUND A SOLUTION
go in wine config and add steam as an application then go to libraries and type dwrite
click add
click edit
select native
once you do that launch steam and enjoy

it's not solution, it's band-aid workaround

*** Bug 36751 has been marked as a duplicate of this bug. ***

wine 1.7.23 on openSUSE Factory Rolling Release here. I am also affected by this bug. The login screen doesn't display any fonts and typing in some fields also doesn't print characters.

In the meanwhile there was some work with direct write.
But there's still no text in Steam with todays wine 1.7.28

Still present in wine-1.7.32

Confirmed on openSUSE Tumbleweed with Wine 1.7.36

Does anyone really know what exactly needs to be fixed that this starts to work? There has been a lot work towards dwrite, but it still doesnt work with steam.

(In reply to Teras from comment #77)
> Does anyone really know what exactly needs to be fixed that this starts to
> work?

A lot of things.

> There has been a lot work towards dwrite, but it still doesnt work
> with steam.

No, it doesn't. When it's done it will be mentioned in this report. In the meantime it makes no sense to confirm it over and over again.

1.7.44-staging still need to disable dwrite(windows 7) to display text fonts. Notices after some using wine current prefix.

This works for me now, after http://source.winehq.org/git/wine.git/commit/44c301c584935fbe4a1e95e65306f5ec13791552. Please open separate reports if something doesn't look right, don't reuse this one.

(In reply to Nikolay Sivov from comment #80)
> This works for me now, after commit 44c301c.

Awesome. Thanks.

Closing bugs fixed in 1.7.49.

*** Bug 39479 has been marked as a duplicate of this bug. ***