blog.i18n.ro » Output

iOS and Romanian language

sorin — Sat, 12 Mar 2011 09:58:43 +0000

First I have to confess that I’m pleased about the amount of attention Apple gave to supporting Romanian language on iOS 4.3 (iPhone/iPad/iPod). I remember reporting few bugs to them regarding Romanian support and I was glad to discover that they were addressed in the next releases. It looks that they do care about the feedback they get, even if you do not have any kind of feedback regarding how they deal with a reported bug.

Still with current iOS there are few problems with the Voice Control and romanian diacritics. Romanian language has only a small number of diacritical characters but it looks that speaking fails to recognize them.

English voice recognition and voice over used in iOS could be easily be tuned to support romanian diacritics.

ș – reads like sh in shut
ț – reads like zz in pizza
ă – reads like a in above
î – close central unrounded vowel
â – reads the same as î

More details regarding phonetic reading of romanian characters can be found on wikipedia.

In addition to the voice issues listed about there is another very annoying bug inside the Romanian keyboard dictionary. Inside the default dictionary there is the word “La“, with the first letter uppercase. This is an extremely common work in Romanian and the auto-correct function will try to replace every “la” with “La”, making typing very hard. Probably this is one of the reasons why most romanians are disabling the auto-correct functionality.

I contacted Apple again and I hope they will solve these bugs soon. And from my Romanian friends, I expect some replies with their experience and maybe some likes on Facebook if they encountered the same problems.

Update #1 – Also I have to mention the the Romanian keyboard lacks the Romanian quotation marks:

U+201E , U+201d – first level
U+00AB , U+00BB - second level

Apple failing to support high-DPI on iTunes

sorin — Tue, 02 Nov 2010 11:08:47 +0000

The irony is that Apple who created the smartphone with the greatest DPI ever, is unable to add high DPI support for their iTunes application.

Here is how the latest iTunes 10 application under Windows 7 on a computer that has the DPI setting set to 150% (“Larger”) also known as 144ppi.

Steve, what kind of QA is the iTunes team doing? As you can see this is not a minor/cosmetic issue anymore.

Basic Unicode readiness testing for your application

sorin — Thu, 29 Apr 2010 15:11:22 +0000

Unicode is a very complex standard, always evolving, but this doesn’t mean you shouldn’t do some basic testing, in order to uncover hidden bugs.

Here is a small Unicode string that could be used to test the readiness of your application to deal with Unicode strings. You can use this string to:

filename – save and load files using this string as port of the filename. Also you should try a long path of more than 260 characters in order to find problems regarding usage of older API under Windows.
text input (paste it) and see if the application will display it wrongly.
- input cursor – first check how cursor moves under Notepad on Windows 7 and see if your application behaves the same. If you’ll see strange character movements or decompositions, you are doing something wrong.
- selection – as above, check the notepad fist and after this check if your application does select text the same way
rendering, if your application is rendering text somewhere, it’s a good idea to use it to see if it does render well
- text size, are the CJK characters too small to be recognized?
- bad rendering, an empty rectangle may indicate a missing glyph (required font missing), this is not very dangerous – nobody has all the fonts but if you see question marks or other strange things you may have a real problem. It’s best if your application does support font-fallback, when it does display text in order to prevent the missing glyph sign.

I will post a text file encoded as UTF-8 (with BOM) that contains the test string because WordPress will cut the article where it does find the character outside Unicode BMP.

Let me know if this helped you and if you know additional tests that I could include in this basic test.

Using Unicode console output with Python

sorin — Wed, 06 Jan 2010 14:12:51 +0000

On Windows console and Unicode are not quite friends. Here is some code that I use in order to assure that my Python scripts output is consistent on all platforms and is supporting Unicode encoded as UTF-8.

You’ll be able to see the right characters if you are running on Windows 7 but on Windows XP you’ll see the UTF-8 ccodes displayed as ANSI. Even with this problem you’ll be able to redirect the output of stdout or stderr to files in order to store UTF-8 output.

On other platforms like Linux or OS X it will just use UTF-8 without any problems.

#!/usr/bin/python # -*- coding: UTF-8 -*-


import codecs, sys
reload(sys)

sys.setdefaultencoding('utf-8')
print sys.getdefaultencoding()
if sys.platform == 'win32':

try:

import win32console

except:

print "Python Win32 Extensions module is required.\n You can download it from https://sourceforge.net/projects/pywin32/ (x86 and x64 builds are available)\n"

exit(-1)

# win32console implementation  of SetConsoleCP does not return a value

# CP_UTF8 = 65001

win32console.SetConsoleCP(65001)

if (win32console.GetConsoleCP() != 65001):

throw ("Cannot set console codepage to 65001 (UTF-8)")

win32console.SetConsoleOutputCP(65001)

if (win32console.GetConsoleOutputCP() != 65001):

throw ("Cannot set console output codepage to 65001 (UTF-8)")
#import sys, codecs

sys.stdout = codecs.getwriter('utf8')(sys.stdout)

sys.stderr = codecs.getwriter('utf8')(sys.stderr)

print "This is an Е乂αmp١ȅ testing Unicode support using Arabic, Latin, Cyrillic, Greek, Hebrew and CJK code points.\n"

Using msdev resource editor to create Unicode dialogs that will not display well

sorin — Tue, 21 Apr 2009 08:08:25 +0000

I was surprised to discover that creating Unicode UI elements in the resource editor of Microsoft Visual Studio 2008 (SP1) does work, BUT when you compile your application they will fail to display well.

I created two test Win32/Unicode native applications one using MFC and one without MFC – the issue appear on both. I didn’t bothered to test .NET because I’m not interested in it.

Take a look at my screenshots below. It’s really simple to reproduce it yourself: just use the MSDEV Wizard to create a new application and paste some Unicode text into one of the dialogs.

Some interesting thing to consider:

I didn’t change the font in the dialog – it’s using the default value: “MS Shell Dlg”
If you modify the language of dialog from the default “English (United States)” to a language that does contains the testing characters they will display – but this is insane! It does mean that is still using codepages?! and worse that you cannot create a dialog containing characters from different scripts?
Isn’t Windows supposed to do font face substitution?
I tested only on Windows XP SP3.

Sad but this does look like a What You See is What you WON’T Get.

Later, same … day

Let’s see the list of bugs I’ve just discovered on Microsoft Connect using it’s “very sad” search feature

By default the RC Files are not Unicode, even on Unicode projects, duh!
Resource editor doesn’t tell you to save the files as Unicode when you have Unicode characters on it. So you loose them without knowing it!
Resource editor doesn’t support UTF-8 – sad!
Resource compiler doesn’t support UTF-8 – sad!

Bugs found on Microsoft Connect: 176612, 100833, 162872. Some of them being submitted 3 years ago for Visual Studio 2005: None of them solved even in newer versions like 2008.

And the DIY formula

Open the RC file using text editor and save it using File > Advanced Save Options and select Unicode – Codepage 1200. It took me quite some time to figure it out just because several people considered that Unicode related bugs are not so important. Maybe we can suggest to rename the Unicode option from the Application Wizard to “Partially Unicode”.

Unicode character sets for testing font coverage

sorin — Fri, 26 Sep 2008 18:25:09 +0000

Testing Unicode coverage for fonts is always a problem and I decided to create a simple set of character sets for testing the coverage. I’ve splitted them by language groups based on regions. Using these strings should be quite easy.

You should remembers some things:

This article is still under development.
It’s not safe to test font strings inside the browsers because they do have font-fallback
soon I will add font-coverage for the most used fonts

Simple scripts – Latin, Cyrillic and Greek

Groups from 1-4 are additive, so characters already included in previous groups are removed

Group 1 – Basic – 5 languages – en, fr, es, de, it

ºßàáâãäåæçèéêëìíîïñòóôöø
ùúûüÿāăčēĕīĭōŏœšūŭžǔ

Group 2 – Western – 6 languages – da, fi, nb, nl, pt, sv

õđńŋřŧǎǥǧǩǯȟʒ

Group 3 – Eastern – 10 languages – ro, tr, pl, cs, hu, sk ,hr, et, lv, sl

ýąćďđėęěğģįİıķĺļľłņňőŕ
śşţťůűųźżșțіїј

Group 4 – Cyrillic – 5 languages – ru, uk bg lt sr

абвгдежзийклмнопрстуф
хцчшщъыьэюяѐёђєіїјљњ
ћѝџѣѫґ

Group 5- Greek

… TBD

Complex Scripts (to be done)

Japanese
Korean
Chinese
Arabic
Hebrew
Greek

How to test fonts under Windows ?

If you want to see character coverage you should use BabelMap, and if you want to write different texts you can use BabelPad. These two tools the best I’ve found so far and are free.