#1135 SVG corrupted: missing image

[Anonymous]

I can generte SVG image using the SVG terminal when I plot any funtion. that's fine. The problem arises when I plot from a matrix. in the SVF there is a link to an unknown image:

in svg file generated:
....
<g style="fill:none; color:red; stroke:currentColor; stroke-width:1.00; stroke-linecap:butt; stroke-linejoin:miter">
<image x='-765.0' y='47.8' width='3242.7' height='747.3' preserveAspectRatio='none' xlink:href='gp_image_01.png'/>;
</g>
....

commands:
set terminal svg size 1000,800 dynamic enhanced
set output 'd:\tmp\sample.svg'
set cbrange [0:200]
set xrange [0:0.5]

set title "tasca"
plot 'file.dat' matrix index 2 notitle with image;

reset;

-----
and the sample data is:

#deficit
100 0
300 0
0 0
0 0
0 0
0 0
0 0
1 0
0 0
102 0
101 0
0 0

[Ethan Merritt]

Seems to work! That's great.

I have a couple of questions..
Why are the routines named recursive_write_foo() ? I see no recursion anywhere in the code. Also, so far as I can see the main function can only ever return "0". There is no other return path. So why are the call sites testing the return? (I ask because it's causing compiler warnings and I want to know the intent before trying to fix them).

Follow-up to you question about closures... If you pass base64_outputfile as the closure, there is no need to have a wrapper function, right?

I think you asked earlier about hooking this to the "standalone" terminal option rather than having a separate "embed" option. I think that would be OK and is probably what people expect "standalone" to do already.

[Dan Sebald]

Here is another version of the patch that addresses:

1) Adding a check on fputc() in the main and finish routines so that they return 0 or 1 rather than just 0.

2) OK, I understand 'closure' now. I've seen this sort of thing with other object-oriented frameworks. It helps to make code thread save as opposed to keeping global information about the object that can be overwritten when the routine is run simultaneously in different threads. What I've done is create a structure for base64 properties and dynamically create and initialize a structure whose pointer can be assigned to "closure". That should be thread safe. Of course the structure is free'd when it is no longer needed.

3) I think the wrapper function is still needed regardless of the closure. There needs to be something that converts the binary PNG data into base64, i.e., the wrapper code. I agree that "recursive" isn't exactly right. I couldn't think of anything better, however. The point is that the wrapper function is not called just once, but many times. For the tiny 2x2 example, the wrapper gets called with small hunks of data about 30 times. How about "piecemeal" rather than "recursive"; that's a more accurate adjective.

4) I too like the "standalone" word. If it needs to be differentiated in the future, then a new word could be used. But I doubt that is going to happen. For the image creation example, any mouse-related contents of the SVG seems the same whether "standalone" is specified or not. So, I removed the "embedded" option and now it is just a few words added to the "standalone" description.

[Ethan Merritt]

OK. Added to CVS. Thanks for the work.

[Dan Sebald]

Thanks. What is the next expected release number down the road?

I missed a "gdImageDestroy(im);" in the non-cairo code. Attached is a patch to make the logic similar to that of the cairo code. That, or just add "gdImageDestroy(im);" right before the last "return 1" in the file. Sorry about that.

[Ethan Merritt]

Got it.