Wrote

Still there is another, more important issue: could you please interpret relative paths with respect to the directory of the current SMath document instead of the current directory? This would create portable documents and enable putting examples in the activebook help system.

I can't do that. More precisely, I don't know how to do it, because SMath Studio does not provide such information. That's why I added CurrentDirectory() function. There is another way to change the current folder. Open the document and then save it via the Save As option. In this case, SMath Studio will change the current path. The path must be changed when the file is opened, but it doesn't. You have to ask Andrey to implement this feature.

I don't know, how Davide managed to do this, but the DataExchange plugin somehow manages to handle relative paths with respect to the current document (despite the help text mentioning the current dir as default path).

In the attached screen shot you see a document, where a formula is exported using a relative path. The file is created in the directory of the currently open SMath document, even if that is not the current system directory (as can be seen in the CurrentDirectory() output).

May be the approach is not available for custom regions. Then a separate function like "DocumentDirectory()" would help, just as the function "SettingsDirectory()" from CustomFunctions, which is used to build the hyperlink targets in the activebook plugin index.

---

Updated. Thank you, Martin. I have looked how he does it. SMath Studio explicitly transmits information about the path of the currently opened document (store.FileName), but it is available only at the time of its evaluation.

Wrote

... but it is available only at the time of its evaluation.

Great, thanks. Seems to work. However, I do not understand what limitation is implied by your statement.

Would it be possible to size the region according to the image size? Perhaps as an option.

I'd also propose to provide sort of image scaling and clipping, with mouse interaction consistent to the xy plot region, i.e.
- zoom by mouse wheel
- move by dragging the image
- resize by dragging the boundary resizing markers
- double click to reset to default (according to feature request above)
This might be sensible only for display of images from files.

Wrote

Wrote

... but it is available only at the time of its evaluation.

Great, thanks. Seems to work. However, I do not understand what limitation is implied by your statement.

This was remark for developers.

Wrote

Would it be possible to size the region according to the image size? Perhaps as an option.

I'd also propose to provide sort of image scaling and clipping, with mouse interaction consistent to the xy plot region, i.e.
- zoom by mouse wheel
- move by dragging the image
- resize by dragging the boundary resizing markers
- double click to reset to default (according to feature request above)
This might be sensible only for display of images from files.

Ok, I'll think about it too. As for svg images, you can change the size of this type of images, but only if the dimensions are not specified in the file. Try these svg-files.

---

svg.zip (5 КиБ) скачан 67 раз(а).

I tried your svg pictures uni. You are right, they can be resized but keeping their aspect ratio.
I suppose there is not a way to respect their aspect ratio by dragging the resizing either of the dragging markers (just asking). Actually, we can make it fit - if we want - by dragging the individual markers separately.

Regards,
Radovan

---

Wrote

As for svg images, you can change the size of this type of images, but only if the dimensions are not specified in the file.

Thanks, this works. In my example, I just had to removing this: width="65.29mm" height="52.71mm"

---

Wrote

Updated. Added support for svg.

[albumimg]318[/albumimg] [albumimg]319[/albumimg]

Great feature, thank you Viacheslav

I tried the method suggested by Martin, It works fine with Jpgfdraw files (save as SVG) but not with Inkscape file (save as SVG or Pure SVG)
sergio

Is it possible, to evaluate the expression in the placeholder of the image region?

Then we would have a neat way to display Maxima generated images using the Draw2D() and Draw3D() functions as described here.

These functions return the file name of the generated image.

There is an svg rendering problem in the image region. The attached file displays differently in TpX, IE and SMath/Image region. Look at the rightmost line in the diagrams. The only correct rendering is by TpX. Of course, I cannot guarantee that gnuplot produces correct svg code. The gnuplot input files produced by Maxima are correct.

---

gnuplot_input.zip (1 КиБ) скачан 57 раз(а).

Hello Martin,

Hmm...I might missed something, but I can not see the plots in the SMath "Diffusion.sm" file. I expected to see them (as usual) but the regions are empty and the *.svg files are not in the active directory (dir variable). See the picture and the log file please.

Regards,
Radovan

EDIT: Strange , I managed somehow to get those bargraphs - right bars were decreseing ( by moveing dir:= ). On the third one I saw th problem at the end - but can not reproduce anymore. Still empty regions???
EDIT2: It seems that Maxima restart and few recalculations will bring the plots (second picture)

---

Updated. SMath Studio 0.96.5146 required.

h0.01 - if you remove this then you'll get the right result.


P.S. Now the background is not removed.

There might be some issues which I did not yet mention.

1. this all applies to SMath 0.96.4909, as the image region is (was) not yet available for the new build (updated Maxima is available on SVN, but still in testing)
2. There might be a timing/robustness issue, it is a bit risky to use identical file names for different plots in the sheet. I changed the sheet such that you get different file names. The images should be produced upon opening or recalculating the sheet.

@uni: Thanks for the update. I confirm that removing h0.01 from wherever in the svg file mitigates the problem (in the old and in the new ImageRegion version). What does h0.01 say? Perhaps that can be avoided by particular plot settings? Just like with the scaling, where it proved possible to get scalable svgs without regexping the svg file.
Another question: Is that a gnuplot bug which I should report there or is this a problem of the image region (and of the IE)?

---

Цитата

What does h0.01 say?

8.3.4 The "lineto" commands

Perhaps this is a bug in the SharpVectors library that I use.

Wrote

Perhaps this is a bug in the SharpVectors library that I use.

I do not know why gnuplot draws a very short horizontal line at the top of the last blue vertical bar. This might be a bug but should essentially be invisible with butt line ends.
The IE rendering and the image region show this horizontal line much too long.
On top of this, the image region somehow wrongly joines the horizontal and the vertical line.

I asked a question on the support forum: Is this a bug?

Wrote

Another question: Is that a gnuplot bug which I should report there or is this a problem of the image region (and of the IE)?

I've noticed the same issues both in chrome and firefox... so, is a bug in the image or in all the major browers :-p

Here is my post to a gnuplot forum.

EDIT: and here is the response, saying that the horizontal line was a fix for viewer problems in the past but should not be visible. There is no fast way to fix the problem.


There are some posts in the group, saying that most viewers render svg wrongly, but that would be no reason to modify the svg export, as it is the fault of the viewers.



Alternativly, Maxima/Gnuplot could export eps or pdf. Uni, if you can display that in a scalable way, then I could possibly switch to that terminal. I attached two corresponding files (had to zip the eps, because such attachments are not allowed in the forum)

---

myfile.zip (4 КиБ) скачан 55 раз(а).