Home pageFind It!Contact PJAPJA documentation

PJA

 PJA Toolkit forum

This forum is dedicated to PJA Toolkit.
You may read freely the messages it contents. If you want to write a message or answer to a subject, subscribe to it first.

Subjects Recent messages Login Subscribe

Messages of subject PJAGraphics drawString doesn't display all Unicode characters

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 15, 2004 at 7:52 PM
Hi,

History mentions :
Version 2.5 06/30/2003

And the source files have the same date.

So... what ?

Cheers,

p.b.

[Subject modified by Moderator]

Manu

Location : Paris / France
Member since : Apr 29, 2003
Messages : 394
 Apr 19, 2004 at 11:46 PM
Ok course PJA Toolkit is alive... Aren't there enough messages in this forum to prove it ?
From the feedback eTeks got for PJA Toolkit 2.5 Beta, it seems to work correctly with Java 1.4.
eTeks will check if it works with the current Beta release of Java 1.5 and then release it.
In the meantime, don't worry of the "Beta" name...
---
Manu (moderator/modérateur)

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 19, 2004 at 11:46 PM
Hi,

Good news :-)

So, my question will concern (Unicode) Text rendering. It appears, after a quick inspection of the code, that the PJAGraphics.drawString method tries to render a string where :

1) characters flow from left to right
2) *one* character is associated with *one* Glyph

Am I wrong ?

More on this topic soon.

Cheers,

p.b.

Manu

Location : Paris / France
Member since : Apr 29, 2003
Messages : 394
 Apr 19, 2004 at 11:46 PM
> So, my question will concern (Unicode) Text rendering. It appears, after a quick inspection of the code, that the PJAGraphics.drawString method tries to render a string where :
> 1) characters flow from left to right
> 2) *one* character is associated with *one* Glyph
> Am I wrong ?

PJAGraphics isn't used by default from Java 1.2, unless you explicitly create a PJAImage instance or if the com.eteks.awt.nojava2d system property is set to true (please read also http://www.eteks.com/pja/en/forum/viewSubject.jsp?subjectId=90 and http://forum.java.sun.com/thread.jsp?forum=5&thread=444149 for more information about special cases). All Java2D operations required for text rendering and drawing are done with classes of the standard libraries.
---
Manu (moderator/modérateur)

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 19, 2004 at 11:46 PM
Hi,

> PJAGraphics isn't used by default from Java 1.2,

I may be missing something then.

Trying to trace PJANativeToolkitComparison within NetBeans 3.6 running on a 1.4.1 JDK.

I've set : -Djava.awt.fonts=C:\\myfont
C:\myfont contains a captured font file : Arabic Transparent.pjaf

In ToolkitDemo.GraphicsTextDrawer.paint, I've made a little quick and dirty change :

text += fontSize [i];
//Added this line to test arabic
text = "áößö ÇáäøóÇÓö ";

Since I only get "?" characters, I've traced the code exectution :

gc.drawString (text, 5, y + metrics.getAscent () + metrics.getLeading ());

Gets into drawString in... PJAGraphics !

What am I missing here ? How PJAGraphics can be used in my "basic" context ?

Cheers,

p.b.







unless you explicitly create a PJAImage instance or if the com.eteks.awt.nojava2d system property is set to true (please read also http://www.eteks.com/pja/en/forum/viewSubject.jsp?subjectId=90 and http://forum.java.sun.com/thread.jsp?forum=5&thread=444149 for more information about special cases). All Java2D operations required for text rendering and drawing are done with classes of the standard libraries.

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 19, 2004 at 11:46 PM
Hi again,

> //Added this line to test arabic
> text = "áößö ÇáäøóÇÓö ";

Of course, it is real arabic ;-)

> Since I only get "?" characters

That was in fact a Netbeans bug. I now get the following execption :

java.lang.IllegalArgumentException: Character ? as no image.
at com.eteks.awt.PJAFontData.checkCharacterRange(PJAFontData.java:387)
at com.eteks.awt.PJAFontData.getCharPixelsWidth(PJAFontData.java:448)
at com.eteks.awt.PJAGraphics.drawString(PJAGraphics.java:1889)
at ToolkitDemo$GraphicsTextDrawer.paint(ToolkitDemo.java:348)
at PJANativeToolkitComparison.main(PJANativeToolkitComparison.java:94)

It looks like there is a problem in mapping a (Unicode) char to an character index in the pjaf file.

Cheers,

p.b.

Manu

Location : Paris / France
Member since : Apr 29, 2003
Messages : 394
 Apr 19, 2004 at 11:46 PM
> It looks like there is a problem in mapping a (Unicode) char to an character index in the pjaf file.

By default com.eteks.tools.fontcapture.PJAFontCapture application captures all characters between Unicode 0 and 255. If you want to get more characters you may change these numbers in PJAFontCapture source in the call new PJAFontData (font, 0, 255)
Remember .pjaf font files are useless on a normal server.
PJANativeToolkitComparison is just a test program that compares AWT Toolkit to PJA Toolkit Graphics methods.
---
Manu (moderator/modérateur)

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 20, 2004 at 12:08 AM
Hi,

> By default com.eteks.tools.fontcapture.PJAFontCapture application captures all characters between Unicode 0 and 255.

Of course I want them ;-)

>If you want to get more characters you may change these numbers in PJAFontCapture

I will give it a try tomorrow : I hope it is as simple as that :-) because I'd like to drive tests on *huge* Unicode fonts in order to evaluate how heavy would be a real Unicode development (à la Pango for example).

> Remember .pjaf font files are useless on a normal server.

That's well understood.

> PJANativeToolkitComparison is just a test program that compares AWT Toolkit to PJA Toolkit Graphics methods.

This one is also well understood.

A few quick thoughts :

First, does it make sense to make a "comparison" if the PJA Toolkit can't deal with Unicode... whose native support by Java is one of the great advantages provided by this language ?

Second, regarding this comparison, does it make sense to compare a user selected font with the DIALOG Font that seems to be choosen for "native" text rendering ?

Last but not least, I think that the PJA Toolkit could be of a great help for pure Java programs like GNU classpath (where it could be used beside GTK+ if the graphic classes were given more abstraction) and - why not ? - JNode.

What's your mind ?

Good night,

p.b.



brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 20, 2004 at 9:36 AM
Hi,

>>If you want to get more characters you may change these numbers in PJAFontCapture
>
> I will give it a try tomorrow :

OK. Changed this line in PJAFontCapture :

PJAFontData fontData = new PJAFontData (font, 0, 255);

to

PJAFontData fontData = new PJAFontData (font, 0, 65535);

Increased memory and laucnhed the app with the following arguments :
Cyberbit.ttf 14 Cyberbit.pjaf

I get a 1.54 Mb file.

>I hope it is as simple as that :-)

It looks like :-) Well... in some way.

With a vocalized arabic content for the "text" variable, PJADemo creates a PJADemoTextDrawer.gif file which displays :

1) arabic characters :-)
2) from left to right :-(
3) unligatured :-(
4) without the wowels :-(

Points 2 and 3 can be considered as normal because the current algorithm considers scripts flowing from left to right where characters have a 1:1 relationship with Glyhs. In arabic, it is more complicated than this.

Point 4 is strange and needs further investigation. I doubt however that it is a problem with the font.

Cheers,

p.b.

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 Apr 20, 2004 at 10:27 AM
Hi,

> Point 4 is strange and needs further investigation. I doubt however that it is a problem with the font.

I think I've got it.

Placed some breakpoint on the first iteration (PJAGraphics.fontSize = 9). It should be the same for further iterations :

My first character is a consonant and is "well" processed.

My second character is a vowel. In arabic, vowels can be considered in the same way as french diacritics are : they are above (like accents, tréma...) or under (like a cédille) a letter.

In PJAGraphics.drawString(), I get :

char currentChar = str.charAt (i) = [my vowel char] : OK.
int charWidth = fontData.getCharWidth (currentChar) = 0 : this is the point.
int totalCharWidth = fontData.getCharPixelsWidth (currentChar) = 5
int leftOffsetAtBaseline = fontData.getCharOffsetAtBaseline (currentChar) = 2

Given that charWidth == 0, the vowels are not rendered because :

if (charWidth > 0)
{
[render]
}

// Advance starting x-coord for next character
x0 += charWidth;

So, there is actually no problem with the font itself :-)

totalCharWidth's value (5) seems to be correct for a fontSize of 9 as well as leftOffsetAtBaseline's value (2).

Furthermore, charWidth's value (0) is also semantically correct because, as said above, a vowel has no width in itself.

An ugly compromise, IMHO yet better than the actual behaviour that purely discards the vowels, would be to display the vowels *after* the consonnants even though it is an incorrect behaviour.

That's how Mozilla works although I consider this behaviour as being a bug :

http://bugzilla.mozilla.org/show_bug.cgi?id=180112

See screenshots provided by Mozilla users that demonstate the problem.

Is this sligth (?) refactoring possible ?

Cheers,

p.b.

Manu

Location : Paris / France
Member since : Apr 29, 2003
Messages : 394
 May 4, 2004 at 10:30 AM
Thank you for your investigation.
I agree that vowels should be displayed correctly but if PJAGraphics is corrected, it should also consider the right to left way of writing. Is there an easy way to determine in Java the way of writing ?
---
Manu (moderator/modérateur)

brihaye

Location : Rennes / France
Member since : Apr 15, 2004
Messages : 9
 May 5, 2004 at 12:02 PM
Hi,

> I agree that vowels should be displayed correctly but if PJAGraphics is corrected, it should also consider the right to left way of writing. Is there an easy way to determine in Java the way of writing ?

Well... let Unicode and the fonts do the stuff themselves :-)

Unless you want to rewrite code for font management, glyph substitution, glyph transformations, font scripting and the like, you should try to use "low level" Java classes. Unfortunately, Java doesn't let you do easily :-(

If you're interested in a quite robust text management (that should be sufficient for most of the scripts), have a look at this unfortunately nearly-defunct project :

http://www.brawer.ch/software/fonts/

The basic idea is to let the user (i.e. *not* the JVM/OS) manage (OpenType) font files.

PJA could get inspiration from this project because it shows how to get access to GlyphVectors although this is not its primary purpose.

Now, given the very interesting method GlyphVector.getGlyphOutline() (http://java.sun.com/j2se/1.4.2/docs/api/java/awt/font/GlyphVector.html#getGlyphOutline(int) )
you can get a java.awt.Shape for each Glyph.

Do remember that a single Character may be represented by several Glyphs (for example "é" could be represented by an "e" glyph with an "acute" Glyph above it) and that a single Glyph may represent several characters (same example : a font with a dedicated "é" Glyph can map a sequence "e" + "acute").

Once you have your Shapes, just let the PJAGraphics draw them ! IMHO, the later the rasterization the better text/font management. The PJA toolkit does... the contrary :-(

With such a code, .pjaf files - when applicable - would become useless.

What's your mind about this strategy ?

p.b.




Home pageFind It!ContactTop

© Copyrights 1997-2014 eTeks - All rights reserved

PJAPJA documentation