Community
Participate
Working Groups
Build Identifier: M20110210-1200 By every other word written in arabic letters, SWT ignores the fallback font I set over the style ranges to display the not ASCII-characters in a styled text, when the font used by widget doesn't contain the arabic glyphs. Reproducible: Always
Created attachment 192591 [details] Snippet
Created attachment 192594 [details] Picture A snapshot of application, which consists of two StyledText-Widgets with fonts, whose names and properties are shown in the labels above them.
The behaviour occurs on Windows XP too, wenn LEFT_TO_RIGHT style is set.
When the font info lines are removed in the snippet, the behaviour is fixed. For me it seems to be setFont() that corrupts the internal state in any way(?) It also seems to be not only a Windows 7 problem: on my WinXP machine it's also currupt. I'm curious how it behaves on Linux.
I do not have this fonts/UnicodeBMPFallback51.ttf font, but it works for me using a different font.
Created attachment 192656 [details] UnicodeBMPFallback51 Please find attached the missing font.
works for me on Windows 7 running SWT from HEAD: http://www.eclipse.org/swt/cvs.php
Created attachment 192701 [details] SWT 3.7M6; incorrect behaviour verified @ Felipe: for me - beeing beyond a firewall - it's a little difficult to use the CVS. But I tried it with the latest 3.7 Stream Stable Build (see the shell text in the attached snapshot). On my XP machine it doesn't work, when I type in an "a" and a space.. alternating. @Irina: thank you for the font. I tried something similar some time ago.. and failed ;(
For the same reason I cannot use the SWT out of CVS too. So I've changed to the SWT 3.7M6 and it still doesn't work. While debugging, I can see that in the method computeRuns() the TextLayout uses a fallback font to shape the arabic letters and takes no notice of the font I set in its style range, if the previous whitespace couldn't be shaped.
I can reproduce the problem, working on the fix.
Simplified test case: public static void main(String[] args) { Shell shell = new Shell(display, SWT.SHELL_TRIM | SWT.RIGHT_TO_LEFT); final Font f1 = new Font(display, "Verdana", 14, SWT.NORMAL); display.loadFont("JavaCode\\UnicodeBMPFallback51.ttf"); FontData[] fd = display.getFontList("Unicode BMP Fallback SIL", true); System.out.println("loaded " + fd[0]); fd[0].setStyle(SWT.BOLD); fd[0].setHeight(13); final Font f2 = new Font(display, fd[0]); shell.addListener(SWT.Paint, new Listener() { public void handleEvent(Event e) { TextLayout layout = new TextLayout(display); layout.setOrientation(e.gc.getStyle()); layout.setFont(f1); layout.setText(" \u0634"); TextStyle style = new TextStyle(); style.font = f2; layout.setStyle(style, 1, 1); layout.draw(e.gc, 10, 10); layout.dispose(); } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } display.dispose(); }
Created attachment 192942 [details] patch this bug was introduced by the fix for Bug 272075 & bug 239556
Fixed in HEAD Note the behaviour is different when Verdana and Tahoma are used. Verdana can't be used to draw whitespaces in Arabic, so the fallback font of the next run is used.
Created attachment 193015 [details] Test with Nightly Build N20110411-2000 Using Nightly Build N20110411-2000 of SWT I see, that the font the application sets using style ranges to draw invalid letters is used by SWT to draw the whitespaces too. Is it impossible to use the system font as a fallback for the letters, that cannot be shaped by the font of the widget and have no alternative font set using a style range? I mean, the font the application sets using style ranges for the invalid letters is not intended to be a fallback font for the other letters. Apart from that, could you please explain to me, why Verdana can't be used to draw whitespaces in Arabic?
Reopend because of the explanation in my previous comment.
(In reply to comment #14) > Is it impossible to use the system font as a fallback for the letters, that > cannot be shaped by the font of the widget and have no alternative font set > using a style range? I mean, the font the application sets using style ranges > for the invalid letters is not intended to be a fallback font for the other > letters. the code that finds the fallback font is complex. It tries different methods to find a good font. In this case it detects that the current run is the same script as the surrondings runs and uses the font from them. It is the right thing to do. > Apart from that, could you please explain to me, why Verdana can't be used to > draw whitespaces in Arabic? You need to ask Microsoft that, but the simple answer is: Verdana does not support Arabic. Note that altough whitespace does not have a glyph it still has metrics (width). The width of a whitespace in a Japanese font is much bigger than the width of a whitespace in an English font. You can fix this problem on your code by setting the font in whitepaces too. closing.
@Felipe: > the code that finds the fallback font is complex. It tries different methods > to find a good font. In this case it detects that the current run is the same > script as the surrondings runs and uses the font from them. I agree with you, the whole topic is highly complex and the implementation pretty tricky. But I do not agree with your statement that the current run (whitespace, ascii 0x20) is the same script as the surrounding runs (arabic characters). As I have seen, the SWT implementation for Linux does it a little bit different - I do not mean the underlying font rendering engine but the SWT code itself. > It is the right thing to do. At least, there is an explicit directive to use StyleRanges for some parts of the string and not to do it for the others! IMO here, in the fallback case the whitespace (characters in general) should be handled separated from the surrounding StyleRanges and tried be drawn with the font that is set for the widget.. and if that attempt fails, to use the regular system fallback font. > You need to ask Microsoft that, but the simple answer is: Verdana does not > support Arabic. Note that altough whitespace does not have a glyph it still has > metrics (width). The width of a whitespace in a Japanese font is much bigger > than the width of a whitespace in an English font. Do you mean, it's "just" the existence of the arabic page within the font that is responsible for the ability of printing the other glyphs? And: is it still the same whitespace codepoint in English and Japanese texts? @Irina: Is it possible for you re-open again and to provide a patch?
