RE: Comments on SVG 1.2 from a Gecko developer

Hi, Robert-

Robert O'Callahan wrote:
| I see that you've taken some shortcuts to make it work in the 
| SVG 1.2 recommendation, such as the idea that the line-height 
| is always derived from the first word. I hope you're aware 
| that (as far as I can tell) you will get something 
| surprisingly ugly with the following markup:
| 
| <flowRoot>
|   ...
|   <flowLine>Some very long text string.</flowLine>
|   <flowLine>Hmm, <flowSpan style="font-size:200%">Uh 
| oh</flowSpan></flowLine> </flowRoot>

I don't think you got the proper reading from this. In section "3.1.12 Text
Flow", item #7:

"Words are added to the current Strip in logical order. All the Glyph Groups
from a word must be in the same strip and all the glyphs from a Glyph Group
must be in the same Text Region. 

When a word is added the line height may increase, it can never decrease
from the first word. An increase in the line height can only reduce the
space available for text placement in the span. 

The span will have the maximum possible number of words." 

To me, that says that the initial determinant of line height is the first
word, but it is increased when a new taller word is added to the strip. I
think that that would be a logical way to do it.

Here's an example in ASV6pr1 (please note that this uses a slightly
different syntax than is in the current Spec, but I assume the funtionality
is largely the same):
http://www.schepers.cc/testbed/flowText-lineheight-ASV6pr1.svg
In case you don't have the ASV6pr1 plug-in:
http://www.schepers.cc/testbed/flowText.png

This looks fine to me. Are you objecting to the fact that there are lines of
unequal height? Or did you think that the larger text would overlap the line
above?


| It seems to me that the basic ideas behind SVG 1.2 text flow 
| could be easily adapted to CSS. You could solve the 
| line-height determination problem by requiring that for 
| elements flowing inside a shape, the CSS3 
| line-stacking-strategy property be treated as "block-line-height".
| http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#LineStacking
| Then you can compute the text regions for a line just like 
| you do here in SVG 1.2. We already know how to place a line's 
| inline boxes offset from the left and right edges of the 
| block (to handle floats). Handling discontiguous text regions 
| shouldn't be too hard (providing the behaviour of 
| text-align:justify is specified, which it doesn't seem to be 
| in this case in SVG 1.2). Placing floats might be 
| troublesome. But we already have to place floats adjacent to 
| other floats so it might not be too much extra work. Or, you 
| could state that floats are not allowed inside SVG text flows 
| at this time.

I don't understand the need to try to put this into CSS. That would cause a
terrible delay in the release of this functionality, when it's already
defined very well in SVG as it is. If someone wants to use flowtext in an
XHTML page, why not simply use an SVG block (either an embed, iframe,
object, or a hopefully-functional mixed-ns section)? This solves the problem
of fonts, precision text layout, and several other issues. 

 
| I'm not ready to comment on the details of the APIs. However, 
| I think you could address the namespace issues and deflect 
| concerns about scope creep by 1) creating a 
| Web-applications-nursery namespace and putting the extensions 
| there and 

I have reservations about this. If control of their development is placed
outside the charter of the SVG WG, the subsequent politics would essentially
mean the death of these features. If this could be done without removing
them from SVG WG development, and still passing them on to Recc status with
the rest of SVG 1.2, I'd be fine with it, but I am far from the only one who
wants these features ASAP.

| 2) putting the extensions in their own section of 
| the SVG draft, clearly separating them from "SVG proper", and 
| explaining that the hope is to migrate them to a broader Web 
| applications forum at a later date.

That seems sensible, if the only intent is to modularize them, and not to
yank them from the SVG1.2 Recc.

Regards-
-Doug


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.713 / Virus Database: 469 - Release Date: 6/30/2004

Received on Thursday, 8 July 2004 01:44:40 UTC