W3C home > Mailing lists > Public > www-svg@w3.org > April 2005

Re: Fwd: Two questions on flowed text in 1.2

From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Date: Sun, 17 Apr 2005 14:09:11 -0400
Message-ID: <4262A647.80008@Kodak.com>
To: bulia byak <buliabyak@gmail.com>
CC: Jon Ferraiolo <jon.ferraiolo@adobe.com>, Chris Lilley <chris@w3.org>, www-svg@w3.org

Hi all,

    I have other comments on the move away from flowText but
this comment applies to both and so is probably worth putting


Jon Ferraiolo wrote:
>>(f) mathematical issues such as some viewers using
>>fixed point arithmetic versus others using double-precision floating point,
>>plus accumulated round-off error. (This is not a complete list.) As I
>>remember, the SVG wrapping text rules were that if a given "word" overflows
>>all available regions, that word is just not visible.

bulia byak wrote:
> This is indeed a problem. In documentation, we will recommend our
> users to always leave some empty space in the flow shapes and not rely
> on the exact wrapping to be preserved in a viewer. They will have to
> live with this; in any case, the benefits of flowed text far outweigh
> this inconvenience.

    A feature that would be of great interest in _many_ use cases for
flowed text in SVG would be to allow a range of font-sizes that the
text could use.  An implementation would start with the largest
font-size if the text fit all is well and good.  If the text doesn't
fit it adjusts the font-size down until it does or it hits a user
defined min font-size.  You could even leave font-size alone and
just add a "min-font-size" property that would default to
'current-font-size' - which would effectively inhibit this behavior
but using something like: 'font-size="24" min-font-size="12"' would
allow for the text to vary from 12 to 24 such that it fits the

    Since this is mostly a 'fallback' case you could leave the
algorithm mostly up to implementations, but I would suggest
something along the lines of stepping the font-size down so
one additional line of text would fit.  One could obviously go
much more complex than this (estimating how much text didn't
fit etc).

>>3) Do any of your workflows involve pouring dynamically-generated text into
>>a <textArea>, where the SVG acts as a template?

    Yes, or even where users are entering the text into a region of a
template and you really want the text to start large and step down
as the text get's longer and longer - i.e. you don't want to bother
the user with a whole 'text layout' facility you just want them to
be able to quickly and easily enter a sentence or two.
Received on Sunday, 17 April 2005 18:09:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:02 UTC