After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 568168 - allow to render "holes" with renderers being capable to do so
allow to render "holes" with renderers being capable to do so
Status: RESOLVED FIXED
Product: dia
Classification: Other
Component: general
devel
Other All
: High enhancement
: 0.98
Assigned To: Dia maintainers
Dia maintainers
: 575045 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-01-18 11:50 UTC by Hans Breuer
Modified: 2009-10-06 19:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
move-to handling within (bezier-)pathes as described above (10.63 KB, patch)
2009-01-18 11:57 UTC, Hans Breuer
needs-work Details | Review

Description Hans Breuer 2009-01-18 11:50:44 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
Comment 1 Hans Breuer 2009-01-18 11:57:10 UTC
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
Comment 2 Hans Breuer 2009-03-12 19:49:55 UTC
*** Bug 575045 has been marked as a duplicate of this bug. ***
Comment 3 Hans Breuer 2009-04-11 12:03:17 UTC
tentative target 0.98
Comment 4 Hans Breuer 2009-10-06 19:25:34 UTC
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