Inkscape: A Vector Drawing Tool

Bezier curves drawn, where svg file requires circular arcs

Reported by Xypron on 2010-10-01
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Unassigned
inkscape (Debian)
Confirmed
Unknown

Bug Description

Package: inkscape
Version: 0.47.0-1

The following svg file requires only straight lines and circular arcs (rx =
ry):

<svg width="930.42641px" height="640.00000px"
xmlns:xlink="http://www.w3.org/1999/xlink" zoomAndPan="magnify"
contentStyleType="text/css" viewBox="-0.10000 -0.10000 4.65213 3.20000"
preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg"
version="1.0">
<path style="fill:#0066ff;stroke:none; fill-opacity:1;" d="
M1.90000,0.30000
L1.90000,0.87500
L2.02500 0.87500
L2.02500 0.54367
A0.30000,0.30000 0 1,0 1.90000,0.30000
Z
M2.02500,0.30000
a0.17500,0.17500 0 0,1 0.17500,-0.17500
a0.17500,0.17500 0 0,1 0.17500,0.17500
a0.17500,0.17500 0 0,1 -0.17500,0.17500
a0.17500,0.17500 0 0,1 -0.17500,-0.17500
Z" />
</svg>

Instead of arcs Bezier curves are drawn.

See Bug 331836 - union of a circle and a square creates curves - not arcs
See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598791

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages inkscape depends on:
ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib
ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra
ii libcairomm-1.0-1 1.8.4-3 C++ wrappers for Cairo (shared lib
ii libfontconfig1 2.8.0-2.1 generic font configuration library
ii libfreetype6 2.4.2-1 FreeType 2 font engine, shared lib
ii libgc1c2 1:6.8-1.2 conservative garbage collector for
ii libgcc1 1:4.4.4-8 GCC support library
ii libgconf2-4 2.28.1-3 GNOME configuration database syste
ii libglib2.0-0 2.24.2-1 The GLib library of C routines
ii libglibmm-2.4-1c2a 2.24.2-1 C++ wrapper for the GLib toolkit (
ii libgnomevfs2-0 1:2.24.3-1 GNOME Virtual File System (runtime
ii libgomp1 4.4.4-8 GCC OpenMP (GOMP) support library
ii libgsl0ldbl 1.14+dfsg-1 GNU Scientific Library (GSL) -- li
ii libgtk2.0-0 2.20.1-1+b1 The GTK+ graphical user interface
ii libgtkmm-2.4-1c2a 1:2.20.3-1 C++ wrappers for GTK+ (shared libr
ii libgtkspell0 2.0.16-1 a spell-checking addon for GTK's T
ii liblcms1 1.18.dfsg-1.2+b3 Color management library
ii libmagick++2 7:6.5.8.3-1 object-oriented C++ interface to I
ii libmagickcore2 7:6.5.8.3-1 low-level image manipulation libra
ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio
ii libpangomm-1.4-1 2.26.2-1 C++ Wrapper for pango (shared libr
ii libpng12-0 1.2.44-1 PNG library - runtime
ii libpoppler-glib4 0.12.4-1.1 PDF rendering library (GLib-based
ii libpoppler5 0.12.4-1.1 PDF rendering library
ii libpopt0 1.16-1 lib for parsing cmdline parameters
ii libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++
ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3
ii libwpd8c2a 0.8.14-1 Library for handling WordPerfect d
ii libwpg-0.1-1 0.1.3-1 WordPerfect graphics import/conver
ii libx11-6 2:1.3.3-3 X11 client-side library
ii libxml2 2.7.7.dfsg-4 GNOME XML library
ii libxslt1.1 1.1.26-6 XSLT 1.0 processing library - runt
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages inkscape recommends:
ii imagemagick 7:6.5.8.3-1 image manipulation programs
ii libwmf-bin 0.2.8.4-6.1+b1 Windows metafile conversion tools
ii perlmagick 7:6.5.8.3-1 Perl interface to the ImageMagick
ii pstoedit 3.45-8 PostScript and PDF files to editab

Versions of packages inkscape suggests:
pn dia | dia-gnome <none> (no description available)
ii libgnomevfs2-extra 1:2.24.3-1 GNOME Virtual File System (extra m
pn libsvg-perl <none> (no description available)
pn libxml-xql-perl <none> (no description available)
ii python 2.5.4-9 An interactive high-level object-o
pn python-lxml <none> (no description available)
ii python-numpy 1:1.4.1-4 Numerical Python adds a fast array
pn python-uniconvertor <none> (no description available)
pn ruby <none> (no description available)
pn skencil <none> (no description available)
pn ttf-bitstream-vera <none> (no description available)

-- no debconf information
--

Xypron (xypron) wrote :

p.png shows incorrect rendering in export file.

Xypron (xypron) wrote :

Test data

tags: added: path
~suv (suv-lp) wrote :

Reproduced with Inkscape 0.48+devel r9802 on OS X 10.5.8

Changed in inkscape:
importance: Undecided → Medium
status: New → Confirmed
tags: added: shape-editing svg
removed: path
~suv (suv-lp) wrote :

Most likely related to or duplicate of:
Bug #167616 “path grammar: arc (A) support on write”
Bug #168218 “circles and arcs are incorrectly drawn (bezier appoximation) ”

The fix mentioned in bug #168218 only changed the formula, but AFAIU not the fact that bezier curves are used to represent circles and arcs in Inkscape; the patch originally fixes bug #332735 “Inaccurate rendering of circular arc of angle 45 degrees.”:
SVN 20771 -> BZR 7366
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/7366>

Xypron (xypron) wrote :

The error is reproducable in
Inkscape 0.48.0 r9654

Alvin Penner (apenner) wrote :

the distortion of the shape of the object appears to be related to the use of the attribute "viewBox" in the svg header. The size of the view box is precisely 200 times smaller than the size of the page, so when it gets rendered the original svg coordinates must be expanded by a factor of 200, leading to the possibility of round-off error.

attached is a modified version. I deleted the viewBox from the original file and instead manually expanded the object to make it visible, and it now appears to be rendered properly.

- how was this image originally produced?

~suv (suv-lp) wrote :

@Alvin - why do other SVG viewers render the file as expected (Squiggle Batik 1.7, Firefox 3.6.9, Safari 5.0.2)?

~suv (suv-lp) wrote :

oops - sorry, overread 'possibility of round-off error.' ;)

~suv (suv-lp) wrote :

s/overread/missed/

Alvin Penner (apenner) wrote :

good question, even my obsolete Adobe SVG viewer in IE8 renders the original file correctly.

There is indeed some numerical error occurring here (in Inkscape). I guess my point is that it is _not_ related to the difference between a Bezier curve and a true arc. If it was related to the difference between a Bezier and a true circular arc, then all renderers would respond the same way to this file. The original file contains only true circular arcs, no Bezier curves. The Inkscape renderer is quite capable of distinguishing between circles and Bezier curves, and showing the difference between them, but the error in this case is quite a bit less than the error showing up in this image.

Alvin Penner (apenner) wrote :

    sorry, I misspoke myself. The situation is more complicated than I thought. It is true that the original file contains only true arc elements, no Bezier curves. But when you edit it, you see the handles typical of Bezier curves, you do not see the handles typical of an arc. (using the Node tool to draw this distinction) The reason apparently is that the object has no sodipodi attributes, which suggests that perhaps it was not created by Inkscape. In the absence of sodipodi attributes, the editing and probably also the rendering will be done using Bezier curves.
    So the question is, why is the Bezier approximation so poor. The reason is that the arc angle is too high. In the curved portion of the 'p', the outer curve section is represented by only 2 Bezier curves and they both have an arc angle greater than 90 degrees. The Bezier approximation to an arc very rapidly becomes very poor if the arc angle is allowed to be higher than 90 degrees.
    So the next question is, why is file p_new.svg better, after manually expanding the image? Because this file contains 8 Bezier curves, not 2, in the same curved portion of the 'p' character.
    I suspect, but obviously cannot prove, that the approximation procedure that converts from arc to Bezier probably has some numerical cutoff that determines how many segments to use and that this cutoff value is in absolute units not scaled units, so that when you convert a tiny image (200 times smaller than normal) you get fewer Bezier segments than when you convert a normal size image, leading to a situation where a very tiny image is not as well-formed as a normal size image.

Hello Alvin,

the SVG file in question was create manually. It is rendered correctly
in Firefox and other browsers because it is SVG compliant.

Obviously Inkscape implements only part of the SVG specification. It
should be changed to support elliptic arcs without approximation.

Best regards

Xypron

Alvin Penner wrote:
> sorry, I misspoke myself. The situation is more complicated than I thought. It is true that the original file contains only true arc elements, no Bezier curves. But when you edit it, you see the handles typical of Bezier curves, you do not see the handles typical of an arc. (using the Node tool to draw this distinction) The reason apparently is that the object has no sodipodi attributes, which suggests that perhaps it was not created by Inkscape. In the absence of sodipodi attributes, the editing and probably also the rendering will be done using Bezier curves.
> So the question is, why is the Bezier approximation so poor. The reason is that the arc angle is too high. In the curved portion of the 'p', the outer curve section is represented by only 2 Bezier curves and they both have an arc angle greater than 90 degrees. The Bezier approximation to an arc very rapidly becomes very poor if the arc angle is allowed to be higher than 90 degrees.
> So the next question is, why is file p_new.svg better, after manually expanding the image? Because this file contains 8 Bezier curves, not 2, in the same curved portion of the 'p' character.
> I suspect, but obviously cannot prove, that the approximation procedure that converts from arc to Bezier probably has some numerical cutoff that determines how many segments to use and that this cutoff value is in absolute units not scaled units, so that when you convert a tiny image (200 times smaller than normal) you get fewer Bezier segments than when you convert a normal size image, leading to a situation where a very tiny image is not as well-formed as a normal size image.
>
>

Alvin Penner (apenner) wrote :

    I believe that I have found the source of the problem, and that it is indeed caused by a poor conversion formula when converting from an arc to a Bezier (blush).
    When you originally load the svg file, the XML editor shows the path in the form of its arc representation, while the Node tool shows Bezier control arms (very confusing). If you use the Node tool and jiggle one of the Bezier points slightly to force a refresh, then the XML editor will show the Bezier path that the curve has been converted to. By doing this for a few different cases, I have confirmed that the formula that is being used in the conversion from arc to Bezier form is:

d/r = theta/3

where:

d = Bezier control arm length
r = radius
theta = angle of arc

This formula is a correct zeroth-order approximation as theta approaches zero, but it is not at all suitable at the large arc angles that are being encountered in the attached image. A better formula to use would be 4*tan(theta/4)/3, as implemented in Bug 332735.

    Unfortunately, I do not know where to apply this patch, so this is a request for technical assistance.

    The file src\sp-ellipse.cpp is apparently responsible for performing the arc-to-Bezier conversion for those objects that have sodipodi attributes. Somewhere there must be a parallel file that is used for the conversion from arc-to-Bezier for those objects that do not have sodipodi attributes, but I have no clue where that file might be physically located.

 Any help in searching would be welcome.

Changed in inkscape (Debian):
status: Unknown → Confirmed
Alvin Penner (apenner) wrote :

a patch has been proposed at : http://old.nabble.com/rendering-arcs---Bug-653315-td29894997.html

Alvin Penner

Alex Valavanis (valavanisalex) wrote :

Related bug/duplicate?..

bug #997571 <Inaccurate arcs>

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.