On 8-9-2012 23:31, Alexandre Prokoudine wrote:

On Sun, Sep 9, 2012 at 1:15 AM, Johan Engelen wrote:

...

Hi all, The guide project has changed the format in which guides are saved to SVG. The question now is: how do we provide compatibility with "old-style" guides? My proposal: convert old-style definitions to new-style upon loading the file. Saving said file and opening it in Inkscape 0.48 will no longer show any guides in this case. If desired, we can create a python extension that saves the file with all guides converted to old-style.

1. Load the file
2. Detect things that need to be converted
3. Convert and warn, what kind of things have been changed

We don't have a warning system, do we? :S -Johan

On 9-9-2012 0:54, Alexandre Prokoudine wrote:

On Sun, Sep 9, 2012 at 2:04 AM, Johan Engelen wrote:

...

...

1. Load the file
2. Detect things that need to be converted
3. Convert and warn, what kind of things have been changed

We don't have a warning system, do we? :S

Shouldn't we have one? :)

Yes we should. Likewise for a file upgrade system...

A simple popup dialog will do?

Cheers, Johan

On Tue, 2012-09-11 at 19:46 -0700, Jon Cruz wrote:

On Sep 9, 2012, at 11:58 AM, Johan Engelen wrote:

...

On 9-9-2012 0:54, Alexandre Prokoudine wrote:

...

On Sun, Sep 9, 2012 at 2:04 AM, Johan Engelen wrote:

...

...

1. Load the file
2. Detect things that need to be converted
3. Convert and warn, what kind of things have been changed

We don't have a warning system, do we? :S

Shouldn't we have one? :)

Yes we should. Likewise for a file upgrade system...

A simple popup dialog will do?

We probably should do a little unified system, since we already have some dialogs and queuing implemented here and there. Pull it all together and we'll give users a non-surprising experience.

Good idea, we should probably add to the list of things to issue a warning if the user has opted to delete non-useful/invalid elements and attributes.

Tav

On 9-9-2012 20:43, Chris Mohler wrote:

On Sat, Sep 8, 2012 at 4:31 PM, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:

...

1. Load the file
2. Detect things that need to be converted
3. Convert and warn, what kind of things have been changed

4. Mark the file dirty and append something like "-converted",

"-upgraded", etc. to file name?

Did we actually have people complain about grids no longer working when opened with an old Inkscape? (the change happened with 0.46)

I feel that showing a dialog is already a more than friendly gesture to our users and that we should keep it at that.

Ciao, Johan

Is there a simple method in Inkscape to close the path (or all paths) in a PathVector - without messing up any paths which are already closed?

This came up in the context of a modified sp-livarot.cpp, where an Inkscape PathVector that was "open" (for instance, a "V" shape) could still be filled, whereas the same path passed into a (modified) sp-livarot.cpp function could not manipulated, apparently because the livarot routines only define boolean operations on closed areas.

Thanks,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

Tried this in inkscape using a test document with a nonzero background color

SPNamedView *nv=SP_NAMEDVIEW(style->object); std::cout << "nv defined? " << (nv ? "yes" : "no") << std::endl; uint32_t bgc = nv->pagecolor; std::cout << "doc background color:" << std::hex << bgc << std::endl;

but it emitted:

nv defined? yes doc background color:0

So that doesn't work. It sets nv to something, but not something actually linked to the document's pagecolor.

How to go about this?

This is needed for some cases in the EMF driver gradient handling. Default Inkscape gradients tend to be like: FF000000 -> FF0000FF. That won't work in an EMF file because these only use RGB, resulting in a R->R gradient, which is not at all useful. As a compromise I wanted to use the background color in place of the transparent stop, or I guess just black if the background color is itself fully transparent.

Thanks,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

I want to be able to merge incoming text fragments from an EMF file into a <text> object which might have multiple lines. The idea is that something like "E=mc2" (formatted properly) is editable immediately on import into Inkscape even though it might have appeared in the EMF as the strings "E","=mc", and "2". (Currently EMF import leaves them like that, which is miserable to edit.) One can get the right look using vertical and horizontal kerning. (Figuring out super/subscript would be awful, since those properties are not explicitly noted in the EMF input.)

However, while the resulting text object looks normal, the editing is baroque.

For instance, for testing purposes, here an example of some text that might have been imported from an EMF (the original dx/dy was simpler and there were more tspans, but this is what inkscape simplified it down to):

<text x="300" y="312.63782" id="text666"

style="font-size:17.5px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Arial;-inkscape-font-specification:Arial"> <tspan dx="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -60" dy="0 0 0 0 0 0 -9 0 0 9 0 0 0 0 0 6 0 0 18" id="tspan6661" style="font-size:17.5px">simpleSupsimpleSubNext long line blah blah blah</tspan> </text>

What displays is (use a fixed width font and imagine Sup and Sub are offset appropriately):

simpleSupsimpleSub Next long line blah blah blah blah

Now the bizarre part. Place the cursor before the "s" in the first "simple" (AKA, before the first letter) and move right with the arrow key. Until the last letter in the first line is hit any editing operations in the cursor take place in the first line. However, after the "b" the cursor jumps back to line up with the left edge of the "N" - but stays in the first row. (That is, it respects the dx information, but ignores the dy information.) Enter a key there and it appends after the final "b" in the first row - there does not seem to be any way to enter letters before the N on the 2nd row. Move the cursor one more position right and enter a character and then it is entered into the 2nd row. Move the cursor all the way to the right and add characters and they append to the end. Press return or shift-return and the text to the right is shifted back and over the the first character ("s" in the first "simple"). Ie, it acts like the classical CR without LF if there is only one row, much stranger in the two row case (try it right after "line").

Is all of this intentional? Naively since the dx/dy are all relative I would have thought that pressing "return" would have changed a kern at that location, (0,0) (for instance) to (-M,+LS), where M is the offset to line up at the start of the first row on X, and LS is the line spacing.

Clearly all of this is related somehow to the kerning. So text -> remove manual kerns. That reduces the two line case to a single line. However, it does not resolve the bizarre CR without LF effect - even though all of the kerning has been eliminated.

Start a new text object and it edits normally, with a "return" acting like both a CR and LF.

The difference between the two cases seems to be the presence of

sodipodi:role="line"

in the tspan of the one that works. Adding that to the de-kerned text makes it behave "normally". However, adding it to the <tspan> in the svg above still does not work quite right. Pressing a return in the top row breaks the text exactly as expected, but doing so in the second row moves the fragment to the right, not to the beginning of the first row (as before), but to the same place text moves when the first line is broken in this manner.

So a little guidance would be helpful.

Is there something that could be added to the svg above, so that it is editable like normal text? If not, are these strange editing outcomes a bug or a feature? Why is it that Inkscape cannot edit text "normally" unless the sodipodi:role="line" is present?

Thanks,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech