Bug status?

SharkD shared this problem 7 years ago

On Wikipedia I noted a number of bugs/issues related to using GeoGebra (link). Namely:

  1. Currently, you cannot specify image output dimensions directly in pixels. You have to 1) determine the desired output size in pixels; 2) set the dots-per-inch of the image output in GeoGebra; 3) convert the pixel dimensions to inches taking into account the dpi you've specified; 3) convert the values in inches to centimeters; 4) continually modify the "scale" parameter of the export dialog until the output dimensions match your calculated values; and 5) hope there are no rounding or other errors. (See image at right.)

  2. If you want to set the pixel dimensions of the viewing area and coordinate axes to precise amounts, you have to 1) decompress the GGB file; 2) modify the decompressed XML file in a text editor; 3) recompress the XML file into a GGB file; and 4) hope that GeoGebra doesn't override these settings the next time you load the file, keeping in mind that resizing the application window or side panels automatically and irretrievably modifies these values, causing you to have to restart the process from the beginning.

  3. When exporting as SVG, the program 1) stores one set of values for SVG element positions; 2) stores another set of values to scale and reposition the elements to match what is seen in the application window; and 3) stores a third set of values for determining the size of the output image's viewport. Meaning you will have to juggle all three sets of values when trying to modify the image for external rendering.

  4. There are bugs when saving the size of the export image's viewport when explicitly defining an "export area" in GeoGebra. GeoGebra has a feature by which you can define the export area inside a drawing using "Export_1" and "Export_2" points, but this feature seems to be broken for SVG images.[3]

  5. PNG output suffers from antialiasing issues when exporting as a 32-bit image file. The mask utilizes only 1 bit of color information instead of all 8 bits that are available, and the "antialiasing" itself is done in the body of the image instead of the alpha channel where it belongs. Meaning that image is transparency is effectively limited to what you see in GIF images with 1 bit transparency, and that you will see traces of the original document's background color when overlaying the image over another image or document. [This issue has been fixed in the beta version. [4]]

  6. There is no way to enter color values directly using RGB components, but instead a limited palette to choose from. There is also no way to determine which palette entry an object is using, except by guessing based on what you see. Finally, the default colors for objects do not exist in the palette (meaning you cannot revert back to the original color after you have changed it), and there is no way to specify a different set of values as the defaults.

I was wondering what the status of these bugs were in both the 3.x and 4.x code branches?

As a comparison, here's how things stand with C.a.R.:

  • You can enter RGB and HSL color values directly, meaning the range of possible colors (e.g. palette) is much greater.

  • For PNG images you can specify a number of additional parameters to control output dimensions (though it may still be necessary to manually convert from centimeters to inches at some point if you are trying to achieve pixel-perfect results).

  • Sizes and dimensions are exported more directly into the SVG file without the need for adjusting three separate sets of values when editing the file by hand as in GeoGebra's SVG output.

  • You can set the dimensions of the drawing pane to exact amounts in pixels.

  • You cannot set the coordinate units to exact amounts in pixels, though by default the coordinate axes are set to fill the drawing pane (which ''can'' be configured) exactly with plus/minus eight units along the horizontal.

  • The image export options for SVG are not as detailed as for PNG.

  • There's no way of specifying the export rectangle directly from within the drawing itself as in GeoGebra, other than by resizing the drawing pane.



Maybe I should use the word 'oversights' instead of 'bugs'?

Comments (5)


Ad RGB: you may go to advanced => dynamic color and set R,G,B to e.g. 1/2, 1/2,1/3. This wasn't an issue even in 3.2. Since 4.0 you can use HSL as well.


Good catch!


I took a look at these unresolved issues in GeoGebra Here is my analysis. (Sorry I did not also number the issues in my first post.)

  1. Improved. You can now set 1 units = N cm and 100 px = N cm. However, you still cannot set 1 units = N px. A potential workaround can be found here.
  2. Not fixed.
  3. Improved. The viewbox and drawing objects seem to be using the same scale now, at least. The lack of decimal places in the SVG viewbox when exporting makes me suspicious, however.
  4. I only sort of recall what problems I was having when I wrote the above, and I think that issue was fixed. However, the exported drawings still do not line up perfectly in the picture frame. There are gaps around the edges sometimes. See here. Is it due to rounding or precision errors when converting between GG units, pixels and cm?
  5. Fixed.
  6. A workaround exists by using Dynamic Colors.


Correction: I just tried #2 again, and I couldn't figure out how to edit the XML file to adjust the drawing pane size. I tried changing the euclidean view size, but the program ignores and overrides me. I am able to change the window dimensions, but that is not really what I want. :(


For #6 there is now a way to add colors with specific RGB code directly using the + button.

© 2019 International GeoGebra Institute