# SVG Text Issues — Sydney 2016

Last updated 5 February 2016

## Introduction

1. General philosophy: How does SVG text interact with CSS.
2. Baselines
3. Auto-wrapped text
1. Where does text wrapping start.
2. What is done with over-flowed text.
3. Doughnut holes.
4. Multiple shapes.

## General philosophy: How does SVG text interact with CSS?

### Background

The main goal is to provide a way where CSS (HTML) text layout can be easily adapted to SVG so that browser vendors do not need to implement two layout models while at the same time not making text layout overly complicated in stand-alone SVG renderers.

Basic HTML/CSS text:

	<p>Some text.</p>


Basic SVG text:

	<text x="100" y="100">Some text.</text>


The difference in these models is that the HTML/CSS text is positioned at rendering time based on other elements in the HTML. The SVG text is given a fixed position that is independent of other elements.

Things get a bit more complicated when wrapping text into a given shape:

Wrapped HTML/CSS text:

	<style>
.wrapper { shape-inside: xxx; ... }
.float-left { shape-outside: yyy; ... }
.float-right { shape-outside: zzz; ... }
</style>
<div id="wrapper">
<div id="float-left"/>
<div id="float-right"/>
<p>
Some text.
</p>
</div>


Wrapped SVG text:

	<style>
.my_text { shape-inside: xxx; shape-outside: yyy, zzz; ... }
</style>
<text id="my_text">Some text.</text>
</div>


The end result of both HTML/CSS and SVG/CSS is an identical wrapping area.

### Difference of opinion?

• Tav: SVG Text uses CSS, SVG Text is not CSS text.
• Cameron: SVG text is CSS text.

The principle difference is where does CSS layout take over. I (Tav) believe that the proper place is in providing CSS layout a "wrapping area" that CSS text layout then fills. Cameron, I think, believes in starting a layer up with a CSS box (as created by a <div>), requiring, for example, explicitly specifying that box margins are zero.

I see this as an implementation issue. It may be necessary that for browsers to take advantage of the CSS layout engine, they need to create a CSS box, set box margins to zero, etc. but it should not be a fundamental part of the specification. Stand-alone SVG renderers should not need to deal with this extra level of complexity.

Amelia comments that "the CSS 'block' model layout does not apply to SVG; SVG layout defines the content box." But the "CSS inline box layout does apply" to auto-wrapped text which means we do need to address margins/padding/borders to the extent that they apply to inline boxes.

## Baselines

Relevant specifications:

### 'dominanant-baseline'

#### Missing values

SVG 1.1 'dominant-baseline' is based on the XSL 'dominant-baseline'. It includes additional values than currently in CSS Inline:

• 'use-script'
• 'no-change'
• 'reset-size'
• 'ideographic'
• 'middle'
• 'text-after-edge'
• 'text-before-edge'

I'm not too worried about losing 'use-script' and 'no-change' but I think 'ideographic' and 'middle' should be kept. Both are supported by Firefox and Blink. 'reset-size' also has a useful purpose (see next point).

#### Baseline table

In both SVG 1.1 and XSL the baseline tables are not changed when the font size changes. The tables are only changed when the 'dominant-baseline' has a value of 'reset-size'. It's not clear that this is the prescribed behavior in the CSS Inline spec and browsers don't seem to follow this.

#### 'auto' values

The 'auto' value for vertical text when coupled with the obsolete SVG 'glyph-orientation-vertical' values '90deg' and '90' breaks SVG content. This is because these values for 'glyph-orientation-vertical' are mapped to the 'text-orientation' value 'sideways' which dictates that the 'dominant-baseline' has a value of 'alphabetic' where in SVG 1.1 the auto value of 'dominant-baseline' for all vertical text is 'central'. This is important as in SVG, text is positioned so that the dominant baseline is aligned to the 'x' attribute of the <text> element (for vertical text). Using the 'alphabetic' baseline for sideways text will result in shifting the text by the difference between the alphabetic and central baselines.

#### Default values

It would be useful to suggest default values for the 'hanging' and 'mathematical' baselines if they cannot be extracted from the font (and are not otherwise clearly defined). Using the top of the 'em' box (as with Firefox) is clearly wrong for writing systems using a hanging baseline. CSS Inline does define a "synthesized" baseline for "hanging": 0.6em. (As referenced from the 'alphabetic' baseline?)

• 'alphabetic': reference.
• 'ideographic': bottom of em-box (descent).
• 'hanging': 0.6 em.
• 'mathematical': 0.8 ex height?
• 'central': defined as middle of em-box.
• 'middle': defined as half of ex-height'

The 'hanging' and 'mathematical' baselines could be measured from the font. One could measure the hanging baseline by measuring the ascent of various glyphs in the the Devanagari, Bengali, Gujarati, etc scripts. The math baseline could be found by finding the middle of the 'minus' character.

## Auto-wrapped text

Relevant specifications:

### How to layout top line?

Note: Not just an SVG issue. Problems occurs with Shapes Module 1 and with Round Display

Possible solutions: Move down until first word fits:

1. By an arbitrary amount.
2. By increments of 'line-height'.
3. By increments of half 'line-height'.

I would favor moving down multiples of half 'line-height'. It would give better predictability of where the first line is placed that having no restriction. Moving down a multiple of 'line-height' would often result in a large gap at the top.

Does the CSS Line Grid spec provide a solution? ('line-grid' value 'create').

Amelia says the Chrome slides the text down ignoring line grid. Here is an example for Chrome:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.

Feed back:

1. No restrictions allows optimal use of space.
2. Important to be able to align to external objects.
3. Need to align across multiple areas.
4. Maybe a new property?

### How to handle overflow?

Flowed text into shapes in SVG uses fixed size regions. How to expose to the viewer overflowed text? The 'over-flow' property allows clipping or ellipses. The CSS 2.1 'overflow' property allows clipping or scrolling. The CSS 3 'overflow' property adds additional values. The CSS Shapes 2 specification dictates that text overflows under the "rectangular bounds" of the element:

Possible solutions:

1. Do not define now for SVG.
2. Provide a means to expose the text, for example, displaying it on hovering over the ellipses).
3. Continue in rectangle region below shape as dictated by Shapes 2 (using width of 'shape-inside' to define "rectangular bounds").

I think it is important that the viewer has access to all the text but arbitrarily placing it on the screen isn't a visually good solution.

### How to handle shapes with doughnut holes, etc.?

Note: This could be a current problem for CSS Shapes 1 (see: Shapes from Image):

The ''wrap-flow' property allows choosing how wrapping flows around an exclusion. It's not clear how this would apply to divided lines from the 'shape-inside'.

### How to fill sequentially into multiple shapes

SVG 1.2 flowed text allowed text to be flowed into multiple shapes (as one shape was filled up, the text would flow into the next shape). It would be nice to preserve this functionality. (Inkscape implements this.)

CSS Regions may be the solution but it's not clear how it would work. A list of shapes in 'shape-inside' would be simpler.

### How is the first glyph positioned in a line

When the first glyph is positioned at the edge of a wrapping area that is not a vertical line (for horizontal text), how is the first glyph positioned?

The initial-letter wrapping section of the CSS Inline specification demonstrates a related problem:

For positioning the first glyph in a wrapping area, presumably any spacing (equivalent to the gray boxes above) is handled by the 'shape-padding' property.

There is still a bit of uncertainty as to what part of the glyph is considered in placing it against the edge of the wrapping area: is it the box defined by the height of the em-box and the width of the glyph? Does a non-unit value of 'line-height' have any effect?