Re: Fwd: Two questions on flowed text in 1.2

Short answer:

See http://www.w3.org/TR/SVGMobile12/text.html#LineIncrementProperty

Long answer:

After lots of feedback from the community on SVG 1.2 (Full) and its flowing 
text features. There was considerable strong feedback that SVG 1.2 was 
going too far down the road towards defining a text layout facility which 
overlapped with HTML+CSS or XSL-FO. The SVG Working Group responded to this 
feedback by telling how text wrapping was among the top three requests from 
SVG content developers (perhaps even #1) and that SVG text wrapping had 
special requirements, such as text in an arbitrary shape, which is 
something that CSS and XSL-FO box models could not address.

The feedback caused the SVG Working Group to reconsider its approach to 
flowing text and as a result scaled back its flowing text features in a way 
that can be thought of as a simple extension of SVG 1.1's <text> element 
and which is conceptually parallel to SVG 1.1's <textPath> facility. 
Fundamentally, all SVG text features (<text>, <textPath>, and <textArea>) 
start from "single-line text". For Latin text, the single-line text starts 
on the left and goes forever to the right along a straight line that is 
axis-aligned with the current user coordinate system. <textPath> represents 
an extension whereby the single-line text is warped along an arbitrary 
path. The new <textArea> also represents an extension whereby single-line 
text is placed inside a shape and wraps when it comes to the boundary of 
the shape.

(For Tiny 1.2, <textArea> is restricted to a rectangle, but we assume that 
for Full 1.2 we will support arbitrary shapes.)

A key simplification for <textArea> versus the previous proposal (which 
used <flowRoot> or <flowText> in the previous drafts of SVG Full 1.2) is 
that we have removed the notion of block-level-like things such as 
"paragraphs". Instead, with <textArea>, you just have single-line text 
which can wrap to the next line. Our thinking is that if you really want a 
box model, then put HTML+CSS inside of an svg:foreignObject. (Not available 
today, but we expect the Compound Document Formats activity to enable that 
sometime in the not-too-distant future.)

In recognition that authors might want to control the distance between the 
baseline for line <n> and line <n+1>, we included a 'line-increment' 
property. We had a choice between subsetting and adapting 'line-height' or 
defining something much simpler and new, and felt it was better to define 
something new. The CSS 'line-height' property:

          line-height: normal | 
<http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-number><number> | 
<http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-length><length> | 
<http://www.w3.org/TR/REC-CSS2/syndata.html#value-def-percentage><percentage> 
| <http://www.w3.org/TR/REC-CSS2/cascade.html#value-def-inherit>inherit

has lots of options that SVG doesn't need and has rather complex rules 
about how to process those options. Since the differences between SVG's 
needs and the CSS definition were so large, we felt it was better to just 
define a new property that only applies to SVG's <textArea> element.

Jon Ferraiolo
Adobe Systems, Inc.
Member SVG Working Group

At 02:58 PM 4/15/2005, bulia byak wrote:

>1. How is one supposed to affect line spacing? If this is the
>line-height CSS property (the most logical approach), it needs to be
>mentioned in the specification. Maybe I missed something but I could
>not find it anywhere.
>
>2. I can understand why <flowPara>, <flowSpan> etc., unlike <text> or
><tspan>, do not have x/y attributes, but what about dx/dy/rotate?
>Being relative, they would not conflict with the flowed text layout
>and would be very useful in some situations. Users will likely find it
>hard to understand why they can add manual kerns to regular text but
>not flowed text, and implementors will appreciate more consistency
>between regular text and flowed text which can simplify
>implementation.