On Wikipedia I noted a number of bugs/issues related to using GeoGebra (link). Namely:
- 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.)
- 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.
- 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.
- 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.
- 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. ]
- 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'?