When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes [truncated]. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as [truncated].
On Mon, 2009-12-21 at 01:44 -0400, bulia byak wrote:
When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes [truncated]. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as [truncated].
This is cool. One feature that I miss from Pagemaker (yes, I'm old) was that it put a little triangle on the bottom of a text box when you could click on to basically draw an additional text box which would then contain the rest of the flowed text.
--Ted
On Tue, Dec 22, 2009 at 1:06 PM, Ted Gould <ted@...11...> wrote:
This is cool. One feature that I miss from Pagemaker (yes, I'm old) was that it put a little triangle on the bottom of a text box when you could click on to basically draw an additional text box which would then contain the rest of the flowed text.
In Inkscape you can easily drag the corner handle to resize the text frame. As for placing a marker indicating text truncation, the problem is that it will take additional effort to calculate its position if we want it to correspond to the last visible character - for example it will be different depending on rtl or ltr text.
On Tue, 2009-12-22 at 14:01 -0400, bulia byak wrote:
On Tue, Dec 22, 2009 at 1:06 PM, Ted Gould <ted@...11...> wrote:
This is cool. One feature that I miss from Pagemaker (yes, I'm old) was that it put a little triangle on the bottom of a text box when you could click on to basically draw an additional text box which would then contain the rest of the flowed text.
In Inkscape you can easily drag the corner handle to resize the text frame. As for placing a marker indicating text truncation, the problem is that it will take additional effort to calculate its position if we want it to correspond to the last visible character - for example it will be different depending on rtl or ltr text.
No, I was thinking that it would be more like a binary union. So then then you could add additional areas that weren't necessarily next to each other. Something like columns in a newsletter. We wouldn't have to deal with the precise end of the text, just provide an extended area for the text.
--Ted
On Tue, Dec 22, 2009 at 2:53 PM, Ted Gould <ted@...11...> wrote:
No, I was thinking that it would be more like a binary union. So then then you could add additional areas that weren't necessarily next to each other. Something like columns in a newsletter. We wouldn't have to deal with the precise end of the text, just provide an extended area for the text.
Actually this is already possible - flowtext can flow from one shape to the next. We just don't have UI for that - because really, we must _first_ move flowtext to our namespace behind a svg:switch before we can add any more functionality to it.
Actually this is already possible - flowtext can flow from one shape to the next. We just don't have UI for that - because really, we must _first_ move flowtext to our namespace behind a svg:switch before we can add any more functionality to it.
This is tied to the subject I mentioned earlier in another thread, the 1:1 correspondence between XML element nodes and SPObjects. This paradigm is somewhat limiting, and storing the XML nodes all the time is eating some memory. In fact, the mere possibility of accessing the XML from the SP tree feels wrong to me - how the object is stored as XML should be private to that object's implementation.
Regards, Krzysztof
On Dec 23, 2009, at 10:03 AM, Krzysztof Kosiński wrote:
This is tied to the subject I mentioned earlier in another thread, the 1:1 correspondence between XML element nodes and SPObjects. This paradigm is somewhat limiting, and storing the XML nodes all the time is eating some memory. In fact, the mere possibility of accessing the XML from the SP tree feels wrong to me - how the object is stored as XML should be private to that object's implementation.
That is where extreme caution in any redesign needs to be exercised. The general approach you mention is the one Microsoft used for COM and the MS Word file format. This ends up blocking many of the more useful design patterns, and does things like tightly couple runtime functionality and efficiency to on-disk storage.
Compatibility is also sacrificed. Remember, we need to extend things to support SVG v 1.2 in addition to (note that it is not "instead of") SVG v 1.1.
So, yes, we probably could benefit from a good refactoring. However, it is critical that we identify all the constraints and requirements before making any substantial changes. We also might want to consider things such as XOP when we do ( http://www.w3.org/TR/xop10/ )
On 12/23/09, Jon Cruz wrote:
Compatibility is also sacrificed. Remember, we need to extend things to support SVG v 1.2
You mean v2.0? :)
Nope. Look in the trunk. We have some 1.2 features in there already.
Um, yes I know :) I was merely referring to W3C's decision to get on with 2.0 and leave 1.2 alone.
Alexandre
That is where extreme caution in any redesign needs to be exercised. The general approach you mention is the one Microsoft used for COM and the MS Word file format. This ends up blocking many of the more useful design patterns, and does things like tightly couple runtime functionality and efficiency to on-disk storage.
Hmm. I am not sure I understand this. What I was thinking about was this:
Currently every SPObject has a corresponding XML element node, for example every SPRectangle has a corresponding svg:rect element, and every SPPath has a corresponding svg:path element. From what I was able to understand, changing the type of the XML element node in response to some styling change (eg. change svg:rect to svg:path if it has markers or LPEs) is not easy, because you need to remove the old XML element node and create a new one. This will destroy any observers attached to the XML node, and in general one can't just 'transplant' them to the new node, because the observers might store the node's address somewhere.
What I thought about is to remove this link, and not store XML in memory at all. Saving would be similar to rendering: we would ask each object to generate its XML representation, and write it to the output file. One benefit of this is that we can change the element that is being written easily, and we can solve the flowtext issue (the flowtext object would "render" to a switch containing both Inkscape editing data and normal SVG 1.1 text).
Regards, Krzysztof
On Dec 23, 2009, at 10:46 AM, Krzysztof Kosiński wrote:
Hmm. I am not sure I understand this. What I was thinking about was this:
[SNIP]
What I thought about is to remove this link, and not store XML in memory at all. Saving would be similar to rendering: we would ask each object to generate its XML representation, and write it to the output file. One benefit of this is that we can change the element that is being written easily, and we can solve the flowtext issue (the flowtext object would "render" to a switch containing both Inkscape editing data and normal SVG 1.1 text).
Yes, the aspect of having each and every class/object do it's own serialization is what breaks modularity. And trust me, the MS Word format is so poorly implemented that even Microsoft can't keep backward compatibility for long.
What we probably need is an in-memory tree that has runtime functionality and then a separate set of classes to do reading and another to do writing. So we can just feed a tree to a SVG11Serializer or a SVG12Serializer, etc. (Of course, given the complexity of SVG 1.2 and all the 'modules', we would probably have that serializer behind facade and factory patterns)
Krzysztof Kosiński wrote:
That is where extreme caution in any redesign needs to be exercised. The general approach you mention is the one Microsoft used for COM and the MS Word file format. This ends up blocking many of the more useful design patterns, and does things like tightly couple runtime functionality and efficiency to on-disk storage.
Hmm. I am not sure I understand this. What I was thinking about was this:
Currently every SPObject has a corresponding XML element node, for example every SPRectangle has a corresponding svg:rect element, and every SPPath has a corresponding svg:path element. From what I was able to understand, changing the type of the XML element node in response to some styling change (eg. change svg:rect to svg:path if it has markers or LPEs) is not easy, because you need to remove the old XML element node and create a new one. This will destroy any observers attached to the XML node, and in general one can't just 'transplant' them to the new node, because the observers might store the node's address somewhere.
What I thought about is to remove this link, and not store XML in memory at all. Saving would be similar to rendering: we would ask each object to generate its XML representation, and write it to the output file. One benefit of this is that we can change the element that is being written easily, and we can solve the flowtext issue (the flowtext object would "render" to a switch containing both Inkscape editing data and normal SVG 1.1 text).
How does your proposal affect roundtripping SVG through Inkscape? For Inkscape as a vector illustration application this may not matter. But for Inkscape as an SVG authoring and editing application this is very important. What happens to a document when we open it and immediately click save? What happens when we open a document with a mixture of non-SVG XMLs?
Aaron Spike
W dniu 23 grudnia 2009 20:28 użytkownik Aaron Spike <aaron@...749...> napisał:
How does your proposal affect roundtripping SVG through Inkscape?
It makes it more difficult. For objects we don't recognize, we can store the original XML. But it gets a little complicated - some portions of the tree store the original XML, and some generate it from internal SPObject data. Maybe someone else has a simpler idea.
Probably the ideal way to implement this SPObject-to-XML serialization would be through aspect-oriented techniques.
Regards, Krzysztof
On Dec 23, 2009, at 11:42 AM, Krzysztof Kosiński wrote:
Probably the ideal way to implement this SPObject-to-XML serialization would be through aspect-oriented techniques.
No, not really.
You should look to some stock design patterns, and not to an entirely new programming paradigm.
I don't see that the Visitor pattern would be that helpful here (which is probably one closest to AOP). We probably first need to look at Facade, Factory and Memento.
That could be even better if text could flow between different kind of text objects.
________________________________ De : Ted Gould <ted@...11...> À : bulia byak <buliabyak@...400...> Cc : Inkscape Devel List inkscape-devel@lists.sourceforge.net Envoyé le : Mar 22 Décembre 2009, 18 h 06 min 42 s Objet : Re: [Inkscape-devel] NEW: truncated text indication
On Mon, 2009-12-21 at 01:44 -0400, bulia byak wrote:
When a flowed text is truncated (i.e. the frame is too small for the entire text), the frame is shown red, and the statusbar hint includes [truncated]. You need to resize the frame to see the truncated end of the text. Analogously, if the path of a text-on-path object is too short to display the entire text, the statusbar will report it as [truncated].
This is cool. One feature that I miss from Pagemaker (yes, I'm old) was that it put a little triangle on the bottom of a text box when you could click on to basically draw an additional text box which would then contain the rest of the flowed text.
--Ted
participants (7)
-
Aaron Spike -
Alexandre Prokoudine -
bulia byak -
Ivan Louette -
Jon Cruz -
Krzysztof Kosiński -
Ted Gould