Re: PangoWarning: failed to choose a font with 'PangoRenderWin32' renderer

[Andreas Sommer <andreas sommer87 googlemail com>]

Thanks for your suggestions. John, my GTK+ runtime does not even have a
pangorc file, and other programs like Glade are always working just
fine. Even creating such a file with

[Pango]
ModuleFiles=C:\Program Files\Glade 3.7.1\etc\pango\pango.modules
ModulesPath=C:\Program Files\Glade 3.7.1\lib\pango\1.6.0\modules

and pointing to it with an environment variable PANGO_RC_FILE did not
change anything.

The weird thing is that the problem is indeterministic, 20% of the times
I start the program, it renders text correctly.

So I will dig into debugging by compiling myself. But I'm already having
trouble compiling the dependency glib using VS2010. Do you have any
suggestion on this error:
1>C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
warning MSB8012:
TargetPath(C:\Projects\glib\build\win32\vs9\Debug\Win32\bin\glib.dll)
does not match the Linker's OutputFile property value
(C:\Projects\glib\build\win32\vs9\Debug\Win32\bin\glib-2-vs9.dll). This
may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt) property values
match the value specified in %(Link.OutputFile).
1>C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5):
warning MSB8012: TargetName(glib) does not match the Linker's OutputFile
property value (glib-2-vs9). This may cause your project to build
incorrectly. To correct this, please make sure that $(OutDir),
$(TargetName) and $(TargetExt) property values match the value specified
in %(Link.OutputFile).
1>LINK : fatal error LNK1104: cannot open file
'C:\Projects\glib\build\win32\vs9\Debug\Win32\obj\glib.def'

The glib.def file does not exist and is not generated. Or is there an
easier way to compile pango and dependencies? Maybe cross-compile from
Linux using mingw32 ports?

On 12.03.2011 08:02, John Emmas wrote:
> Hello Andreas,
>
> My experiences are actually with C++ but the first time I built a GTK app using Pango I had exactly the same problem and it took ages to figure out.  Here are some of the lessons I learned though....
>
> I'm not sure if it's Pango itself or if it's something else that affects Pango (GTK maybe) - but for Win32 builds, your application's "exe" file is expected to be in a folder called "bin".  The "pangorc" file is expected to be in a folder called "etc/pango" which is a subdirectory of the directory where "pango.dll" is installed.  If your pango DLL isn't called "pango.dll" (which mine wasn't) "pangorc" is expected to be in the folder "../etc/pango" (i.e. a subdirectory of your "bin" folder's parent directory).  It's all pretty confusing.
>
> As an example, if you're currently building your exe target into "C:\Program Files\my_app" you'll need to change that to be "C:\Program Files\my_app\bin".  You'll then need to create the following folder:-
>
> C:\Program Files\my_app\etc\pango
>
> and make sure it contains these files:-
>
> pangorc
> pango.modules
> pangox.aliases
>
> "pango.modules" then needs to contain the correct paths to wherever your pango module files are located.
>
> I have to confess that I'm not at all familiar with PyGTK (or even with Python) so forgive me if you already know all this or if none of it is relevant to PyGTK.  As I said earlier, my comments are based on my C++ builds.  However, I do remember that when it came to pango's modules, their physical locations are very critical.  I suspect that this will almost certainly be the explanation for your problem.  For C++ there's also a "config.h" file which needs to be set up correctly, though that might not apply in your case.
>
> Ultimately though, as Behdad suggested, you might need to build everything from source and debug it yourself.  That's what I had to do eventually.  There's no way I'd have found any of this out otherwise.
>
> John

On 11.03.2011 23:29, Behdad Esfahbod wrote:
> Hi,
>
> I don't know how to help except for suggesting that you compile pango yourself
> and dig into debugging, but guess you already knew that.
>
> behdad