Bug 63633

Summary: Markers in svg exported as pixels
Product: cairo Reporter: Heye <glxhf>
Component: svg backendAssignee: Emmanuel Pacaud <emmanuel.pacaud>
Status: RESOLVED WORKSFORME QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: jean.brefort
Version: 1.12.2   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 68382    
Attachments: svg exported from gnumeric
Sample showing the issue
Ugly hack which "fixes" (= work arounds) the issue.
markers.png

Description Heye 2013-04-17 09:56:47 UTC
Created attachment 78128 [details]
svg exported from gnumeric

In svg images exported from gnumeric the markers are exported as pixels (example attached). Lines and labels are okay. This problem appeared after I upgraded to Ubuntu 12.10. Svg files that I saved with earlier versions still work fine.

I use gnumeric 1.10.17 and libcairo2 1.12.2-1ubuntu2.2.

This has been initially reported to gnumeric but they assured me the problem is related to cairo.

https://bugzilla.gnome.org/show_bug.cgi?id=698162
Comment 1 Uli Schlachter 2013-04-17 15:33:01 UTC
Since you say that this used to work and since you already test with cairo git master (did you?): Could you git bisect this issue?

If not, assume that I have no clue what I am doing (I don't even know what gnumeric does) and give me a step-by-step-for-idiots list of things to do where I get the wrong result at the end (and how I (easily) see that the result is wrong).
I cannot promise anything, but I might be bored enough to learn more about cairo-svg and perhaps even figure this issue out.
Comment 2 Heye 2013-04-17 16:05:43 UTC
Sorry, I don't know how to test with cairo git master but here is how you can reproduce the bug:

Open gnumeric and put in numbers in a few cells, select them and then create a chart. As chart type you can use anything that has markers, e.g. an x-y plot. After you created the chart right-click on it and choose 'save as image'. This will allow you to export the image as svg. If you now open the saved image with a vector graphics programme you will see that axis labels and lines are vectors whereas the markers consist of pixels. They used to be vectors, too, but some change must have caused them to be exported as pixels which looks quite messy.
Comment 3 Jean Bréfort 2013-04-17 16:18:49 UTC
Created attachment 78144 [details]
Sample showing the issue

Running this simple code shows the issue. Looks like this happens since the introduction of recording surfaces.
Comment 4 Uli Schlachter 2013-04-17 17:24:29 UTC
Being too slow to read comments, I tested with gnumeric. Since I had no starting point, I used something ancient (I think it was 1.8). The problem is reproducible. Git bisect points fingers at:

$ git bisect bad
99fa5ff6c211b96326484f80fe91ead0860c3a23 is the first bad commit
commit 99fa5ff6c211b96326484f80fe91ead0860c3a23
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Aug 13 20:07:57 2011 +0100

    snapshot: Defer acquisition
    
    Fixes 'xlib-expose-event' but triggers an infinite loop in self-copy.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

:040000 040000 a0f06d6d96ce43760c2b3283a2fbd0fbbb42b8ef b394682c7b781c5b9021fb8740717d756415b118 M	src

So that it doesn't get lost, here is the bisect log (all the skips are due to cairo-debug.c:37:41: fatal error: cairo-image-surface-private.h: No such file or directory):

git bisect start
# good: [6b3aa86b1c5b2fce3e56b43142c4ec2664a37032] Increment cairo version to 1.8.0.
git bisect good 6b3aa86b1c5b2fce3e56b43142c4ec2664a37032
# bad: [e66e9ac12e3e11af76f14e8de3cfee72d4299864] win32: fix corrupted drawing
git bisect bad e66e9ac12e3e11af76f14e8de3cfee72d4299864
# good: [2325d755b03958d8ead9a995c0d1d03e4f93af0c] gl: Pretty print the error GLenum.
git bisect good 2325d755b03958d8ead9a995c0d1d03e4f93af0c
# good: [b11b89e8e0c6cb0a05c9de69e3235bedc0c27756] pdf: check if smask is bilevel and encode as such
git bisect good b11b89e8e0c6cb0a05c9de69e3235bedc0c27756
# bad: [38a242a380d24c669f10dd542c3bab606434b8ad] spans,image,gl: Add fast-path for simple copies
git bisect bad 38a242a380d24c669f10dd542c3bab606434b8ad
# bad: [30eac7b2c5a3a2a9c5de4886cdd38666ef19cddb] test: Add line-width-large-overlap
git bisect bad 30eac7b2c5a3a2a9c5de4886cdd38666ef19cddb
# bad: [0101a545793291d0fe76b765ba8392ade5faa1a1] time: Add cairo_time_t type
git bisect bad 0101a545793291d0fe76b765ba8392ade5faa1a1
# bad: [8f99e926c8b1a8fa7f7e0d828a96bac6dc1fe39c] paginated: unwrap subsurfaces during context creation
git bisect bad 8f99e926c8b1a8fa7f7e0d828a96bac6dc1fe39c
# good: [e7bd4c93e320325b09e6a2cc8c3d9547c7b0d1f2] util/show-traps: Cache the rendering of the traps+edges
git bisect good e7bd4c93e320325b09e6a2cc8c3d9547c7b0d1f2
# skip: [73b87334a401a7705f674429d55bb5d0bc559c17] surface: Don't modify operator
git bisect skip 73b87334a401a7705f674429d55bb5d0bc559c17
# skip: [487c5e4d3a5aa5e723bd7b5d418a6b7a9313f5a8] recording: replay_all is meant to mean REPLAY && ALL!
git bisect skip 487c5e4d3a5aa5e723bd7b5d418a6b7a9313f5a8
# skip: [6d1c0e6d28ef61efbfa8f06f13840fd151cfb07e] Fix pollution from skia commit
git bisect skip 6d1c0e6d28ef61efbfa8f06f13840fd151cfb07e
# good: [a3d2d5b42b769241e888a34c3edd015619560431] script: Remove reference to image-surface-private
git bisect good a3d2d5b42b769241e888a34c3edd015619560431
# skip: [4862aadb0fd1e5b7ea2710d56ff4984f3761611d] surface-wrapper: Initialise clip to NULL
git bisect skip 4862aadb0fd1e5b7ea2710d56ff4984f3761611d
# good: [02da8c7efb007d046f95456734968d7e9335a7af] default-context: Tidy push-group
git bisect good 02da8c7efb007d046f95456734968d7e9335a7af
# skip: [9d5d46e8466f9417febfdefef6707bae9818b02d] bo-rect: One step too far...
git bisect skip 9d5d46e8466f9417febfdefef6707bae9818b02d
# bad: [8a90b22897b6460b3396b9959383131039bd9ce2] subsurface+recording: handle recursion
git bisect bad 8a90b22897b6460b3396b9959383131039bd9ce2
# bad: [bca9400aec5c11e402758a2e06c8be560e64b78f] recording: break self-copy loop
git bisect bad bca9400aec5c11e402758a2e06c8be560e64b78f
# skip: [a37ed264ed96d1b9f5ebc634d64137b71872c762] pdf: Propagate NOTHING_TO_DO
git bisect skip a37ed264ed96d1b9f5ebc634d64137b71872c762
# skip: [279f6ceb595412bef165a808f05caa3044ef102c] Only reduce the clip if it is not in active use for the operation
git bisect skip 279f6ceb595412bef165a808f05caa3044ef102c
# good: [be1ff2f45fdbc69537e513834fcffa0435e63073] xlib: Set the clip_region for glyphs
git bisect good be1ff2f45fdbc69537e513834fcffa0435e63073
# skip: [ed324fb3a114faeab4b7844869d2269892a2417e] recording-surface: Don't store the transient error when returning the path
git bisect skip ed324fb3a114faeab4b7844869d2269892a2417e
# good: [2e545672ba14fb49455ce501ded21efd18df1a65] perf/micro: diagonal lines
git bisect good 2e545672ba14fb49455ce501ded21efd18df1a65
# skip: [afe84fa77f392a9748319efee01db6b3c6d870fb] pdf: Compute fill-stroke extents first before trying to use it to set the clip
git bisect skip afe84fa77f392a9748319efee01db6b3c6d870fb
# skip: [1ccd269a3f33684bfbedcd94ad9bca56b1404143] skia: Update to use cairo_backend_t interface
git bisect skip 1ccd269a3f33684bfbedcd94ad9bca56b1404143
# skip: [829eabfc9531a3e4490760b6bbd33286cd280e95] test/line-width: Refactor and tidy
git bisect skip 829eabfc9531a3e4490760b6bbd33286cd280e95
# good: [79aa04fd50463629b3ab2e2efbcd8084038f6c09] ps: use deflate compression for ps level 3
git bisect good 79aa04fd50463629b3ab2e2efbcd8084038f6c09
# bad: [4a990925e91a91c1d9d5a81f5ad91c1000bf5cce] script: Support unbounded native recording surfaces
git bisect bad 4a990925e91a91c1d9d5a81f5ad91c1000bf5cce
# bad: [99fa5ff6c211b96326484f80fe91ead0860c3a23] snapshot: Defer acquisition
git bisect bad 99fa5ff6c211b96326484f80fe91ead0860c3a23
Comment 5 Uli Schlachter 2013-04-18 15:05:03 UTC
Created attachment 78183 [details] [review]
Ugly hack which "fixes" (= work arounds) the issue.

Thanks a lot for that test case, Jean.

The attached patch fixes this. The problem is that the code in cairo-svg no longer recognizes the recording surface, because it got wrapped in a snapshot surface. Fixing this properly requires someone who knows more about cairo-svg to do some restructuring, I guess. Someone else will have to do this.

No idea if it would make sense to add a test case for this to the test suite (especially because I have no idea how such a test case should look like nor why the current mime-data test wouldn't catch this).
Comment 6 Emmanuel Pacaud 2013-04-18 15:10:08 UTC
I'm not sure it is that ugly. I think it's not possible in cairo to use a context and associated ressources like patterns from several threads.

It would be a good idea to raise this issue on the cairo mailing list.
Comment 7 Bryce Harrington 2016-10-20 03:23:06 UTC
Created attachment 127414 [details]
markers.png

I ran the repro example, and it looks to me like it's producing the results I would expect of the code.  See attached screenshot of what eog is showing me - is that right, or am I overlooking something?

Is anyone else still reproducing the problem?  Maybe the underlying issue has been resolved?
Comment 8 Bryce Harrington 2017-11-06 21:44:07 UTC
Closing after a year with no response.  Feel free to reopen with requested info if the issue can still be reproduced.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.