- flowRegion makes flow-go.svg render "correctly"
Actually from my reading of the spec, the old rendering was correct: each flowregion filled from top to bottom, even if it contains multiple shapes.
- fixed the lost word problem. note that you need to
put spaces at the beginning of a flowSpan (or the end of the previous) otherwise the words at both ends will be glued together
Yes, that's reasonable
- a preliminary convert_to_text() verb is in sp-flowtext
Excellent, I put it on Shift+Alt+W as "Unflow text", with the Alt+W reserved for "Flow text" (convert text + shape into a flowed text).
There were a few problems:
- compilation errors on char conversions again - fixed
- the text style only worked if set on flowRoot, not flowDiv - fixed by adding SP_STYLE_FLAG_ALWAYS to sp_style_write_string (line 787), so that it writes the entire style of each chunk, including inherited style
- space after flowSpan was lost - partially fixed by adding xml:space="preserve" to the created text, but the start positions of spans are still sometimes off (convert the attached one and watch the words "as well as" and "kinsoku" - they jump off a bit)
Plus a few other small changes, so please take the files from CVS if you want to change something.
I also thought about the best way to create flowed texts. I think using clones is indeed the best method, as it will let us avoid adding flowtext parsing code to a million places. So when you select a shape and a text, here's what happens:
- the shape is cloned, clone placed exactly over the original
- the clone gets inkscape:use-move="parallel" and inkscape:use-delete="unlink" attribs to ensure these behaviors regardless of user prefs (sp-use support required, but it's simple to add)
- tspans with sodipodi:role="line" are merged together, separated by spaces
- an empty tspan with sodipodi:role="line" (i.e. empty line) is converted into <flowLine/>
- the flowRoot is constructed from the clone and the text thus prepared; original text is deleted
The original shape thus remains and is editable as usual, and the text shape will be updated via the clone. This means the paths in "foreign" (non-Inkscape) flowed texts that do not use clones will not be editable at all, but this is OK (at least for now). This approach has the advantage of relative simplicity, and two more commands can be easily added based on the same mechanism - "Flow around" (adds exclusion shape to an existing flowed text) and "Chain flow" (adds a new region to an existing flowed text), with all these shapes remaining editable (i.e. only their clones are added into the flowtext).
On Mon, Aug 02, 2004 at 03:14:44PM -0300, bulia byak wrote:
- tspans with sodipodi:role="line" are merged together, separated by spaces
[I've interpreted "separated by spaces" as "inserting a space character ( ) between each merged pair of spans".]
Inserting a space between joined words will do the wrong thing for URLs, hyphenated words, and probably Chinese text.
The problem shouldn't arise if we allow typing directly into a shape, with Inkscape doing the line breaking: Inkscape can retain the space characters where they exist, as well as retaining newlines.
[How would newlines be stored in SVG? Is newline recognized as such in the 1.2 draft spec, at least for textflows?]
Approaches until we support typing into a text shape:
- "Unix hacker's approach": Don't insert spaces. The user will compensate, either by not doing any line breaks, or by typing an explicit space (if appropriate) before line breaks. The spelling checker should pick up any mistakes made.
- "Microsoft approach": Use the xml:lang attribute to decide whether or not to insert spaces, and require the user to use a "none" language for URLs. Treat hyphenated words specially (if language is en etc.).
Issues:
- We don't yet support specifying xml:lang for text. (We should, e.g. for spell checking.)
- I don't know of a two-letter code suitable for "none". (xml:lang can be set to "none", but this is for overriding CSS rules, and is to be considered equivalent to absence of xml:lang.)
How should we treat absence of xml:lang? Currently the spell checker language is taken from locale (I forget which; I think LC_MESSAGES).
How should we treat unrecognized language codes?
pjrm.
Inserting a space between joined words will do the wrong thing for URLs,
An URL broken across lines is broken already.
hyphenated words
These could only be hyphenated manually, and therefore can be expected to be dehyphenated also manually. Adding or not adding a space matters less than the manual hard hyphen which stays anyway.
and probably Chinese text.
This one may be real, but I think it's enough to rely on xml:lang if it ever becomes a problem.
The problem shouldn't arise if we allow typing directly into a shape, with Inkscape doing the line breaking: Inkscape can retain the space characters where they exist, as well as retaining newlines.
Of course. We're only discussing the command to convert old multiline text objects to flowed text.
[How would newlines be stored in SVG? Is newline recognized as such in the 1.2 draft spec, at least for textflows?]
Yes, see <flowLine/>
- "Unix hacker's approach": Don't insert spaces. The user will compensate,
Manually removing unneeded spaces if we insert them will likely be much less frequent than adding them if we don't. Let's not overengineer this simple command until spaces really become a problem.
On Mon, Aug 02, 2004 at 11:02:38PM -0300, bulia byak wrote:
Inserting a space between joined words will do the wrong thing for URLs,
An URL broken across lines is broken already.
No it isn't. A URL broken across a line is much better than a URL off the edge of the page. There are standards saying how URLs should be split across lines (namely without using a hyphen) and similarly that URL recognizers (e.g. mail agents that auto-markup URLs) should accept such split URLs.
However, I was just thinking when walking to the office that given that URIs are computer-recognizable, we can treat them specially if we want to for purposes of line breaking and rejoining.
Handling URIs doesn't fix the problem in general, but there's still some value in making the problem rarer.
hyphenated words
These could only be hyphenated manually, and therefore can be expected to be dehyphenated also manually. Adding or not adding a space matters less than the manual hard hyphen which stays anyway.
True for a long word that has a hyphen inserted to break the line at that point, but not true for phrases with hyphens ("computer-recognizable").
Also mostly true if one follows the OED practice of writing "computer- -recognizable" (i.e. having a hyphen at the beginning of the next line if one splits a hyphenated phrase at the hyphen).
- "Unix hacker's approach": Don't insert spaces. The user will compensate,
Manually removing unneeded spaces if we insert them will likely be much less frequent than adding them if we don't.
Agreed.
Let's not overengineer this simple command until spaces really become a problem.
The "Unix hacker's approach" involves least engineering.
What do you mean by "become a problem" (used both here and in context of chinese) ? It is immediately a problem in the software; it becomes a practical problem once someone uses the relevant bit of code. We may or may not receive a bug report, though that can be used as a test of annoyingness.
pjrm.
On Mon, 2 Aug 2004 15:14:44 -0300, bulia byak <buliabyak@...400...> wrote:
the shape is cloned, clone placed exactly over the original
the clone gets inkscape:use-move="parallel" and
inkscape:use-delete="unlink" attribs to ensure these behaviors regardless of user prefs (sp-use support required, but it's simple to add)
Correction: both the first shape into which the text is flown and the additional shapes that are added via "Flow around" (exclusion) or "Chain flow" get inkscape:use-delete="delete". This means that deleting any "additional" shape also deletes its clone inside the flowtext, and the flowtext reacts by reflowing accordingly. If however you remove the only remaining shape (i.e. all regions are now empty), flowtext must detect this situation and convert itself to text automatically.
participants (2)
-
bulia byak -
Peter Moulder