Re: Fwd: Two questions on flowed text in 1.2

Jon,

> 1) Is Inkscape primarily interested in SVG for publishing (i.e., the SVG's
> are view-only) or SVG for applications (i.e., the SVG presents a user
> interface and users enter data which is sent back to a back-end server)? I
> would like to have a better understanding of the workflows for which
> Inkscape will be using <textArea>.

Inkscape is a general-purpose vector editor with SVG as the native
format. Therefore we do not really have any preferences as to how
Inkscape-created SVGs are to be used; it's our users who put them to
use. I see no problems with any of the scenarios you outlined. We just
provide a tool for creating SVG; by making sure our SVG documents
follow the standard closely, we make them as universally applicable as
any other SVG documents.

(As an aside, we do write some Inkscape-specific metadata into our SVG
documents, but this metadata may only affect the way the document is
edited in Inkscape, but never affect the way it is rendered. For
example, an attribute from Inkscape namespace forces Inkscape to treat
a <g> as a layer instead of a group. You can always export a document
as "Plain SVG" without any Inkscape metadata.)

So, to answer your question about how Inkscape will use textArea, it's
not Inkscape which will use it, but our users. There are lots of
situations where this is necessary: text boxes in diagrams, text
columns in web page mockups, page layouts to be printed or exported to
PDF, SVG pages with text created for SVG-enabled browsers, etc.

> 2) Do you want the various SVG viewers to perform rewrapping of text on the
> client side, and if so, do you require that the viewers wrap text exactly
> as your authoring tool?

SVG 1.2 compliant viewers will do their own rewrapping, of course. We
expect them to follow the standard-prescribed way, not "our" way of
wrapping it :)

> There are various situations where the viewer will
> wrap text differently than the authoring tool: (a) the SVG viewer may not
> implement all features completely or correctly

There's no protection against this one I'm afraid, except that, when
in doubt, the user will be able to convert the flowed text into
regular <text> from SVG 1.1 (losing the reflow capability but
preserving the appearance).

> (b) complicated specs such
> as SVG tend to have at least a few errata, so even "correct"
> implementations might not have integrated errata completely at any given
> moment in time, 

Same answer as in (a), except we will do our best to help you get the
specification right the first time :)

> (c) client systems will have a different set of installed
> fonts,

We don't yet support SVG fonts but we plan to, so that embedding all
used fonts into the SVG document will take care of that.

> (d) not all fonts with the same name are identical (e.g., Helvetica
> can vary from machine to machine),

Same answer as (c)

> (e) different users install different
> localization packages,

This problem is not unique to flowed text. If you're trying to view an
SVG with Arabic text but don't have the fonts or your viewer is
incapable of RTL, it will be screwed no matter whether it's flowed or
not.

> (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.

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. At any rate, the users will always have the option
of converting flowed text to 1.1 <text> or even directly to paths, if
appearance is important.

By the way, this problem is not limited to 1.2. In 1.1, you have the
same provision for textPath: glyphs that go beyond the end of the path
are not shown. (And if you ask me, this was really a bad decision; it
would make much more sense if these glyphs were visible, continuing
the line at the same angle as the last glyph-on-path.)

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

Even though, as I said above, generally it's our users who make use of
Inkscape-generated SVGs, to this question I can answer in the
positive. One of our planned projects involves converting all of the
Inkscape tutorials, which are currently SVG 1.1 with manual line
breaks, into SVG 1.2 with all text flowed into rectangular columns.
These tutorial documents will be generated from a DocBook text source
and SVG illustrations, and the XSLT stylesheet that will do the
conversion will have to "pour" the source text into textAreas of the
generated SVG. This will make updating and translating the tutorials
much easier.

--
bulia byak
Inkscape. Draw Freely.
http:://www.inkscape.org

Received on Sunday, 17 April 2005 16:30:45 UTC