svg export from on-line resources is at random scaling

Lenore shared this problem 1 year ago
Not a Problem

From the app on my computer, I can choose how the units in the GeoGebra window will be represented in an svg export. That means I can get files at known scales out of GeoGebra. However, when I upload that applet as a GeoGebra resource, there is no dialog asking about scaling. Worse, the export doesn't make doesn't make a uniform decision about how to scale the drawing. It appears to scale the viewing window to about 10cm x 10cm regardless of the units in view. Because the viewing window is always a bit bigger than the object being exported, this means the actual drawings are even more randomly scaled than just the arbitrary window scaling. For instance, I'm trying to draw sets of gears to laser cut. They all have to be cut to the same scale obviously or they won't work together. Yes, I can afterwards measure the diameter of the central hole that is the same for all of them and then compute the rescaling value for each gear and then rescale them in Inkscape. But why do I have to do all this work? There is a numerical scale built into GeoGebra. Use it consistently.

Comments (20)

photo
1

1) Please say which version you are using


2) Please always upload your .ggb file when you are reporting a problem

photo
1

It is the online version that misbehaves and no version numbering seems to be accessible for that. An example of the misbehavior can be seen with https://www.geogebra.org/m/k9mcy8qf but the behavior is generic to svg export from the on-line applet. A laptop version that shows correct behavior is <?xml version="1.0" encoding="utf-8"?>

<geogebra format="5.0" version="5.0.613.0" app="classic" platform="d" xsi:noNamespaceSchemaLocation="http://www.geogebra.org/app...; xmlns="" xmlns:xsi="http://www.w3.org/2001/XMLS...; >

</geogebra>. The correctly behaving file in that version (which is what is uploaded to the link above) is attached.

photo
1

Help -> About for the version number


Sorry, the export is working as intended (the online version doesn't assign a notional scaling to cm). As you've noted you can post-process in Inkscape

photo
1

That may be the intended functionality. However, it is not a useful functionality because the export scale is not only unknown but unless very picky set-up is made is also unknowable because the exported file is a single entity (including boundary white space) so that even if you know what size the drawn part should be, there isn't typically any way to measure what size it came out to be so there isn't any way to choose how to rescale. The only way I have found around this is to disable pan and zoom and force the window to zoom to exactly the edges of the figure and force the window to be square but that required a whole lot if finagling with adjusting the window size before I uploaded and then again after I uploaded so that the graphics window online is both exactly square and exactly the size of the object drawn. That a lot of extra work for every single use that could be saved by scaling the export to the coordinates in the drawing instead of scaling them to the (completely arbitrary) window coordinates.

photo
1

That's easy to solve, you can specify corner and corner2, and make an "Export" button see https://wiki.geogebra.org/e...


(or make GeoGebra Points called Export_1 and Export_2)

photo
1

I think that's what I'm doing with ZoomIn in effect (zooming to the size of the object) but since I can't guarantee that the actual window is perfectly square, I either have two declare to scaling corrections to be used after export to account for the out-of-squareness, or I have to tweak the window until it's at least really close to square.


Can you please explain to me the objection to exporting scaled to the axes drawn in the window (which is what everything that has been drawn is based on). I'm completely baffled as to what use case would prefer scaling to an unknown and arbitrary pixel size of a window over scaling to the values in the drawing.


Why force zooming in so that figures exactly touch the edge of the window in order for the rescaling value to be knowable? What is gained here?

photo
1

Please read my previous post carefully and actually try it out

photo
1

I've read your comment and the ExportImage command wiki about 11 times and I'm getting nowhere. The only mention of corner I find on that wikipage is for specify where to put the image that has been taken but I want to specify where the image is taken (so that I don't have to do all the finagling with window size and zooming). I think from context and syntax that these corner commands are not the same as the usual ones that tell the pixel(?) coordinates of the corners of the viewing window. I had a simpler file and tried to put the export button in that. In version bending0.ggb nothing seems to happen (except a screen blink). Certainly no file is created. I tried the command without the corner designations but that also simply blinks the screen and produces nothing anywhere on my computer - at least not searchable, not in the folder of the ggb file and not on the desktop. Even running the command directly in the input bar has zero effect. Hmm. Maybe this is something that only works in the Classic 6 interface? The export actually happens in the Classic 6 interface. Putting the corners means I do know exactly what size the image _should_ export as. The actual size still depends on the zoom (and possible unequal scaling of the screen) and the corners are only obeyed if they are on screen; if one is off screen the export cuts off at the edge of the window. So this is a slight improvement on what I had cobbled together but still is rather ugly. Consider the process: make a scale drawing, export, rescale the drawing the size you already drew things to be in the first place, then go on with the rest of your project

photo
1

bending0.ggb
which is where?

photo
1

I didn't attach it b/c switching to 6 made things work. Here are both versions; neither of which works in 5. 0 works in 6 so I didn't try 0b.

photo
1

Well. I spoke a bit too soon. The export button works for me on my Mac on Mojave in any browser I try (Firefox, Safari, Chrome, Opera). However, my students say and I can verify that I cannot export from Safari, or Firefox on an iPad. I can export from Chrome by allowing a pop-up but the other two don't even get to asking about a pop-up. See for instance https://www.geogebra.org/m/....

photo
1

Try enabling the menubar then they can access File -> Export Image

photo
1

I'm missing something. How does this not get me back to the original problem of needing to have a perfectly square window zoomed in exactly the right amount so that the scaling factor which must be applied afterwards is known?

photo
1

Did you try it?

photo
1

Try what? Doing exactly what I did before that was unsatisfactory? 3:43am just to keep you happy, I will now repeat a process that did not work in the past.


  1. Go to https://www.geogebra.org/m/pwcksrsq and edit it.
  2. Click Advance Settings and check Show Menu.
  3. On laptop, go to 3bar menu, Export as, svg.
  4. Open file in Inkscape. Object is, just as before, the drawing I want plus some random white space around it so the drawing cannot be accurately sized.
  5. Still on laptop, redo but click the export button first to see if that changes something. Export still has unknown amount of whitespace added.
  6. Still on laptop, try the Export Image menu item instead. That produces a png which isn't particularly helpful because now resolution artifacts get added into the mix. (3:53am)
  7. On iPad, Export as .svg opens in a browser window and then I can put send it somewhere off the iPad. That version also as an unknown amount of extra whitespace added. (4:05am)

In desperation, try using the export button trick to repaste the image to the ggb window and see if downloading that is any better.

Attempt 1: Change existing script of

ExportImage("filename", myname, "type", "svg", "view", 1, "corner", (-scale/2,-scale/2), "corner2", (scale/2,scale/2))

to

pic1=ExportImage("filename", myname, "type", "svg", "view", 1, "corner", (-scale/2,-scale/2), "corner2", (scale/2,scale/2))

but where is this pic1 going to go? Shrug. Try it anyhow. That adds a copy of the gear to the viewing window when I try it in ggb5 on the laptop. That isn't helpful. I don't want a second copy of the gear even resized to fit the window.


Not sure where to go from here that isn't, as I already indicated, back to using zoomin to fill the window with the drawing and trying to compensate for the window possibly (probably) not being square carefully so that at least there can be no extra white space on one of the two axes.

laptop is running Firefox 83.0 on MacOS 10.14.6 (Mojave)

iPad is iOS 13.7 with whatever Safari version that implies.

photo
1

For the menu option you need to make points Export_1 and Export_2


https://wiki.geogebra.org/e...

photo
1

I thought from your suggestion that "To crop an export, make the Points Export_1 and Export_2 to define the rectangle to crop" in the wiki perhaps meant "If the Points Export_1 and Export_2 have been defined, then any image downloaded via the Download As menu will automatically use those two points to define the lower-left and upper-right corners of the rectangle to be exported regardless of the view. If those points do not exist, the view exactly as shown in the window will be exported". But that does not seem to be the case. See https://www.geogebra.org/m/pwcksrsq created from .ggb attachment. Screen shot of the boundaries of the exported object also attached (the goal is to have the boundaries snug against the object on all 4 sides).

photo
1

These coordinates don't look right:/P59X1GQAAAABJRU5ErkJggg==

photo
1

You are right. (Though I thought I did an export button trial at the same time that came out right but was using those same point. Must be my imagination.) I notice that when I use these two points to define the export via command attached to a button and compare the results of using the button to the results of using the menu item, the results differ by just under a pixel and a half in size (out of 344 pixels for one version). I have not checked to see how the difference is affected by different locations of the Export_1 and Export_2 points.


Thanks for pointing me to that wiki page and for elucidating its contents. I think it would be quite helpful to clarify there that while the two points may be used in the export command that the page is mainly about, they can also be used independently of those commands. That point is, to me at least, not at all clear from the brief note on them in the wiki.

photo
© 2022 International GeoGebra Institute