Use compressed SVG to reduce file size

[wh201906]

Is your feature request related to a problem? Please describe.
The generated SVG file size can be so large in some cases.

Describe the solution you'd like
Use compressed SVG(*.svgz) as the default file format to reduce the generated file size, or add an option to let the users decide the file format.

Additional context
Hi. Thank you for this great project.
The compressed SVG is not widely used because the HTTP server might compress its response, so there is no need to use the compressed one. However, if the SVG file is used locally, I think this file format will save a lot of space.
I don't know if it's difficult to add the support of compressed SVG file. Here are some links about the compressed SVG file. I hope they can help you.
https://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Compression
https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Getting_Started#svg_file_types

[personalizedrefrigerator]

Thank you for the feature request! How big are the SVGs you're getting? Are they primarily strokes, images and text, or a mixture? If primarily strokes, are you resizing/rotating strokes frequently?

I agree that .svgz would be useful, but I'm hesitant to add another runtime dependency to js-draw (e.g. a runtime implementation of Gzip) if it can be avoided.
Additionally, because js-draw runs in a web browser (or a WebView, in the case of Joplin), it can't take advantage of NodeJS's support for GZip, while the plugins and apps that use it (i.e. Joplin) often can. As such, I think it might make more sense to implement this in the Joplin plugin/in Joplin.

For now, I'm going to make this a lower priority than lowering runtime memory (RAM) usage. (At present, in a 13 MiB file with only strokes, js-draw uses roughly 130 MB of RAM.)

[wh201906]

I haven't used this in the realistic scenario, I just tested it in the Joplin by making a lot of strokes then exported the generated SVG file. After that, I found that the SVG file size reaches 30KB+. Based on this result, I guess it's easy to get a large SVG file when taking notes, especially for CJK characters.

Additionally, because js-draw runs in a web browser (or a WebView, in the case of Joplin), it can't take advantage of NodeJS's support for GZip, while the plugins and apps that use it (i.e. Joplin) often can. As such, I think it might make more sense to implement this in the Joplin plugin/in Joplin.

As for me I just hope to reduce the size of SVG file in Joplin. I don't know much about web, so I wrongly post the issue there. If this feature should be implemented in other place, should I close this issue?

[wh201906]

For now, I'm going to make this a lower priority than lowering runtime memory (RAM) usage. (At present, in a 13 MiB file with only strokes, js-draw uses roughly 130 MB of RAM.)

Yeah you are right. The RAM cost is so high.

[personalizedrefrigerator]

I haven't used this in the realistic scenario, I just tested it in the Joplin by making a lot of strokes then exported the generated SVG file. After that, I found that the SVG file size reaches 30KB+. Based on this result, I guess it's easy to get a large SVG file when taking notes, especially for CJK characters.

Additionally, because js-draw runs in a web browser (or a WebView, in the case of Joplin), it can't take advantage of NodeJS's support for GZip, while the plugins and apps that use it (i.e. Joplin) often can. As such, I think it might make more sense to implement this in the Joplin plugin/in Joplin.

As for me I just hope to reduce the size of SVG file in Joplin. I don't know much about web, so I wrongly post the issue there. If this feature should be implemented in other place, should I close this issue?

Keep it open for now! It applies to everything using js-draw. I think adding an example showing how to use NodeJS (e.g. in electron) to gzip js-draw's output.

[wh201906]

Ok

[personalizedrefrigerator]

See laurent22/joplin#8663 for current status/what's making this difficult.