[sip-comm-dev] Sinhala translation is complete!


#1

Hi,

I'm very happy to finally complete the translation. Though there are
still few words to be revised, I'm sure the translation is pretty
good. Please commit :slight_smile:

However there are several issues. The critical one is,
as I previously discussed with Martin, Sinhala text are not rendered
at all with the current configuration.
when the laguage is selected, only box symbols are displayed. The
reason is because the font does not have the glyphs to match to the
unicode values. Default fonts used in any OS currently doesn't contain
glyphs corresponding to sinhala unicode range as I know.

Therefore I edited UIServiceImpl.java to set fonts using UIManager.
Windows vista and 7 come with a sinhala font named "Iskoola Pota".
what I did was check the OS and setting it as the font for all
components.
to do that the current laguage should be read at UIServicesImpl. But
plugin.generalconfig.ConfigurationManager.getCurrentLanguage() did not
work (bundle not started). so I copied that method to
impl.gui.utils.ConfigurationManager. and it worked. (patch attached)
is that ok?
However this way, physical font name is hard coded, which i think is
not a good thing.
Any advices?

Also there are some other issues specially with linux. I'll try to
slove them and post here :slight_smile:

Thanks in advance.

Regards,
Amila

si.patch (4.45 KB)


#2

However there are several issues. The critical one is,
as I previously discussed with Martin, Sinhala text are not rendered
at all with the current configuration.
when the laguage is selected, only box symbols are displayed. The
reason is because the font does not have the glyphs to match to the
unicode values. Default fonts used in any OS currently doesn't contain
glyphs corresponding to sinhala unicode range as I know.

As far as I understand, your Windows is setup with a font which does not
contain Sinhala glyphs i.e. you don't use Sinhala in other applications
and you want to have it in SIP Communicator only? I'm asking because we
use the system font as set by the user on both Windows and the GNOME
desktop environment on Linux and, if that font contains Sinhala glyphs,
SIP Communicator should display them as well.

Therefore I edited UIServiceImpl.java to set fonts using UIManager.
Windows vista and 7 come with a sinhala font named "Iskoola Pota".
what I did was check the OS and setting it as the font for all
components.
to do that the current laguage should be read at UIServicesImpl. But
plugin.generalconfig.ConfigurationManager.getCurrentLanguage() did not
work (bundle not started). so I copied that method to
impl.gui.utils.ConfigurationManager. and it worked. (patch attached)
is that ok?
However this way, physical font name is hard coded, which i think is
not a good thing.
Any advices?

Well... I don't really know the best practices with respect to such a
problem but it doesn't currently sound great to me to have the font
hard-coded into SIP Communicator. It's not that much different but I
might prefer having a list of well-known fonts defined in the
language/translation file itself which SIP Communicator could try to set
(preferably, if it first determines that the current font doesn't have
the necessary glyphs).

路路路

On Mon, 2010-11-08 at 05:12 +0530, Amila Manoj Silva wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

However there are several issues. The critical one is,
as I previously discussed with Martin, Sinhala text are not rendered
at all with the current configuration.
when the laguage is selected, only box symbols are displayed. The
reason is because the font does not have the glyphs to match to the
unicode values. Default fonts used in any OS currently doesn't contain
glyphs corresponding to sinhala unicode range as I know.

As far as I understand, your Windows is setup with a font which does not
contain Sinhala glyphs i.e. you don't use Sinhala in other applications
and you want to have it in SIP Communicator only? I'm asking because we
use the system font as set by the user on both Windows and the GNOME
desktop environment on Linux and, if that font contains Sinhala glyphs,
SIP Communicator should display them as well.

I don't think this is due to setup of my windows. I haven't modified
any setting related to fonts or installed Sinhala fonts other than the
one which is there by default. Sinhala is displayed correctly in web
pages and other applications (firefox etc.).

Object defaultGUIFont =
toolkit.getDesktopProperty("win.defaultGUI.font"); in
impl.gui.UIServiceImpl.java is the place you get the system font for
in windows, right? I knew about that.
In Windows 7, I get
win.defaultGUI.font - Tahoma
win.menu.font - Segoe UI
win.messagebox.font - Segoe UI
these fonts doesn't contain glyphs of Sinhala unicode range.

Without any changes (to a font or setting), Sinhala text is displayed
correctly on title bars in SIP Communicator, I guess that's because
fonts on title bars are handled by the OS

Also SWT renders Sinhala text correctly, I created a simple SWT
application and added a label with sinhala text without changing its
font. It's displayed correctly. That's because in SWT, font rendering
is handled by the OS as I read somewhere

I don't know the exact mechanism how OS handles unicode text but,
swtLabel.getFont().getFontData()[0].getName()
gives the font name as Segoe UI, and that font doesn't contain Sinhala glyphs!
so my guess is the OS somehow picks glyphs from other fonts according
to unicode value and java Swing doesn't do it.

This is same in Ubuntu 10.10, only default fonts are different and
they don't display sinhala glyphs.

Therefore I edited UIServiceImpl.java to set fonts using UIManager.
Windows vista and 7 come with a sinhala font named "Iskoola Pota".
what I did was check the OS and setting it as the font for all
components.
to do that the current laguage should be read at UIServicesImpl. But
plugin.generalconfig.ConfigurationManager.getCurrentLanguage() did not
work (bundle not started). so I copied that method to
impl.gui.utils.ConfigurationManager. and it worked. (patch attached)
is that ok?
However this way, physical font name is hard coded, which i think is
not a good thing.
Any advices?

Well... I don't really know the best practices with respect to such a
problem but it doesn't currently sound great to me to have the font
hard-coded into SIP Communicator. It's not that much different but I
might prefer having a list of well-known fonts defined in the
language/translation file itself which SIP Communicator could try to set
(preferably, if it first determines that the current font doesn't have
the necessary glyphs).

I found a better way (attached). here I get the fonts installed in the
system and iterate through them, and select the first font that can
display both Sinhala and English glyphs, and this loop will run only
if language is set to Sinhala, of course
WDYT?

Thanks and Regards,
Amila

si2.patch (4.75 KB)

路路路

On Mon, Nov 8, 2010 at 4:11 PM, Lyubomir Marinov <lubo@sip-communicator.org> wrote:

On Mon, 2010-11-08 at 05:12 +0530, Amila Manoj Silva wrote:


#4

The following taken from
http://weblogs.java.net/blog/mkarg/archive/2010/02/13/unicode鈩-write-once-read-nowhere
sounds to me to be related:

Font Linking
Submitted by skyewire on Tue, 2010-02-16 18:03.
Hi Markus,

I don't think you should be having this problem at all. Do you know
about Font Linking (aka Font Merging or Composite Fonts)? It is the
standard solution to this problem: when a graphics toolkit has to draw
a glyph that does not exist in the current font, it should
automatically use a fallback font that does contain the glyph. So the
only requirement is that there is at least 1 installed font on the
system that can display the glyph, and I think that's completely
reasonable.

Now things get a bit tricky with Swing. Font Linking works
out-of-the-box with all the logical fonts (e.g. the "Dialog" font or
the "Monospaced" font) or by any font created by a standard L&F like
the Windows L&F. Last I checked, Font Linking does NOT work if you
create your own non-logical font, e.g. you create a new Tahoma 11pt
Font object and assign that font to the text field. It also does NOT
work if you use a L&F that uses custom fonts in this way, e.g.
JGoodies Looks.

So the questions are (1) are you using a non-standard L&F or (2) are
you setting a custom font on the text field in question?

Finally, you can use some internal Sun classes to apply Font Linking
to any font (including custom created Font objects). See these posts
in the JGoodies Looks mailing list for more info and sample code:

https://looks.dev.java.net/servlets/SearchList?list=users&searchText=wes...

Cheers,
Daniel

There's also a related bug report at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6407157.

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi,

Yes, it is related.
So, java has 5 logical (composite) fonts, Sans Serif, Serif, Dialog,
Dialog Input and Monospace. Physical fonts are mapped to these fonts
by jre. The problem is jre does not map Sinhala fonts to those logical
fonts.

going through the discussion there, I came across to this,
Class c = Class.forName("sun.font.FontManager");
聽聽聽聽聽聽Method m = c.getDeclaredMethod("getCompositeFontUIResource",
聽聽聽聽聽聽聽聽new Class[] { Font.class });
聽聽聽聽聽聽newFont = (FontUIResource) m.invoke(null, myFont);

this creates a composite font, with 'myFont' as the primary font and
Dialog as the fall-back font. that means any glyphs that are not found
in myFont will be fetched from Dialog.
I tried this and it works.
Still, myFont needs to be specified. That means we still have to find
the correct font using the way I stated before (by iteratively
checking if fonts can render a Sinhala character), and the new
composite font should be set to uiDefaults as before. The advantage
here seems to be that the any character in java's logical fonts can be
rendered along with Sinhala glyphs.
However, if this method is used, there are still some issues with some
components. Ex: JEditorPane with html uses font specified in a css
style file rather than its font.

Better approach would be make jre map Sinhala fonts too, to those
logical fonts. Those mapping is done as specified in
fontconfig.properties file located in jre/lib directory. so I tried to
edit that,
as described in
http://download.oracle.com/javase/6/docs/technotes/guides/intl/fontconfig.html#names
CharacterSubsetName is needed to specify a font. there is a list of
predefined named stated for about 10 languages. It also states that
additional names should be defined to identify additional character
subsets. (Probably Unicode range). But I couldn't find the format to
define that anywhere.
Also, even if it's done, editing fontconfig file is considered as
modifying jre. I don't think it's suitable to do it for every
installation.

After that I came across this,
http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp#add-font

Just adding a font to jre/lib/font/fallback directory makes jre to
automatically add it as a fall-back font for logical fonts. whenever
there's is unrenderable character, it looks in fall-back font for
glyphs. I added a Sinhala font to that directory and everything worked
perfectly in sipcomm without any modification to code!
This seems to be the best method.

Is it possible to distribute a font with sipcomm and add it to jre's
fallback directory during installation?
I found 2 open source Sinhala fonts
lklug - http://www.lug.lk/fonts/lklug
freeSerif - https://savannah.gnu.org/projects/freefont/

Otherwise we'll have to use the previous method

I think this problem is related not just to Sinhala, also to other
languages that are not mapped to logical fonts

Regards,
Amila

路路路

On Tue, Nov 9, 2010 at 3:52 AM, Lyubomir Marinov <lubo@sip-communicator.org> wrote:

The following taken from
http://weblogs.java.net/blog/mkarg/archive/2010/02/13/unicode鈩-write-once-read-nowhere
sounds to me to be related:

Font Linking
Submitted by skyewire on Tue, 2010-02-16 18:03.
Hi Markus,

I don't think you should be having this problem at all. Do you know
about Font Linking (aka Font Merging or Composite Fonts)? It is the
standard solution to this problem: when a graphics toolkit has to draw
a glyph that does not exist in the current font, it should
automatically use a fallback font that does contain the glyph. So the
only requirement is that there is at least 1 installed font on the
system that can display the glyph, and I think that's completely
reasonable.

Now things get a bit tricky with Swing. Font Linking works
out-of-the-box with all the logical fonts (e.g. the "Dialog" font or
the "Monospaced" font) or by any font created by a standard L&F like
the Windows L&F. Last I checked, Font Linking does NOT work if you
create your own non-logical font, e.g. you create a new Tahoma 11pt
Font object and assign that font to the text field. It also does NOT
work if you use a L&F that uses custom fonts in this way, e.g.
JGoodies Looks.

So the questions are (1) are you using a non-standard L&F or (2) are
you setting a custom font on the text field in question?

Finally, you can use some internal Sun classes to apply Font Linking
to any font (including custom created Font objects). See these posts
in the JGoodies Looks mailing list for more info and sample code:

https://looks.dev.java.net/servlets/SearchList?list=users&searchText=wes...

Cheers,
Daniel

There's also a related bug report at
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6407157.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Amila Manoj

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net