New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ipe crashes on empty paths (which are created by svgtoipe) #163

Closed
tinloaf opened this Issue Oct 9, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@tinloaf

tinloaf commented Oct 9, 2017

Hi,

current ipe cannot load a file containing this path:

<path>
0 0 m
</path>

However, a path like this is sometimes being created by svgtoipe, for example when converting the attached file (which I had to zip so that github allows me to attach it…)

I'm not sure if this is a bug in ipe or svgtoipe, but I think from http://ipe.otfried.org/manual/manual_47.html paths with "just a move" are not explicitly forbidden, right?

Regards,

Lukas

crash.zip

@otfried

This comment has been minimized.

Show comment
Hide comment
@otfried

otfried Oct 9, 2017

Owner

What should Ipe do with such a path? There is actually no way to represent such an object in Ipe now, so rejecting it seems the right thing to do to me. As far as I can see, the svg file has no visible contents either.

Owner

otfried commented Oct 9, 2017

What should Ipe do with such a path? There is actually no way to represent such an object in Ipe now, so rejecting it seems the right thing to do to me. As far as I can see, the svg file has no visible contents either.

@tinloaf

This comment has been minimized.

Show comment
Hide comment
@tinloaf

tinloaf Oct 9, 2017

Yes, but I think refusing to open the file is probably not the correct behaviour? At least for SVGs, such an "useless" path is allowed by the specs, I think. For ipe, I also think that the manual does not forbid this. Thus, either ipe currently refuses to open a well-formed Ipe-XML file, or svgtoipe transforms a valid SVG file into an invalid Ipe XML file.

Maybe it would be better to just silently ignore such paths? Either during conversion from SVG to Ipe-XML or when opening the file in ipe.

Edit: I looked at the code of both ipe and ipetosvg and could not figure out a "trivial" way of ignoring such things. For ipe, the problem is that for the file to open, Path::create() needs to return something (that is not NULL), and I'm not sure what. For svgtoipe, the problem is that parse_path() writes the commands to out as soon as it sees them. It would need to check if the path is "non-trivial" before writing anything.

tinloaf commented Oct 9, 2017

Yes, but I think refusing to open the file is probably not the correct behaviour? At least for SVGs, such an "useless" path is allowed by the specs, I think. For ipe, I also think that the manual does not forbid this. Thus, either ipe currently refuses to open a well-formed Ipe-XML file, or svgtoipe transforms a valid SVG file into an invalid Ipe XML file.

Maybe it would be better to just silently ignore such paths? Either during conversion from SVG to Ipe-XML or when opening the file in ipe.

Edit: I looked at the code of both ipe and ipetosvg and could not figure out a "trivial" way of ignoring such things. For ipe, the problem is that for the file to open, Path::create() needs to return something (that is not NULL), and I'm not sure what. For svgtoipe, the problem is that parse_path() writes the commands to out as soon as it sees them. It would need to check if the path is "non-trivial" before writing anything.

@otfried

This comment has been minimized.

Show comment
Hide comment
@otfried

otfried Oct 10, 2017

Owner

It's always debatable what to do with ill-formed input. One strategy is to accept as input nearly anything that can be interpreted in some way, but to conform strictly to the specs when writing output.

HTML browsers are extreme in this respect, since there is so much ill-formed HTML around. SVG viewers again will try to interpret as much as they can, because there are so many different SVG-producers around.

There are not many Ipe-format producers around, and I think being strict on what Ipe accepts helps them quickly identify bugs in their code. If I'm creating Ipe files and I make a mistake, I definitely want Ipe telling me what's wrong with my output rather than silently ignoring some element.

From this point of view, this should be changed in svgtoipe. As you say, this isn't easy, because svgtoipe is a rather simple script that doesn't fully parse the SVG before creating Ipe output - it rather translates elements on the fly (there are a few other things it can't do because of that).

Owner

otfried commented Oct 10, 2017

It's always debatable what to do with ill-formed input. One strategy is to accept as input nearly anything that can be interpreted in some way, but to conform strictly to the specs when writing output.

HTML browsers are extreme in this respect, since there is so much ill-formed HTML around. SVG viewers again will try to interpret as much as they can, because there are so many different SVG-producers around.

There are not many Ipe-format producers around, and I think being strict on what Ipe accepts helps them quickly identify bugs in their code. If I'm creating Ipe files and I make a mistake, I definitely want Ipe telling me what's wrong with my output rather than silently ignoring some element.

From this point of view, this should be changed in svgtoipe. As you say, this isn't easy, because svgtoipe is a rather simple script that doesn't fully parse the SVG before creating Ipe output - it rather translates elements on the fly (there are a few other things it can't do because of that).

@otfried

This comment has been minimized.

Show comment
Hide comment
@otfried

otfried Oct 10, 2017

Owner

If this is an actual problem for you right now, converting SVG figures to Ipe, I suggest writing a small script that simply filters out these path objects. A simply regular expression match should do.

Owner

otfried commented Oct 10, 2017

If this is an actual problem for you right now, converting SVG figures to Ipe, I suggest writing a small script that simply filters out these path objects. A simply regular expression match should do.

@pierreganty

This comment has been minimized.

Show comment
Hide comment
@pierreganty

pierreganty Oct 10, 2017

The command xml ed -d "//path[normalize-space(text())='0 0 m']" <file>.ipe (using the xml utility xmlstarlet) will delete every path of the form

<path>
0 0 m
</path>

It would recommend it because it is safer to use than regular expression (e.g. it should always return a valid XML file)

pierreganty commented Oct 10, 2017

The command xml ed -d "//path[normalize-space(text())='0 0 m']" <file>.ipe (using the xml utility xmlstarlet) will delete every path of the form

<path>
0 0 m
</path>

It would recommend it because it is safer to use than regular expression (e.g. it should always return a valid XML file)

@otfried otfried closed this Dec 18, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment