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
macOS: XML error: error in path data: number expected (premature end of data) #240
Comments
Sorry, I can't help with Asymptote issues here. Please upload the corresponding DVI file |
How should I upload the dvi file?
ZIP file |
Thanks for uploading the file. Unfortunately, I can't reproduce the error. The file converts correctly on my machines (Linux and Windows). Maybe someone needs to take a closer look at this on a Mac (which I don't have access to). |
Currently, I am little bit lost:
based on recent issues on macOS
draw(box((0,0), (2,1))); A diff between both intermediate tex files containing special commands: \special{dvisvgm:raw{?nl}%
-<g transform='matrix(0.996264 0 0 0.996264 56.6594 65.5634)'>{?nl}%
-<path d='M 0 1.50562L 2.50937 1.50562L 2.50937 0L 0 0L 0 1.50562Z' fill='#ffffff'/>{?nl}%
+<g transform='matrix(0.996264 0 0 0.996264 57.6594 64.5634)'>{?nl}%
+<path d='M 0 2.50937L 2.50937 2.50937L 2.50937 0L 0 0L 0 2.50937Z' fill='#ffffff'/>{?nl}%
</g>}\catcode`\#=6%
\catcode`\#=11%
\special{dvisvgm:raw{?nl}%
-<g transform='matrix(0.996264 0 0 0.996264 56.6594 65.5634)'>{?nl}%
-<path d='M 0.250937 1.25469L 2.25844 1.25469L 2.25844 0.250937L 0.250937 0.250937L 0.250937 1.25469Z' fill='none' stroke='#000000' stroke-linecap='round' stroke-linejoin='round' stroke-miterlimit='10.0375' stroke-width='0.501875'/>{?nl}%
+<g transform='matrix(0.996264 0 0 0.996264 57.6594 64.5634)'>{?nl}%
+<path d='M 2.25844 1.25469C 2.25844 0.700332, 1.80904 0.250938, 1.25469 0.250937C 0.700332 0.250937, 0.250937 0.700332, 0.250937 1.25469C 0.250937 1.80904, 0.700332 2.25844, 1.25469 2.25844C 1.80904 2.25844, 2.25844 1.80904, 2.25844 1.25469Z' fill='none' stroke='#000000' stroke-linecap='round' stroke-linejoin='round' stroke-miterlimit='10.0375' stroke-width='0.501875'/>{?nl}% shows that the most outstanding difference is the cubic Bézier curve. The error
As you say, it seems to be that the generated dvi file is fine. So it might not be an issue on the side of asymptote but a platform-specific one. Do you have an idea in which direction I could look? Is there anything platform-dependent regarding the My current assumption is that I have to compile dvisvgm myself with debug symbols to see what is going on in |
I guess it's this issue. The behavior of |
Thanks for pointing out this difference between the two implementations of the STL regarding the What baffles me in particular is that this issue is 10 years old (llvm/llvm-project#18156). Writing correct parsers is IMHO always challenging, and something like SVG might be one of the even more complicated ones (xml+properties like paths). However, finding a license-compatible lightweight ready to use, actively maintained third-party library is also not a simple story. Anyhow, I hope you find a workaround in the parser of dvisvgm and can fix it in one of the next releases of dvisvgm. |
I did a little bit of further digging: I took the test example from llvm/llvm-project#18156 and added a few lines related to SVG path parsing: demo-double-stream.cpp#include <sstream>
#include <iostream>
using namespace std;
void extract_double(const string & s)
{
stringstream ss;
double d;
// testing number only
ss << s;
ss >> d;
if(!ss.fail())
cout << "'" << ss.str() << "' converted to " << d << endl;
else
cout << "'" << ss.str() << "' failed to convert to double" << endl;
}
int main()
{
cout << "local is " << setlocale(LC_ALL, NULL) << endl;
extract_double("-4.9");
extract_double("-4.9 X");
extract_double("-4.9_");
cout << endl << "SVG Path parsing:" << endl;
extract_double("2.50937L");
extract_double("0L");
extract_double("2.50937Z");
cout << endl << "Issue between libc++ (llvm) and libstdc++ (gcc):" << endl;
extract_double("-4.9d");
extract_double("-4.9X");
cout << "SVG Path parsing:" << endl;
extract_double("1.25469C");
} The results are libc++ (llvm)
libstdc++ (gcc)
This confirms that libc++ throws an error for Since this issue for libc++ is quite old and shows no sign of an upstream change, IMHO As a first step it should be specifically mentioned that libc++ (LLVM) cannot be used for dvisvgm and suggest to use libstdc++ (GCC). However, libstdc++ is not by default available on macOS and makes installation on macOS more complicated. There might also be other reasons why someone would like to use libc++. Possible options to allow libc++
All of them sound like a major change in the code (new dependencies or a rewrite of the path parser). I will try to compile dvisvgm myself using libstdc++ on macOS for now. |
I hardly know anything about how to compile either dvisvgm or Asymptote on macOS (though I'm on macOS), but if it's a litter bit easier to compile Asymptote on macOS using default settings, for a workaround it seems you can patch Asymptote to always insert a space before Relevant lines in Asymptote https://github.com/vectorgraphics/asymptote/blob/494e8120ee967aa9c71ae26e2476b5632211b6e2/texfile.h#L419-L436 Or, does Asymptote allow executing user scripts after it writes to a tex file and before it runs latex command? |
That's actually a suggestion I consider now. I am already struggling compiling dvisvgm since the kpathsea dependency is not easy to fulfil:
Thanks.
Not that I am aware of. I could add a workaround with the |
I have now patched Asymptote and compiled it myself: --- a/texfile.h
+++ b/texfile.h
@@ -417,22 +417,22 @@ public:
}
void moveto(pair z) {
- *out << "M";
+ *out << " M";
writeshifted(z);
}
void lineto(pair z) {
- *out << "L";
+ *out << " L";
writeshifted(z);
}
void curveto(pair zp, pair zm, pair z1) {
- *out << "C";
+ *out << " C";
writeshifted(zp); writeshifted(zm); writeshifted(z1);
}
void closepath() {
- *out << "Z";
+ *out << " Z";
}
Now I get a webgl output for However, I leave this issue open, since dvisvgm should handle all valid svg input correctly. Either dvisvgm should not compile with libc++ or find a workaround to deal with the difference between libc++ and libstdc++. |
I've fixed the issue locally and will commit the patch after some more testing. |
I am using Asymptote which in turns uses dvisvgm.
I get for following asymptote file
draw(unitcircle);
the error
Running asymptote verbose with keep intermediate files
shows that the error is printed by dvisvgm (see last lines):
My Environment:
Ghostscript 10.00.0 with libgs from https://www.tug.org/mactex/morepackages.html (watchout to customize the installation to include libgs)
The text was updated successfully, but these errors were encountered: