http://bugs.winehq.org/show_bug.cgi?id=58887
Bug ID: 58887 Summary: Opening screen of Photolemur 3 has 'tofu' characters between letters on three lines Product: Wine Version: 10.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: superian@gmail.com Distribution: ---
Created attachment 79551 --> http://bugs.winehq.org/attachment.cgi?id=79551 Terminal output when running the program
After installation, running Photolemur 3 version 1.1's opening screen has 'tofu' characters between letters on three lines.
Adding a font to Wine's Windows/Font folder does not cure this.
I cannot find a download link for the setup program, but I will keep looking.
shasum256 Photolemur_3_Win_Setup.exe 4e185aa8358af73b1f0cdfd8d9709e0bbe7aceb20886577e923ebf19bb53d3c7
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #1 from Ian superian@gmail.com --- Created attachment 79552 --> http://bugs.winehq.org/attachment.cgi?id=79552 A screenshot of PL3 under Wine 10.17 showing this
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...it's not really "tofu"...but it still seems to be something stupid...
Namely, it looks like the window is being given a utf16 string and tries to interpret it as 8-bit/utf8...yet it gets the proper length of the string...
Most interesting part seems to be that only *some* of the strings are affected...
The program might be using something more complicated than TextOut, but on the off-chance it isn't, would you check if 'text' channel is showing something about those strings ?
Otherwise, try to determine which function displays them and trace it back to the point A/W mixup happens.
(if it's a font problem, it's likely only in the way that the fallback path triggers an obscure bug - cause the text, while looking incorrect, is also correct in its content)
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #3 from Ian superian@gmail.com --- It is interesting, isn't it? I did wonder about utf16, but wouldn't the start characters have the 'box' in front of them in that case? Instead, it's just between all of the characters in those lines.
There is one other place where the characters are not being displayed properly: in the settings menu where selected options have the 'box' in front of them. I'll see what they're supposed to be shortly.
I have found a download for the install program:
downloads.skylum.com/photolemur3/win/Photolemur_3_Win_Setup.exe
It has the same sha256 as my copy.
There are just over 160 files in the folder. There are numerous examples of the "800x600" string in the Common.Localization.dll, but there's one in Photolemur.ImportImages.dll too and that also has - in utf8 / certainly not utf16 - "DRAG PHOTOS HERE" just before that and "OR" plus "OPEN SAMPLE IMAGE" just after it.
http://bugs.winehq.org/show_bug.cgi?id=58887
mata sutupud@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com
--- Comment #4 from mata sutupud@yahoo.com --- It would make sense if the software was adding some unicode combining character to "style" the text after each original character, and the font doesn't support that. Would be interesting to know how it looks like on windows.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #5 from Ian superian@gmail.com --- Created attachment 79554 --> http://bugs.winehq.org/attachment.cgi?id=79554 How it looks on Windows
I'm probably turned some transparency off in Windows when debloating after the move to Windows 11: note that the window is not translucent unlike the one in Wine.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #6 from Ian superian@gmail.com --- Created attachment 79555 --> http://bugs.winehq.org/attachment.cgi?id=79555 Another screenshot under Windows showing it's a tick character that's not displayed under Wine
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #7 from Ian superian@gmail.com --- Funny you should ask :) I did some screenshots when booting into Windows for a few minutes following a kernel-update reboot for Linux Mint last night.
The text with the boxes between the characters should be bold. So should the word 'OPEN' on the button, but that doesn't have this effect.
For no very good reason, Photolemur loves having unnecessary GPU effects whenever it can, so is it possible this is an issue with converting some calls to get the GPU to make the text bold?
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com --- From the logs it looks like at least some of that is using WPF for its UI. Installer does for me at least, but it doesn't work with wine-mono as far as I can tell. Have you installed .NET runtime manually?
Also please attach +dwrite log (as a text file), at the time when you see this splash screen with null glyphs.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #9 from Ian superian@gmail.com --- No I haven't installed .NET (the PL3 installer trying and failing to do so was the issue that made it 'garbage' a few years ago - the Ian who did the report on AppDB back in 2019 was me...)
I did let Wine install the Mono it asked to install on initial installation of Wine 10.17, where it's in drive_c/windows/mono/mono-2.0, but it's not installed system wide:
$ mono -V Command 'mono' not found, but can be installed with: sudo apt install mono-runtime
If I add "WINEDEBUG=+dwrite" to the environmental variables, nothing materially different appears on the terminal output. Am I missing something?
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl ---
If I add "WINEDEBUG=+dwrite" to the environmental variables, nothing materially different appears on the terminal output. Am I missing something?
Define how you understand "add <FOO> to environmental variables".
Basically, nothing past 'WINEDEBUG=+dwrite wine <app name>' should be necessary (well, besides the part meant to capture debug output).
If you did it correctly, no new output would be a bit strange...(unless your prefix is a semi-random mix of builtin and native)
Perhaps add also 'loaddll' to the list of channels.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #11 from Ian superian@gmail.com --- Normally, my script to launch this would be:
env WINEPREFIX=/home/ian/.winepl3 wine "[location of Photolemur 3.exe]"
So either
export WINEPREFIX=/home/ian/.winepl3 env "WINDEBUG=+dwrite" wine "[location pf Photolemur 3.exe" export -p WINEPREFIX
or
env WINEPREFIX=/home/ian/.winepl3 env "WINDEBUG=+dwrite" wine "[location of Photolemur 3.exe]"
... so that both the WINEPREFIX and the WINDEBUG get passed.
Am I doing it wrong?
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #12 from Ian superian@gmail.com --- It would help if I could spell WINEDEBUG, ahem.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #13 from Ian superian@gmail.com --- Created attachment 79564 --> http://bugs.winehq.org/attachment.cgi?id=79564 PL3 debug run with dwrite and loaddll
Expands to about 65MB of text...
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com --- Thanks. It's right there:
--- 0124:trace:dwrite:dwritetextanalyzer_GetGlyphs L"U\200aN\200aL\200aO\200aC\200aK\200a \200aF\200aU\200aL\200aL\200a \200aV\200aE\200aR\200aS\200aI\200aO\200aN":37, ---
So text is originally interleaved with 0x200a "hair space" characters. This basically means we need to check if it should synthesize something if this character is missing from font, of if you'll get same null glyphs on Windows, when using a font without 0x200a support.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #15 from Ian superian@gmail.com --- Adding Tahoma to the Windows/Fonts directory solves this on the opening screen :)
But it makes anything that should have a tick on the Settings menu appear as all boxes :(
Without Tahoma, only the tick is a box.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #16 from Ian superian@gmail.com --- Created attachment 79565 --> http://bugs.winehq.org/attachment.cgi?id=79565 Screenshot of PL3 opening screen looking good after installing Tahoma
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #17 from Ian superian@gmail.com --- Created attachment 79566 --> http://bugs.winehq.org/attachment.cgi?id=79566 Screenshot of PL3 settings menu not looking so good with Tahoma installed
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #18 from Ian superian@gmail.com --- Created attachment 79567 --> http://bugs.winehq.org/attachment.cgi?id=79567 Screenshot of PL3 settings menu not looking so good with Tahoma installed and a second option ticked
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #19 from Ian superian@gmail.com --- Installing a font called Segoe UI doesn't help with the Settings menu issue.
If I look at an even longer dwrite log file generated while looking at the Settings menu, there's a reference to FontFamily 'Liberation Sans' not long before it wants to output "Correction", but adding Liberation Sans to the Windows/Fonts folder makes something very unhappy and it terminates before getting to the opening screen.
http://bugs.winehq.org/show_bug.cgi?id=58887
--- Comment #20 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Ian from comment #19)
Installing a font called Segoe UI doesn't help with the Settings menu issue.
If I look at an even longer dwrite log file generated while looking at the Settings menu, there's a reference to FontFamily 'Liberation Sans' not long before it wants to output "Correction", but adding Liberation Sans to the Windows/Fonts folder makes something very unhappy and it terminates before getting to the opening screen.
None of that is related to original issue with null glyphs being rendered. Let's keep this report about your original issue.