I have tried install llvm 7.0.1 on Windows 10.
But the installer has text corruption like below.
It make so harder to install.
How do I fix it?
I using Windows 10 1809, chcp is 65001.
I using Japanese.
I have enabled "Use Unicode UTF-8 for worldwide language support" in Region settings".
Is this change cause of the error?
But A installer of other application does not be text curruption.
Update:
The Picture of installer with compatibility mode (Windows XP SP3)
That LLVM installer is not a Unicode NSIS installer. The LLVM team can fix it by adding Unicode True to their NSIS script.
That LLVM installer looks like it supports multiple languages (I could not find it's source, it might be using CMake/Ninja) and NSIS does try to guess the correct language but this is based on the return value of GetUserDefaultUILanguage() and not the active codepage.
I could not replicate your issue on build 18290 (after changing to UTF-8 and rebooting I verified that GetACP() returns 65001) but this is probably because my system is detected as English by NSIS.
Based on the (N) in your Next button in your screenshot I'm going to guess that your UI language is detected as Chinese or Japanese?
Without more information about your system it is hard to guess if this is a bug in NSIS or Windows. NSIS is a relatively normal application and does not call MultiByteToWideChar on its interface strings (IIRC).
Edit:
By forcing a installer to pick Japanese I can replicate your issue. The solution for this issue is to switch your "language for non-Unicode programs" back to Japanese if you wish to install this application using Japanese as the display language. Another solution you can try is to set the locale for a single application. AppLocale was Microsoft's solution to this but it is not supported on Windows 10 but there are other alternatives out there.
When building a NSIS installer without Unicode support the program stores the text internally as raw bytes encoded with the codepage of the specific language. At run time it uses functions like SetWindowTextA to set the text of UI elements. This is how non-Unicode applications have worked since the dawn of time on Windows. All non-Unicode programs that display text outside the ASCII range will have the same issue unless they have been specifically written to support UTF-8 as the active codepage (which is unlikely since it is a new feature). This feature is only useful for console applications and ported POSIX applications that assume that the narrow string is UTF-8 encoded.
Too long for a comment.
UPDATE: Looking at this a little, I am wondering if the problem is a font corruption issue. There is a description of rebuilding the font cache here: http://www.trishtech.com/2013/11/rebuild-fonts-cache-windows-8/. I think you must install a good copy of the font file first though? You do that by copying the font files into the Fonts folders I believe. I will check with Anders what font NSIS uses.
Similar issue with an MSI file: Windows Installer ugly font rendering.
Compatibility Mode: Pretty sure that UTF8-setting would cause it. I don't think it would work, but the first thing I would try would be to run the executable in compatibility mode.
Locate the setup.exe in question.
Right click the EXE, hold right mouse button down, now drag to empty desktop area and release mouse button. Click "Create Shortcut Here".
Right click Shortcut => Properties => Compatibilty tab.
Try various combinations of "Run program in compatibility mode for..."
I would try "Windows XP" highest service pack first. Click OK when done.
Now double click the shortcut to launch the executable and see what happens.
Im having some glitching issues while using JasperSoft Studio. (using the latest version from the AUR).Im using GNOME.
Steps to reproduce :
Add Text Field. Select it.
Go to Properties -> Borders -> Click on a border on the square.
The Pen Width (1.0 by default) appears for an instant and then "disappears" (Its still there as I can select it but i think the font color becomes white)
This can be temprorarily resolved by going to preferences and toggling the theme from classic -> GTK or vice versa. The resolution exists only for the current report and does not remain for other opened reports. Really annoying bug.
Ive tried Adwaita and GTK other themes etc...but no use. The bug persists.
I have a version 6.1.1 of Jaspersoft Studio on another machine running the latest UBUNTU GNOME and it works near perfectly.I tried running this version of Jasper on arch using various settings but it stops working as soon as I open a JRXML file. Nothing is clickable and I have to kill the process. I am guessing its a GTK issue.
I dont want to go back to using Ubuntu as I love the Arch experience. Can someone help me to run the AUR version of Arch without this glitch.
And if you think 6.1.1 should run fine on Arch...can someone help me overcome the GTK issue (Ive already tried export SWT_GTK3=0; but it doesnt work)
Thanks.
Try editing the runjss.sh script (probably in /opt/jaspersoftstudio) and add the line
export SWT_GTK3=0
Then try running JSS via that script and see if it helps.
I haven't had the same issue as you but I've been having a lot of Gnome-related problems and I'm using the same combination as your - Arch (Manjaro) and Gnome with JasperSoft Studio 6.4.3. Works perfectly since I added that line.
You can also edit the .desktop file to exec runjss instead of the default exec line.
I've created a webapp that uses SVG to allow the user to create an image. Because I want the user to be able to export that image as a PNG, I've embedded a number of fonts directly into the SVG as Base64 encodes (I converted the fonts using FontSquirrel). Everything works just fine under OSX (where I am developing) on all major browsers.
I have limited ability to test Windows machines, but one of my beta test users is having a problem where certain characters render incorrectly under Windows (Firefox or Chrome that we've tested so far). So far, it appears to affect the letter 'g' and the number '8'. Here's what they look like:
I'm pretty stumped... not seeing anything about this on SO or other sights about embedding fonts as Base64. Do I need to set up my encode on font squirrel differently to accommodate Windows or something?
Update: Thanks to Mike for the testing environment link. I took a look at this and it appears to have been an issue with the encoding of my font. It was present on all versions of Windows (7, 8, and 10) and browser combos. After some frustration I redid the font squirrel encode (which I had tried previously) and suddenly everything worked. I don't know, but if someone finds this, I guess re-encode.
I have a HP Pro tower pre-installed with FreeLnx. Every application renders text correctly. However, each time I launch Android Studio it just shows a bunch of squares instead of text characters thus making it impossible to use the application. The debian version is squeeze and GNOME 2.30.2. Any help will be much appreciated.
I simply changed my system font to FreeSans after which I launched Android Studio poof everything started working all fine.
what is this Error, and how to resolve it?
I am using Visual studio 2005 for Smart device MFC developement,
Is upgrading to 2008 can solve my problem.
Error 85 error RC2176 : old DIB in res\icon3.ico; pass it through SDKPAINT
Thanks
this might help you:
http://www.axialis.com/tutorials/vistaicons.html
It looks like vista icons now use PNG headers. The error is slightly false though as its not an old DIB its just a header it doesn't recognize, PNG.
How was that icon created? Long ago Visual C++ 6.0 had its own little way of creating icon .ico files. Probably not using PNG so this might be the way to go is to find some program to emulate that and create an icon using the old DIB way. Or upgrading to 2008 :)
Actually there is another way not mentioned here in the other answers.
If you would install and integrate a more recent (same or later release date than VS 2008) SDK with VS 2005, that also resolves it. You can also go to C:\Program Files\Microsoft Visual Studio 8\VC\bin (or your equivalent of the path) and replace the files rcdll.dll and rc.exe with the ones from a more recent VS, WDK or SDK.
Side-note: the version of rcdll.dll and rc.exe must match, that is you need to copy both at once from your source (be it VS, WDK or SDK). For me any version starting with 6.0 or 6.1 worked. That's any version starting from the compilers that accompanied the Vista SDKs and VS versions or later.
There are actually 2 situations I've encountered that lead to this error RC2176.
As you probably know, a Windows .ICO file can contain multiple images for different sizes and color depth. VS2005 throws this error in at least two situations (unrelated to DIB)
.PNG images in the icon (as described in Codejoy's answer)
256x256 or larger images in the icon
By using GIMP to shrink the largest image size to 128x128, and avoiding .PNG, the problem is resolved with VS2005. Or, upgrade to a newer VS ;)
I had this problem in VS2012 for which I googled but didn't find anything else but this link to a MSDN site which talked about opening it up with sdk-paint , so in my project I doubleclicked the icon that was responsible for the error and deleted the PNG format and voila program started.
Greetz
Richard
The compressed/packed 256x256 was the problem for me. Once I unchecked the option to save as compressed (for Vista) in my icon editor app, the problem went away.
There is another situation I encountered which triggered the error, that is a corrupted PNG file. I've used the sed command to globally replace some strings in the project folder, and it just replaced the (looks liked) windows line ending to UNIX one, which caused my image files corrupted.
So, maybe there are some bugs in the PNG parser of MFC library, which cannot handle malformed input files.
Best resolution I have come across is from Axialis where they offer guidance of saving the ICO file in uncompressed PNG format.
https://www.axialis.com/docs/iw/How_to_use_a_Windows_Vista_Compressed_Icon_in_a_Software_Project.htm