OK, I don't do much .Net programming, but I do have one that I maintain, so the answer to this may be obvious.
Setup:
Windows 7 Ultimate with All Language Packs Installed
Visual Studio 2008 Winforms VB.Net project.
I'm in the process of localizing this project, and when I'm making the Japanese version of the forms, the characters display as squares, though they render in my browser correctly. I'm guessing that this is because the default font does not have a glyph for those characters.
So, my questions:
Are winforms UTF-8, or some other character encoding?
Is there a way to change the character encoding?
Should I change the font for the Japanese forms, or will Windows do it?
What's the general best practice here?
I want to know that I am copying the characters correctly into my forms, and I want to be able to test them. How can I do this?
Thanks for any feedback!
EDIT:
Thanks for the info! Here's what I've found.
Arial Unicode MS does have all the glyphs, but I wasn't using it, because it wasn't in the VS2008 list of fonts. I manually edited the font box to use it, but then Visual Studio throws the message, "Attempted to read or write protected memory. This is often an indication that other memory has been corrupted." I'm guessing that's because VS doesn't have permission to access that font for some reason. I go back to the default font, scary error message goes away.
Then, even when using Arial Unicode MS, the text renders as blocks in the forms titles. Same text renders correctly in labels.
So, I think I want to use the default font, and let Windows handle it. I think I've read that everything from XP on will handle it. Windows 2000 won't, which is a shame, but what ever, I don't know what font I should use, and whatever font it is was excluded from VS. I don't know how to add it without getting lots of error messages about protected memory.
Now the problem is, resizing the labels in the form, since the translated text is often larger.
Also, I don't have a support team to do this for me, but I could maybe install extra copies of Windows 7, and change to the Japanese language pack and try to run it. But that becomes a major pain. I thought I read that you could change the language while the application is running, but that doesn't seem to be true. MS docs talk about how to do this, but Windows 7 also tells you that you have to log out to change the language.
MS Gothic seems to work, and it's part of VS 2008, but the title bar is still squares. That's really odd, since the same glyphs are in the winform. Is that because title bar fonts are set at a system level, and not the application level?
Sorry for being wordy. Not sure that there is even a question here. Just trying to get it all out, so maybe this will help someone else down the line.
Any .NET code, including Windows Forms, uses Unicode encoded as UTF16. Your problem isn't likely to be an encoding issue, that produces question marks instead of squares. Getting a square indicates you are using a font that is missing the required glyph to display the Japanese character.
You can use the charmap.exe applet to find out what glyphs are supported by the font you use. If they are missing then the operating system is forced to fall back to a substitute font and fail at it when it cannot find one. Displaying squares is then all it can do. An old operating system version is a very likely cause for this mishap, particularly so for XP without the optional East Asian fonts installed.
Do note that this font problem is very unlikely to be an issue on a machine that boots the Japanese version of Windows. It will have to proper fonts to display Japanese text of course. You can get specific language versions of Windows through an MSDN subscription. At least get one for your QA staff so they can verify that everything works correctly.
Here's a great read on your issues from Joel Spolsky.
Just to be clear, did you install the language support: Control Panel / Regional Options / Display Languages. Presumably you've got Japanese text in the source code. You're saving the source code as some sort of Unicode, right?
For 3 years I've maintained a Japanese forms-based app (www.jbrute.com) which migrated from MFC, to WinForms to WPF across US English versions of XP, Vista and Win7. It displays Kanji, Kana and Uses the IME. No grief whatsoever.
Related
According to their website (http://www.gdpicture.com/products/managed-pdf/) you have the ability to extract fonts from a PDF file. However, I can't seem to find the functionality to do this. I have encountered several methods to add them, but none to extract them (and they don't show as embedded files). Has anyone tried to do this, or have experience with GdPicture?
Version: 14 (Current)
Disclosure: I am part of the ORPALIS technical staff that edits the GdPicture.NET SDK, that's why I know there's an ongoing communication about this already.
It is my understanding that you have a support case open for a merging issue relative to fonts and as you know, our development team is currently working on a fix that will solve it so I strongly recommend that you wait for them to finish.
There's no extraction of the embedded font as you might expect at the moment but the development team is also working on one, we will let you know as soon as it is available (it should be very soon).
You can get information about (already) embedded fonts using the GetFontCount, IsFontEmbedded, GetFontName and GetFontType methods.
You can also add new embedded fonts (of different types) using the AddFontFromFileU, AddStandardFont, AddTrueTypeFont, AddTrueTypeFontFromFile, AddTrueTypeFontFromFileU and AddTrueTypeFontU methods.
this is a question I have posed already in two forums for different aspects (keyman and oxygen XML product forums), but I suspect there is a more general issue which I fail to see.
I have Keyman installed on Mac OS X and would like to use it with Word, libreoffice, oxygen or other software to type ethiopic script. However the behavior is quite strange in my understanding.
If I type a combination to obtain a character like 'h+a' I expect to obtain 'ሀ' but I get 'ሀh' or typing b+a to get 'በ' I get instead 'b በ'
In TextEdit for example this works fine and I do not understand why it does so in word and other editors.
Any suggestion on how to solve this?
Keyman for Mac OS X is a beta release product. This means that it has known issues and is being made available for testing. So, this is a known bug in the beta release of Keyman for Mac OS X. At the bottom of the Keyman for Mac OS X home page you can see a list of known issues, and the relevant issue is:
Keyman does not detect context correctly in Open Office or LibreOffice or MS Word 2011 14.4.3.
There's not much you can do to solve the problem yourself, bar typing in TextEdit and pasting into other editors (which isn't practical). I am on the Keyman developer team and we are aware of the issue and are working on it.
How to identify which smalltalk IDE/implementation is used by seeing an desktop application developed in smalltalk?
The icons and the lines in the shown widget strongly point towards VisualAge Smalltalk from IBM, which nowadays is VA Smalltalk from Instantiations. The program obviously was generated with a replacement window icon, so that you cannot tell from the window, but the container icon tree displayed here makes me almost 100% sure it is VisualAge.
Do you happen to have access to the runtime directory on that Windows computer? If so, is there a program called abt.exe or nodialog.exe? Or even better: is there one or more of these subdirectories in the runtime directory: \bin \nls \bmp? If so: it is VA.
A picture of the start-up splash screen would help confirm or eliminate some dialects, as would an indication of what OS's it runs on, or the year it was first deployed (is there a copyright statement on the splash screen?). These icons remind me of OS2 or Windows 95 (or Windows 3.1), which would indicate a very early Visual Works or perhaps VSE. Any insight into the source storage mechanism would help too - a .dat file indicates an Envy based system, which would be either early VisualWorks, or VisualAge. Another possible indicator is the icon in the upper left of the window - but the "blue sky/green mountain" in your picture is not one I recognize. VisualAge first had the "eyeball", then later the "Smalltalk balloon" that hearkens back to the 1980 Byte magazine cover. For pictures of some of the older IDEs, look through the older out of print Smalltalk training books at http://stephane.ducasse.free.fr/FreeBooks.html
My company is moving to a new system which has a very poor printing system in place but it does create PDF's on the file system.
My Boss has asked me to create an application to print all the PDF's based on a JOB number.
I've gotten the filesystem search working, I have used the acrobat sdk to open each file and find certain strings to determine which pages go where.
The problem I'm dealing with is that the Acrobat SDK doesn't seem to support choosing printer settings.
My first thought was no big deal I just change the default windows printer and just change the tray so the invoice part and equipment listing go to white paper from tray 1, and the remittance goes to tray 2 on blue paper.
It seems like the printdocument in .net can handle alot of printer settings but I'm not sure if a PDF can be used with a print document.
Looking for any advice or assistance.
Thanks,
Joshua
I found the answer was to use Win32.
Here was the website that helped me get through some of the hurdles:
http://edinkapic.blogspot.com/2011/01/how-to-set-printer-default-paper-bin-in.html
The underlying problem is that PDFs are combination of vector graphics for the text and bitmapped images. It all needs to be rendered into a format the printer understands before being printable.
Ghostscript does this very nicely and if you need to do it from .Net, GhostScript.Net provides an excellent vb.Net interface.
The problem I'm dealing with is that the Acrobat SDK doesn't seem to support choosing printer settings.
You can't use the desktop version of Acrobat for this, since it's not designed for unattended operation and requires a user interface. Also, I believe it violates Adobe's license.
There have been a few times where I've used unicode symbols in place of small icons in one of my Cocoa apps, either because it's easier to draw inline with text or because I didn't feel like firing up Photoshop to draw a simple arrow. I've wondered though, could there be issues with localization or fonts I might not be aware of? Are there any cases where these symbols might not match what I'm seeing on my workstation?
I don't see anything really wrong with this shortcut approach, especially given Apple's concern for typographic quality. In your shoes, I would consult the Unicode Code Charts, and make sure I'm very carefully specifying a programmatic unicode character rather than relying on typing it in my editor.
Since cocoa uses unicode extensively internally, and since most API methods that don't specify encoding have been deprecated for the last couple iterations of OS X, I think you're pretty safe. As you're writing a desktop/iphone app, rather than a webapp where the deployed fonts are unknown, you should be OK from a bitmap rendering standpoint if you stick to unicode characters that can be rendered by the known default fonts that ship as part of the system.
As long as you ensure it's one of the symbols included in a standard system font and it's set in the right font, there shouldn't be anything to worry about. Apple itself uses Lucida Unicode symbols all over Aqua. The only way that could go wrong on an end user's computer is if his system was broken anyway.
No; Cocoa has strong Unicode-fu. If you do have a problem, it'll probably be your fault—most likely, converting to or from the wrong encoding. (GCC used to have problems with \u sequences in #"" literals, but I believe that's fixed now.)
On the other hand, using characters such as on a webpage is a good way to confuse non-Mac users.
I wouldn't do that. not consistent with the look and feel you usually get on an iPhone or a mac...