RE: [SVGMobile12] Text in an area

Hi, Cameron-

Thanks for your detailed comment and proposed fixes. Proposed fixes make us very happy. *

Cameron McCormack wrote:
| 
| In section 10.11.5, the sentence
| 
|   Below is a recommended algorithm for implementing 'display-align'.
| 
| should probably read
| 
|   Below is a recommended algorithm for implementing
|   display-align="center".

You're correct. I've fixed this.


| Also, this algorithm seems to have been made more general so 
| that it can handle flowing text into non-rectangular shapes, 

Yes, the intent is to lift the restriction on rectangle-only for SVG Full. The XSL WG has expressed interest in text-wrapping to arbitrary shapes in XSL2, and we will be coordinating closely with them to make sure that we have compatibility.

 
| but there are a couple
| of problems with the algorithm as it stands.
| 
| For example, this document illustrates how some text may flow into a
| non-rectangular shape:
| 
<snip />
|   ▪ Loop infinitely…
| 
| Perhaps just having line 7 of the algorithm be
| 
|   7. If C is greater than or equal to D then layout terminates.
|
| so that improvements are always made. 

You're right, that seems to have been overlooked. I've corrected it. It would be good to know if this is implemented in Batik. Have you done so, or are you planning to?


| However I’m not convinced that
| this algorithm won’t result in being stuck in a local minimum 
| for C and
| not find the best layout.  (But perhaps that is not the aim.)

We agree that it may get stuck in a local minima, but the effort in most systems for finding best possible layout is disproportionate to the effect. For instance, TeX has a much deeper and more complex algorithm that takes into account content pages out, but is still imperfect. As you see above, also, Outlook is atrocious at breaking text for replies. It's a hard problem, and we erred on the side of good-enough-fit.

To acknowledge this, and to give way for implementations to have a better algorithm (although not a worse one), I have changed the introduction to the algorithm to read, "Implementations relying on a different algorithm should exhibit the same behavior as this algorithm does. This algorithm provides a minimum-quality bound on such features as shape-fitting, line-breaking, and optimal wordcount included." 


| Also, the algorithm does not say what to do if some words weren’t
| positioned because they fell off the edge of the end of the shape.
| Should A = 0 in this case?

I have clarified this in the spec:

 "Note that any text which does not fit into the textArea is not laid out, and thus does not affect the calculations in steps 3 and 4."


If this does not satisfy your concern, please respond within 2 weeks with further clarification.

Thanks-
Doug, on behalf of the SVG WG


* Though not as happy a carton of ice cream. Proposed fixes that include ice cream will receive priority in all future dealings.

Received on Thursday, 8 June 2006 00:45:55 UTC