Hello everyone,
I have been experiencing alot of issues with text in labels where an RTL language and a LTR language are mixed.
The alignment of the text (And the way it is treated) depends on the first word in the line. Depending on whether it is an LTR or RTL oriented word, the rest of the line is aligned accordingly (There is a whole Bi-directional (Bidi) algorithm to it, its a known solution to the probelm).
That behaviour confuses the users.
In JDK 1.4.2 Java supplies a way (Albeit annoying) to explicitly declare that a TextLayout should be aligned explicitly to either LTR or RTL.
The only way I could change the way TextLayouts were created (Add the attributes param to the constructor) was to try and inject code into TextUtilities, but that is not possible (It would have been final if it didn't have members, I know).
Im asking if there you would consider extending the TextUtilities framework to include such explicit support in TextLayout's attributes (Atleast) so we'll have some sort of hooking to set such attributes in a complete manner to the Graph's creation.
Thanks in advanced,
Morwen.
TextUtilities and explicit RTL / LTR presentation
-
- JFreeChart Project Leader
- Posts: 11734
- Joined: Fri Mar 14, 2003 10:29 am
- antibot: No, of course not.
- Contact:
I think this will be quite hard to fix for the 1.0.x versions of JFreeChart, which still need to run using just the Java 1.3.1 APIs. I would like to try to get a better understanding of this issue so that I can make sure that future versions of JFreeChart handle it better. I still know relatively little about mixing RTL and LTR text, so any references you can suggest would be helpful.
David Gilbert
JFreeChart Project Leader
Read my blog
Support JFree via the Github sponsorship program
JFreeChart Project Leader


Hey David,
In addition to supplying the reference information I came about during my "fix" to the problem, if I were to create a patch which would be backwards-compatible to Java 1.3 (By checking for the version as it does currently in a few places), and making the feature available (Again, being backward compatible), would patches for this be accepted / reviewed?
If so, I'll be more than happy to make them.
Morwen.
In addition to supplying the reference information I came about during my "fix" to the problem, if I were to create a patch which would be backwards-compatible to Java 1.3 (By checking for the version as it does currently in a few places), and making the feature available (Again, being backward compatible), would patches for this be accepted / reviewed?
If so, I'll be more than happy to make them.
Morwen.
Hey David,
Currently the implementation of Jfreechart works most of the time
by "guessing" the directionality of the text based on the first letter.
I would like to see an ability to explicitly set given text to be right to left or vice versa.
I looked at the code, and the core change seems to be in:
TextUtilities in the method drawRotatedString
where we create a TextLayout object.
The TextLayout object accepts an optinal Map of TextAttribute
one of which may be TextAttribute.RUN_DIRECTION which may be
set in order to override the default behaviour (guess according to first letter).
The main problem is how to pass the parameter deep into JfreeChart
since we would like the ability to contorl directionality of text in various parts of the graph (labels,axis lables,tooltips, etc...), I considered two different approaches:
1) The naive approach invloves adding an optional parameter to many classes all over.
2) The shortcut involves using java.awt.Font to carry the message, as we already have the ability to set a different font to various parts of the graph and the font gets carried in all the way to TextUtilities.drawRotatedString.
I propose adding 2 interfaces: RTLFont and LTRFont, and in TextUtilities we will check if the Font implements one of these interfaces and add the RUN_DIRECTION parameter accordingly.
This will allow anyone to set the directionality of any part (even if they use an extention of java.awt.Font, not that I know of any reason to do this).
Thanks,
Morwen.
Currently the implementation of Jfreechart works most of the time
by "guessing" the directionality of the text based on the first letter.
I would like to see an ability to explicitly set given text to be right to left or vice versa.
I looked at the code, and the core change seems to be in:
TextUtilities in the method drawRotatedString
where we create a TextLayout object.
The TextLayout object accepts an optinal Map of TextAttribute
one of which may be TextAttribute.RUN_DIRECTION which may be
set in order to override the default behaviour (guess according to first letter).
The main problem is how to pass the parameter deep into JfreeChart
since we would like the ability to contorl directionality of text in various parts of the graph (labels,axis lables,tooltips, etc...), I considered two different approaches:
1) The naive approach invloves adding an optional parameter to many classes all over.
2) The shortcut involves using java.awt.Font to carry the message, as we already have the ability to set a different font to various parts of the graph and the font gets carried in all the way to TextUtilities.drawRotatedString.
I propose adding 2 interfaces: RTLFont and LTRFont, and in TextUtilities we will check if the Font implements one of these interfaces and add the RUN_DIRECTION parameter accordingly.
This will allow anyone to set the directionality of any part (even if they use an extention of java.awt.Font, not that I know of any reason to do this).
Thanks,
Morwen.
Hi,
using the Map of font-attributes is a good idea, but you dont have to use an Interface for that tweak. java.awt.Font has a constructor that accepts a Attribute-Map, and existing fonts can be derived to contain additional attributes.
@see Font#deriveFont(Map)
@see Font(Map)
You can derive your own attribute type, which then gets carried by the font. This is much easier than subclassing the font. This way, the implementation just has to check whether that particiular attribute is set, which then carries the Text-Attribute map as bulk value.
Have fun,
said Thomas
PS: Anyone who loads its own fonts-files usually receives an subclass of java.awt.Font. Using your own (application specific) fonts is often considered mandatory for high-quality printing.
using the Map of font-attributes is a good idea, but you dont have to use an Interface for that tweak. java.awt.Font has a constructor that accepts a Attribute-Map, and existing fonts can be derived to contain additional attributes.
@see Font#deriveFont(Map)
@see Font(Map)
You can derive your own attribute type, which then gets carried by the font. This is much easier than subclassing the font. This way, the implementation just has to check whether that particiular attribute is set, which then carries the Text-Attribute map as bulk value.
Have fun,
said Thomas
PS: Anyone who loads its own fonts-files usually receives an subclass of java.awt.Font. Using your own (application specific) fonts is often considered mandatory for high-quality printing.