An internal class - TextLine - used by TextLayout and TextMeasurer is trying to compensate for italic overhang to the right that if ignored might mean visually text did not fit into the space it claimed it would occupy. It only needs to pad the rightmost character in the line this way. However if you, or TextMeasurer, starts to use these values to *position* subsequent text then that might well cause the effect you are seeing. TextMeasurer.getAdvanceBetween() I think should be logical advance but I'd need to think about it. The calculation that's causing your problem is roughly and usually getAscent() * font.getItalicAngle().
That is what is getting added on to the advance. You could try compensating by that amount and see if it helps. -phil. Peter B. West wrote:
I wrote a couple of small test programs to look at the behaviour of TextMeasurer, especially in situations where the text is in mixed fonts. The fonts I used for the test are from the Luxi font set, available with X distributions. The first one measures "aaaa" in an italic and in a regular font, looking at the total advance, the increment of the total advance, and the advance of the character itself. Results follow. Ita i 1 adv_to_i 6.364563 increment 6.364563 adv_i_only 6.364563 Ita i 2 adv_to_i 10.80304 increment 4.4384766 adv_i_only 6.364563 Ita i 3 adv_to_i 15.241516 increment 4.4384766 adv_i_only 6.364563 Ita i 4 adv_to_i 19.679993 increment 4.4384766 adv_i_only 6.364563 Reg i 1 adv_0_to_i 4.4384766 increment 4.4384766 adv_i_only 4.4384766 Reg i 2 adv_0_to_i 8.876953 increment 4.4384766 adv_i_only 4.4384766 Reg i 3 adv_0_to_i 13.31543 increment 4.4384766 adv_i_only 4.4384766 Reg i 4 adv_0_to_i 17.753906 increment 4.4384766 adv_i_only 4.4384766 There are a couple of interesting things here. Firstly, the advance of single characters of the italic fonts is greater than the increment of characters other than the first, presumably representing an inherent kerning effect of italic fonts. The increment of subsequent characters is the same as the advance of the corresponding regular character, as shown in the lower group of the first set, above. More interesting is the actual measurement. The ratio of the advance of the italic character to the advance of its regular peer is 1.43395213! When I examine the individual characters from the two fonts with FontForge, I get these values: regular 'a' width 909 LBearing 75 RBearing 5 italic 'a' width 909 LBearing 123 RBearing -48 The largest difference I can manufacture from those figures is 957/904, or 1.05862831, which is not in the same ball-park as the TextMeasurer figures. The second test repeats the first, with one change. In the first set, the two inner characters are in the italic font, while the two outermost are in a regular font. Mix i 1 adv_to_i 4.4384766 increment 4.4384766 adv_i_only 4.4384766 Mix i 2 adv_to_i 11.212321 increment 6.7738447 adv_i_only 6.364563 Mix i 3 adv_to_i 15.650798 increment 4.4384766 adv_i_only 6.364563 Mix i 4 adv_to_i 20.089275 increment 4.4384775 adv_i_only 4.4384766 Reg i 1 adv_0_to_i 4.4384766 increment 4.4384766 adv_i_only 4.4384766 Reg i 2 adv_0_to_i 8.876953 increment 4.4384766 adv_i_only 4.4384766 Reg i 3 adv_0_to_i 13.31543 increment 4.4384766 adv_i_only 4.4384766 Reg i 4 adv_0_to_i 17.753906 increment 4.4384766 adv_i_only 4.4384766 Similar observations hold. However, the increment value for the first italic character following a regular character (the second line of the upper group) is greater than the advance value for the isolated character, and greater than any value for the italic only group (upper group of the first set of observations.) My interest is that I am using TextMeasurer to perform paragraph line breaking in situations where I may have mixed-font text. I measure the complete paragraph, but, in order to perform the line-breaking algorithm, I need also to know the measurement of individual fragments of text. Fragments are the pieces between possible break points, which include spaces and potential hyphenation points. The effect that I'm seeing (and I haven't yet confirmed that this is entirely a TextMeasurer problem) is illustrated in the attached measurement.png. The fragments of the text are placed at offsets from one another as calculated by their measurements. In the png, the measurement of a fragment is determined by asking a TextMeasurer, defined across the whole paragraph, for an advance from the beginning of the fragment to the beginning of the following fragment. This works beautifully for the regular text, but the italicised text is, as you can see, being measured larger than it actually is. Further, the right margin of the line is extended. This indicates that the measurement of the entire line differed from the sum of the individual measurements. I attempted to compensate for this by measuring fragments as the difference between the total advance from the beginning of the text to the beginning of the following fragment, and the total advance from the beginning of the text to the beginning of the fragment. This seems to overcome the margin drift to the right, but does not solve the problem, as illustrated in measurement2.png. My reason or switching from using GlyphVectors to using TextMeasurers was to gain performance improvements. The logic is also considerably simpler. However, GlyphVector measurement works, whilst taking measurement differentials from the beginning of the text leads to quadratic increases in time with paragraph length. Even with the more unreliable mode of measuring from the beginning to the end of a fragment, the time taken to perform the layout increases more steeply with increasing paragraph size than the corresponding GlyphVector method. Peter------
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".