Skip to main content
rstawarz
Participant
April 14, 2009
Question

Bug/Issue with Text Layout

  • April 14, 2009
  • 1 reply
  • 718 views

Hello,

I think I may have uncovered a bug in the Text Layout Framework.  I am trying to control which pieces of text flow to which container.  In doing so I have setup some simple samples that illustrate how I *think* the composition sizing and container/container controllers work.  It's entirely possible I don't understand how the framework should work, but I think the sizes being computed after CompositionCompletionEvent.COMPOSITION_COMPLETE are not accurate and there is a bug when measuring text.

Here is the general concept of these samples:

  1. Create a textflow
  2. Add text into a paragraph/span into the flow
  3. create a new container and container controller and add it to the display and flow respectively
  4. Ask the flow composer to compose the given text blocks using "textFlow.flowComposer.compose()"
  5. the event is used to size the composition to the exact size so that no other text will fit in it
  6. then repeat steps 2-5 as needed for additional text.

As you will see in these two samples, the flow/sizes aren't giving the desired results.

Please help me understand what is going on.

Thanks!

-Ryan

I've built this against the "Version 4.0.0 build 4904" and "Version 4.0.0 build 5952" builds.

Here are two screenshots of the 'unexpected' results as well:

Expected: The example below should have had each red box filled with 'T', 'h', and 'e' respectively - each red box is it's own 'container'.

Actual:  The flow composer skipped the middle box, and put the 'h' into the last box despite using the compositions height/width.

Expected: The above should have had each red box filled with 'Mission', and 'to Mars', respectively - each red box is it's own 'container'.

Actual: The flow composer put the 'Miss' into the first box and flowed 'ion' into the last box despite using the using the compositions height/width.Actual

This topic has been closed for replies.

1 reply

Participating Frequently
April 15, 2009

Ryan,

What seems to be happening is that when composing within NaN x NaN, the composer measures the 'h' as if it will form the first line of a container. But when composing within the measured bounds, the composer tries to fit the 'h' as if it will form an interior line.

I'm not sure why this is happening, but it makes a difference as explained next. In the former case, its height is governed by the firstBaselineOffset format, whereas in the latter case, its height is governed by the lineHeight format. If the two are the same, things work fine. For example, try setting textFlow.firstBaselineOffset = BaselineOffset.LINE_HEIGHT. This may or may not be a suitable workaround for your usage.

-Abhishek

(Adobe Systems Inc.)