- From: bulia byak <buliabyak@gmail.com>
- Date: Sun, 17 Apr 2005 13:30:43 -0300
- To: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Cc: Chris Lilley <chris@w3.org>, www-svg@w3.org
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