octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58429] Export of plotted circles to SVG could


From: Michael Leitner
Subject: [Octave-bug-tracker] [bug #58429] Export of plotted circles to SVG could use SVG circle primitive
Date: Tue, 26 May 2020 03:29:34 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #7, bug #58429 (project octave):

I don't know anything about OpenGL, but I know about SVG: as far as I know, a
<circle> element is typically rendered by the renderer converting it first to
a cubic Bezier curve, with four segments to make up the full circle, and then
using the general routines for Bezier curves. You see the resulting choice of
control points if you draw a circle in Inkscape and convert it to a path. That
said, in a renderer that uses such an approach, there would absolutely be no
visual difference if Octave were to output such a Bezier curve for circular
markers. In particular, the initial complaint about "hairy" or "corroded"
appearance would be solved. And it seems that OpenGL handles cubic Bezier
curves natively.

Further, it could make the code simpler: you would not need to decide how many
points you have to use to make the plot satisfactorily smooth (depending on
the size of the marker), but always use four Bezier segments and let the
library think about how this is best rendered, both for on-screen plotting and
for plotting into a file. Of course, this is still much less efficient than
directly outputting <circle> elements, but this is something that OpenGL
seemingly does not know about. However, perhaps it is possible to use relative
instead of absolute positions in the svg output, then it would at least
compress to the same size (as the position of the marker is always encoded by
the first control node, while the remaining 12 nodes/control points that make
up the rest of the path statement are always at the same relative positions).
And this would then indeed be amenable to postprocessing. 

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58429>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]