I didn't find any topic on this, but I think it is something that someone of you already experienced.
I'm importing a PDF (generated from a CAD draw). its size is ~1.2MB, but as soon as I save it to SVG its size explodes to ~20MB.
I reworked the PDF a bit (ungrupping all, deleting things not useful to me, etc...) but its size it is still huge ~19MB.
The weird thing is that, if I save it back to PDF its size looks again small, like 1.1MB.
My question is: Is there a way to find what is the element that "consumes" so much space? The draw that I'm importing is on A4 page format and is not complicated, so must be something "hidden" in the file.
thanks for your message. Unfortunately it is something that I can not share since it is related to a project under patent.
So I tried to simplify it removing parts of the draw (to post it) and I soon realized that its sized reduced dramatically down to ~1MB. It is then something related to the draw, not to invisible parts as I thought at the begin.
How can a line consume so much space?
Just to provide you something I deleted many parts of the draw and I made the example_1.svg, then I deleted some other and I save it as example_2.svg. You'll see that the first is 340kB, while the second (with just few lines less) it's 124kB. In a normal svg few lines can't weight so much... So I really hope that with these examples you could point me to the error.
Strange: the first SVG and only I checked is 127KB on my system - when saved to PDF it goes down to 12KB. Why it´s 339 parts most in Groups is beyond me.
I attached the PDF from Inkscape. Seems I have to compress it as zip because PDF isn´t accepted as an upload via drag+drop methinks.
Note that PDF files are binary files: they're not designed to be human-readable, so the data in them can be highly compressed and optimised to reduce the file size. SVG files are a form of XML document. XML is a format that is intended to be highly structured, so it can be read by a machine, but also broadly readable (and editable) by a human in a text editor. Open an Inkscape file in a text editor and you'll see what I mean.
You can save as a "Compressed Inkscape SVG (*.svgz)" from within Inkscape. This basically stores the same SVG file, but also applies GZip compression to it, producing a binary file that's no longer human readable, but which is much smaller. If you want to look at the size of a PDF versus an SVG then saving as an SVGZ file would be a much fairer comparison.
That difference alone may not be the sole cause for the size difference, but it is worth being aware of.
Yes I know very well the difference that exists between the SVG and the PDF and I agree with you.
What I still miss is the size difference between the 2 example files that I shared. If I had produce them directly with Inkscape I would have had 2 files quite similar in size... That is my point.
I've been already able to generate the PDF and I had the very same result of you (PDF output results x10 times smaller that its SVG). Of course I would be interested to keep the source file small since I do not keep the "output files".
Even more I'd like to have a smaller SVG since I need to generate also an EMF file which results similar in dimension.
The grey dashed lines are compound paths using many nodes. These could be simple paths with a dash stroke style. Ask the cad operator to generate the dashed lines as solid with color (e.g. red) and change red> dashed grey inside Inkscape.
The paths have many figures to the right of the decimal. These might be fine with just a few. I'd check the numeric precision in the svg output preferences.
There are a few invisible/worthless paths with nodes only stacked on each other. these should be deleted.
What I still miss is the size difference between the 2 example files that I shared
For a start, example_1 has 779 paths in it, compared with 340 in example_2. A lot of the dashed paths are actually made up of hundreds of smaller subpaths, rather than just using a single path with a dash-array set. In the SVG it's the difference between having code like this:
<path d="m 0,0 -0.49,0.04 m -22.300001,1.63 -0.5,0.03 M -0.95,0.08 -1.4,0.12 m -0.45,0.03 -0.46,0.04 m -0.45,0 -0.45,0.04 M -3.67,0.27 -4.12,0.31 M -4.58,0.34 -5.03,0.38 M -5.48,0.42 -5.94,0.46 M -6.39,0.49 H -6.84 M -7.3,0.53 -7.79,0.57 M -8.24,0.61 -8.7,0.65 M -9.15,0.68 -9.6,0.72 m -0.46,0.04 -0.45,0.04 m -0.45,0 -0.46,0.03 m -0.45,0.04 -0.45,0.04 m -0.46,0.04 -0.45,0.04 m -0.45,0.03 -0.46,0.04 m -0.45,0 -0.46,0.04 m -0.45,0.04 -0.45,0.03 m -0.46,0.04 -0.450001,0.04 m -0.449998,0.04 -0.49,0.04 M -18.26,1.36 h -0.449999 M -19.17,1.4 -19.620001,1.44 M -20.07,1.48 -20.530001,1.51 M -20.98,1.55 -21.43,1.59 M -21.889999,1.63 -22.34,1.67" ... />
compared with code like this (which produces a similar looking path):
Multiply that difference across hundreds of paths, each with dozens or hundreds of nodes, and you can quickly get to the sort of size differences you're seeing.
Yes, makes sense now. On top of your answer then I have my final question.
Is there a (simple) way to replace all these small subpaths with a single path? (I mean a "translation" command, instead of selecting every single path with the mouse and then transform it...).
Is there a (simple) way to replace all these small subpaths with a single path?
Not that I can think of. Inkscape has no way to determine that these individual subpaths actually form a single dashed line - it sees them just as lots of separate segments all collected together into a single path object.
@Xav - This is a late followup, I know, but I also wanted to thank you for your explanation. Now I understand why I have five gazillion paths in my document that was originally a CAD file, then a PDF.
@rRsk-Averse-Rider - Well, it's long ago enough that I'd completely forgotten I'd written that reply, but I'm glad it was able to help you understand your problem. It's just a shame that I still can't think of an easy solution.
Beyond the Basics small PDF import results a big SVG
Inkscape.org
Hi folks,
I didn't find any topic on this, but I think it is something that someone of you already experienced.
I'm importing a PDF (generated from a CAD draw). its size is ~1.2MB, but as soon as I save it to SVG its size explodes to ~20MB.
I reworked the PDF a bit (ungrupping all, deleting things not useful to me, etc...) but its size it is still huge ~19MB.
The weird thing is that, if I save it back to PDF its size looks again small, like 1.1MB.
My question is: Is there a way to find what is the element that "consumes" so much space? The draw that I'm importing is on A4 page format and is not complicated, so must be something "hidden" in the file.
Many thanks!
AGA
Can you share an example pdf file?
Hi Tyler,
thanks for your message. Unfortunately it is something that I can not share since it is related to a project under patent.
So I tried to simplify it removing parts of the draw (to post it) and I soon realized that its sized reduced dramatically down to ~1MB. It is then something related to the draw, not to invisible parts as I thought at the begin.
How can a line consume so much space?
Just to provide you something I deleted many parts of the draw and I made the example_1.svg, then I deleted some other and I save it as example_2.svg. You'll see that the first is 340kB, while the second (with just few lines less) it's 124kB. In a normal svg few lines can't weight so much... So I really hope that with these examples you could point me to the error.
Many thanks!
AGA
Strange: the first SVG and only I checked is 127KB on my system - when saved to PDF it goes down to 12KB. Why it´s 339 parts most in Groups is beyond me.
I attached the PDF from Inkscape. Seems I have to compress it as zip because PDF isn´t accepted as an upload via drag+drop methinks.
Note that PDF files are binary files: they're not designed to be human-readable, so the data in them can be highly compressed and optimised to reduce the file size. SVG files are a form of XML document. XML is a format that is intended to be highly structured, so it can be read by a machine, but also broadly readable (and editable) by a human in a text editor. Open an Inkscape file in a text editor and you'll see what I mean.
You can save as a "Compressed Inkscape SVG (*.svgz)" from within Inkscape. This basically stores the same SVG file, but also applies GZip compression to it, producing a binary file that's no longer human readable, but which is much smaller. If you want to look at the size of a PDF versus an SVG then saving as an SVGZ file would be a much fairer comparison.
That difference alone may not be the sole cause for the size difference, but it is worth being aware of.
Hi @Xav,
thanks for your message.
Yes I know very well the difference that exists between the SVG and the PDF and I agree with you.
What I still miss is the size difference between the 2 example files that I shared. If I had produce them directly with Inkscape I would have had 2 files quite similar in size... That is my point.
Hi @PixelPest,
thanks to you message too.
I've been already able to generate the PDF and I had the very same result of you (PDF output results x10 times smaller that its SVG). Of course I would be interested to keep the source file small since I do not keep the "output files".
Even more I'd like to have a smaller SVG since I need to generate also an EMF file which results similar in dimension.
Best regards,
AGA
Some observations:
The grey dashed lines are compound paths using many nodes. These could be simple paths with a dash stroke style. Ask the cad operator to generate the dashed lines as solid with color (e.g. red) and change red> dashed grey inside Inkscape.
The paths have many figures to the right of the decimal. These might be fine with just a few. I'd check the numeric precision in the svg output preferences.
There are a few invisible/worthless paths with nodes only stacked on each other. these should be deleted.
For a start, example_1 has 779 paths in it, compared with 340 in example_2. A lot of the dashed paths are actually made up of hundreds of smaller subpaths, rather than just using a single path with a dash-array set. In the SVG it's the difference between having code like this:
<path d="m 0,0 -0.49,0.04 m -22.300001,1.63 -0.5,0.03 M -0.95,0.08 -1.4,0.12 m -0.45,0.03 -0.46,0.04 m -0.45,0 -0.45,0.04 M -3.67,0.27 -4.12,0.31 M -4.58,0.34 -5.03,0.38 M -5.48,0.42 -5.94,0.46 M -6.39,0.49 H -6.84 M -7.3,0.53 -7.79,0.57 M -8.24,0.61 -8.7,0.65 M -9.15,0.68 -9.6,0.72 m -0.46,0.04 -0.45,0.04 m -0.45,0 -0.46,0.03 m -0.45,0.04 -0.45,0.04 m -0.46,0.04 -0.45,0.04 m -0.45,0.03 -0.46,0.04 m -0.45,0 -0.46,0.04 m -0.45,0.04 -0.45,0.03 m -0.46,0.04 -0.450001,0.04 m -0.449998,0.04 -0.49,0.04 M -18.26,1.36 h -0.449999 M -19.17,1.4 -19.620001,1.44 M -20.07,1.48 -20.530001,1.51 M -20.98,1.55 -21.43,1.59 M -21.889999,1.63 -22.34,1.67" ... />compared with code like this (which produces a similar looking path):
<path d="m 0,-2 -23.290001,1.7" style="...stroke-dasharray:0.45, 0.4;..." ... />Multiply that difference across hundreds of paths, each with dozens or hundreds of nodes, and you can quickly get to the sort of size differences you're seeing.
Hi @Xav ,
many thanks for your very clear answer!
Yes, makes sense now. On top of your answer then I have my final question.
Is there a (simple) way to replace all these small subpaths with a single path? (I mean a "translation" command, instead of selecting every single path with the mouse and then transform it...).
Many thanks!
AGA
Not that I can think of. Inkscape has no way to determine that these individual subpaths actually form a single dashed line - it sees them just as lots of separate segments all collected together into a single path object.
Hi @Xav ,
sure I understand.
In any case super thanks for the clear explanation about the issue I had.
All make sense.
Cheers,
AGA
@Xav - This is a late followup, I know, but I also wanted to thank you for your explanation. Now I understand why I have five gazillion paths in my document that was originally a CAD file, then a PDF.
@rRsk-Averse-Rider - Well, it's long ago enough that I'd completely forgotten I'd written that reply, but I'm glad it was able to help you understand your problem. It's just a shame that I still can't think of an easy solution.