GNOME Bugzilla – Bug 568168
allow to render "holes" with renderers being capable to do so
Last modified: 2009-10-06 19:25:34 UTC
A lot of Dia's bezier code has warnings like "only first BezPoint can be a BEZ_MOVE_TO". This is basically a limitation of the bezier approximation code originally used in the DiaGdkRenderer. It is currently used in the renderer base class DiaRenderer, but there already are some renderers in principle capable to handle move-to within bezier pathes just fine (cairo, svg, probably wmf, ...). An important use case of move-to within a bezier path is rendering holes when filling text outlines. For a glyph like 'O' one gets two pathes i one chunk: the first one describes the outer border, while the second describes the inner border which needs to be substracted from the first shape. Another use case are svg imports like http://svn.gnome.org/viewvc/librsvg/trunk/tests/samples/butterfly.svg - just three svg:path with a lot of holes. With the current code the desired effect is just impossible to get. 2008-01-18 Hans Breuer <hans@breuer.org> * lib/bezier_conn.c(bezierconn_simple_draw) : unused function adapted to split a given bezier rendering at the move-to points into 'easier' pieces * lib/beziershape.c(beziershape_simple_draw) : unused function adapted to render only up to the first move-to within a bezier path with holes * lib/dia_svg.c(dia_svg_parse_path) : instead of splitting into pieces at move-to within a path just return the whole thing * lib/geometry.c(distance_bez_line_point,distance_bez_shape_point) : instead of complaining about "BEZ_MOVE_TO found halfway ..." just calculate it * lib/diarenderer.[ch] : implement DiaRenderer::is_capable_to(RENDER_HOLES) to allow objects code to adapt to specific renderer capabilities * objects/standard/outline.c : render holes if the renderer used is capable to do so. Otherwise fall back to rendering 'inner' shapes with color_white * plug-ins/cairo/diacairo-renderer.c plug-ins/libart/dialibartrenderer.c : implement Renderer::is_capabe_to * plug-ins/wmf/wmf.cpp : intial unused and untested implementation of bezier rendering which should be capable to render holes
Created attachment 126682 [details] [review] move-to handling within (bezier-)pathes as described above missing in the patch (and thus not to be applied before 0.97) : - ensure no renderer not being capable to render holes gets BEZ_MOVE_TO within a path - double-checking of libart rendering capabilities - thorough testing and some risk analysis - everythign I've overlooked
*** Bug 575045 has been marked as a duplicate of this bug. ***
tentative target 0.98
not handled on the Dia XML level, not by svg import. But the rest is pushed: http://git.gnome.org/cgit/dia/commit/?id=fe78bedf0c9ba782aa08cfecae62093ae65dc748