This page is an archive of the previous Group's wiki from http://www.w3.org/Graphics/SVG/Group/wiki.

Text-wrapping in Tiny 1.2

SVG 1.2 Tiny has a textArea element that allows text-wrapping.

SVG 1.1 already has a mechanism for text breaks (the tspan element) but requires that the author choose the position of the break in advance.

For SVG which is generated automatically, or includes strings of unknown length drawn from a database, or where the font to be used is not known, it is desirable to allow the line break positions to be calculated at display time. A common use case is text callouts on a diagram, which must fit into a rectangle of a given size and where part numbers etc. are drawn from a database.

Maciej Stachowiak registered a Formal Objection on 22 March 2006 regarding the provision of a text wrapping facility.

Discussion

Whether the current SVG textArea is the right way of dealing with the text wrapping use cases

SVG Tiny 1.2 SVGT12-392
The official response to the formal objections.
Resolution: The text-wrapping facility is useful and should be kept.
Rationale: A large number of content authors and implementors have stated that they want this feature.
Rationale: Some Tiny implementations don't want to implement the CSS or HTML models just to get text wrapping (eg. on mobile devices)
Rationale: Future implementations of SVG will certainly want to do advanced text wrapping - for example, wrapping text to shapes, something that is not being planned by other specifications (though XSL-FO and SVG are planning a joint release for text wrapping to shapes).

Suitability of SVG textArea for compound documents

Maciej says that SVG text isn't suited for HTML/SVG compound docs.
Maciej dislikes the interaction in XHTML+SVG where SVG text and XHTML text are marked up differently.
Resolution: TODO.

Difficulty of creating an SVG/CSS text layout engine

Andrew Emmons says that textArea is lightweight, and that in Full will allow wrapping in shapes and other features.
Maciej and Peter Sorotokin have a detailed discussion about how difficult it is to code a joint SVG/CSS text layout engine:
* Peter Sorotokin says he is able to build an SVG/CSS text layout engine, and that this isn't unusually difficult. He points out that there are difficulties integrating XSL:FO with CSS that are more fundamental.
* Maciej says he thinks a combined engine is still complicated.
* Peter Sorotokin says it's not that much harder than CSS by itself, and that SVG text layout is much simpler and takes less code. Integrating CSS text layout with any other text layout would be as complicated.
Resolution: Integrating CSS text layout with any other text layout would be as complicated; and it is still worthwhile.

SVG text is incompatible with semantic markup

Maciej says that that SVG text is incompatible with semantic markup - "the W3C's big project is the Semantic Web, and yet SVG will encourage authors to create significant chunks of text with purely presentational markup"
Resolution: TODO