Phil Race wrote:
Peter B. West wrote:
On Thu, 2006-06-15 at 17:24 +0100, Peter B. West wrote:
David,
Thanks for the response. I did look at LineBreakMeasurer, but in looks
as though the most powerful layout mechanism available is
Font.layoutGlyphVector. The docs say:
its not 'the most powerful'
"Returns a new GlyphVector object, performing full layout of the text if
possible. Full layout is required for complex text, such as Arabic or
Hindi."
It was that flexibility and power I was after. You have to do your own
Bidi which is a complicationg factor, but you get everything else, as
far as I can tell.
as you say it doesn't do Bidi and as David Kavanagh as trying to remember
AttributedString can handle text in multiple fonts (ie suppose you wnat
to style
one word in italics,) and with various stylings (have a word in red or
have it underlined)
AttributedString together with LineBreakMeasurer can handle that. It
will also handle Bidi
I'm using AttributedString as well, with subclasses of
AttributedCharacterIterator.Attribute for hyphenation markers and
character replacement graphics.
Full layout is an expensive process, so I would like to be able to work
off the GlyphVectors I have, if possible, to retrieve the broken lines.
you get most of the same benefit by caching the TextLayout objects that
LineBreakMeasurer
returns. Mostly apps should avoid GlyphVector unless you know you can
make some
simplifying assumptions about the text you will be handling.
So my feeling is you are digging into the guts rather than using the
higher level APIs
that have been designed for this sort of purpose.
I am not sure if you are also wanting to somehow break at hyphens or
have some
special behaviour associated with them. LineBreakMeasurer could also do
that
by telling calling the overload of LBM.nextLayout() that takes offSetLimit.
-phil.
Thanks for the input Phil. Now I'm more confused. I would love to use
LineBreakMeasurer. However, the best conclusion I could draw from the
documentation available was that it made a few simplifying assumptions
itself.
What does layoutGlyphVector do, if anything, that LineBreakMeasurer and
TextLayout do not. I'm assuming that the full layout of complex scripts,
including kerning, ligatures and context-dependent text shaping are
being performed in both. Is this the case?
If so, that's great. However, "LineBreakMeasurer implements the most
commonly used line-breaking policy: Every word that fits within the
wrapping width is placed on the line. If the first word does not fit,
then all of the characters that fit within the wrapping width are placed
on the line. At least one character is placed on each line."
This is the fly in the ointment. It seems to me that this limitation is
recognized as being serious in the Java2D "white paper". The exit path
offered is GlyphVectors. They are adjustable, where TextLayouts are
immutable.
I am performing paragraph layout with complex Knuth/Plass style
line-breaking and adjustment. Given this requirement, and the
requirement to support complex scripts, how do you suggest I go about this?
Peter
--
Peter B. West <http://cv.pbw.id.au/>
Folio <http://defoe.sourceforge.net/folio/>
===========================================================================
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".
