Inkscape (using cairo) fails to print thin lines to PDF

[Jürgen Weigert]

Since 1.12.3, cairo cannot render fine lines to pdf. 1.12.2 was the last version that worked.

http://cgit.freedesktop.org/cair/diff/?id=bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442

introduced code to avoid lines that would be invisible when rasterized. While this is a valid logic for raster backends, it is a bad idea for PDF output. There we want to see all fine lines.

My specific use case is generating a lasercutter drawing for an Epilog Zing laser with inkscape. There the hardware would raster anything thicker than 0.02mm, and cut 0.01mm or below. 1.12.3 skips lines below 0.036mm, 1.13.1 skips lines below 0.018mm -- which is still not enough to safely drive my lasercutter.

Previously reported against inkscape: https://bugs.launchpad.net/inkscape/+bug/1174909

Also reported agains cairo upstream with a suggested fix: https://bugs.freedesktop.org/show_bug.cgi?id=77298
Check out the attached reproducer and fix.

I'd suggest to circulate patched ubuntu packages, until upstream releases an official fix.

[Jürgen Weigert (jnweiger)]

Since 1.12.3, cairo cannot render fine lines to pdf. 1.12.2 was the last version that worked.

http://cgit.freedesktop.org/cair/diff/?id=bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442

introduced this code in cairo-compositor.c:_cairo_compositor_stroke

   if (_cairo_pen_vertices_needed (tolerance, style->line_width/2, ctm) <= 1)
        return CAIRO_INT_STATUS_NOTHING_TO_DO;

The idea was to avoid lines that would be invisible when rasterized. While this is a valid logic for raster backends, it is a bad idea for PDF output. There we want to see all fine lines.

My specific use case is generating a lasercutter drawing for an Epilog Zing laser with inkscape. There the hardware would raster anything thicker than 0.02mm, and cut 0.01mm or below. 1.12.3 skips lines below 0.036mm, 1.13.1 skips lines below 0.018mm -- which is still not enough to safely drive my lasercutter.

See also https://bugs.launchpad.net/inkscape/+bug/1174909

Check out the attached reproducer.

[Jürgen Weigert (jnweiger)]

Created attachment 97205
reproducer

[Jürgen Weigert (jnweiger)]

Created attachment 97206
Example output from the reproducer with missing objects.

[Jürgen Weigert (jnweiger)]

Created attachment 97207
Example output from the reproducer when good.

[Jürgen Weigert (jnweiger)]

Created attachment 97220
suggested fix.

Please double check if num_vertices == 1 should never be done (for PDF).

I am not sure why this was introduced at all. With 1.12.2 the lowest num_vertices value was 4, which assured that all objects are rendered to the PDF.

[Jürgen Weigert (jnweiger)]

Created attachment 97247
Suggested fix. Different approach.

Contributed by Patrick Himmelmann. Now we have something to discuss. Maybe we find a third alternative, so that the logic for raster backends continues to discard small objects, but the logic for vector backends includes everything?

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "suggested fix." seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Sebastien Bacher (seb128)]

Thanks for your bug report/work on it. That seems like a valid bugfix to backport but we are probably going to want to have a review comment from upstream first (and ideally having them commiting the fix to their vcs)

[Jürgen Weigert (jnweiger)]

Hi Sebastian, I dont want to archive my emails on bugreports privately.
Please add your comments directly to the report. Thanks, JW-
Am 14.04.2014 10:50 schrieb "Sebastien Bacher" <email address hidden>:

> Thanks for your bug report/work on it. That seems like a valid bugfix to
> backport but we are probably going to want to have a review comment from
> upstream first (and ideally having them commiting the fix to their vcs)
>
> ** Changed in: cairo (Ubuntu)
> Importance: Undecided => High
>
> ** Changed in: cairo (Ubuntu)
> Status: New => Triaged
>
> ** Bug watch added: freedesktop.org Bugzilla #77298
> https://bugs.freedesktop.org/show_bug.cgi?id=77298
>
> ** Also affects: libcairo via
> https://bugs.freedesktop.org/show_bug.cgi?id=77298
> Importance: Unknown
> Status: Unknown
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1306846
>
> Title:
> Inkscape (using cairo) fails to print thin lines to PDF
>
> Status in libcairo - cairo vector graphics library:
> Unknown
> Status in “cairo” package in Ubuntu:
> Triaged
>
> Bug description:
> Since 1.12.3, cairo cannot render fine lines to pdf. 1.12.2 was the
> last version that worked.
>
>
> http://cgit.freedesktop.org/cair/diff/?id=bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442
>
> introduced code to avoid lines that would be invisible when
> rasterized. While this is a valid logic for raster backends, it is a
> bad idea for PDF output. There we want to see all fine lines.
>
> My specific use case is generating a lasercutter drawing for an Epilog
> Zing laser with inkscape. There the hardware would raster anything
> thicker than 0.02mm, and cut 0.01mm or below. 1.12.3 skips lines below
> 0.036mm, 1.13.1 skips lines below 0.018mm -- which is still not enough
> to safely drive my lasercutter.
>
> Previously reported against inkscape:
> https://bugs.launchpad.net/inkscape/+bug/1174909
>
> Also reported agains cairo upstream with a suggested fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=77298
> Check out the attached reproducer and fix.
>
> I'd suggest to circulate patched ubuntu packages, until upstream
> releases an official fix.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/libcairo/+bug/1306846/+subscriptions
>

[Sebastien Bacher (seb128)]

> Hi Sebastian, I dont want to archive my emails on bugreports privately.
> Please add your comments directly to the report. Thanks, JW-

? I only used the webUI from launchpad to comment on the bug. Launchpad, like most bug trackers, send you new comments using emails so you know of activity on the bug you reported...

[Sebastien Bacher (seb128)]

Could somebody review the suggested change there?

[Adrian Johnson (ajohnson-redneon)]

This is not really a pdf specific problem. We need to always pass strokes through to the vector backends no matter how thin. I don't know the best way to do this as I am not familiar with that code that these patches modify.

[Jürgen Weigert (jnweiger)]

(In reply to Sebastien Bacher from comment #6)
> Could somebody review the suggested change there?

Patrick's version is best, please go ahead with this patch!

[Jürgen Weigert (jnweiger)]

@Chris Wilson et all:

I'd like to raise priority on this issue.
We know the issue to exist for several years now on Linux systems. Recently we see more and more Windows systems to suffer from the same issue. The attached patch is simple and fixes the issue.

Is there anything I can do to summon a cairo maintainer here?

[Sebastien Bacher (seb128)]

is there anyone wanting to review that one?

[Adrian Johnson (ajohnson-redneon)]

Created attachment 118380
Don't cull thin lines on vector backends

The patch didn't work for my test case and broke many other tests.

Attached is a new patch that seems to fix the bug. The patch ensures a minimum line width when calculating stroke extents on vector backends.

[Adrian Johnson (ajohnson-redneon)]

Created attachment 118381
cairo test for thin lines

This patch contains a cairo test for thin lines.

[Spitzak-k (spitzak-k)]

Created attachment 118385
attachment-30721-0.html

This seems excessively complex, rather than having the later handler (the
one turning a non-zero float into a zero fixed) be patched instead. I
figure it would be correct for all backends to turn very tiny but non-zero
line widths into the smallest ones they can render.

On Mon, Sep 21, 2015 at 5:18 AM, <email address hidden> wrote:

> *Comment # 12 <https://bugs.freedesktop.org/show_bug.cgi?id=77298#c12> on
> bug 77298 <https://bugs.freedesktop.org/show_bug.cgi?id=77298> from Adrian
> Johnson <email address hidden> *
>
> Created attachment 118381 <https://bugs.freedesktop.org/attachment.cgi?id=118381> [details] <https://bugs.freedesktop.org/attachment.cgi?id=118381&action=edit> [review] <https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=77298&attachment=118381>
> cairo test for thin lines
>
> This patch contains a cairo test for thin lines.
>
> ------------------------------
> You are receiving this mail because:
>
> - You are watching the QA Contact of the bug.
>
>

[Adrian Johnson (ajohnson-redneon)]

(In reply to Bill Spitzak from comment #13)
> Created attachment 118385 [details]
> attachment-30721-0.html
>
> This seems excessively complex, rather than having the later handler (the
> one turning a non-zero float into a zero fixed) be patched instead. I
> figure it would be correct for all backends to turn very tiny but non-zero
> line widths into the smallest ones they can render.

We don't want to alter the line width on the vector backends. If a 0.001mm line width is specified for pdf that is the line width it should use. My patch only alters the line width when the extents are measured for the purpose of culling 0 width/height objects.

[Adrian Johnson (ajohnson-redneon)]

I've commit my patch and testcase.

[su_v (suv-lp)]

@Adrian - the commit broke the quartz backend (and based on comments on irc the gl backend too):

  CC cairo-quartz-surface.lo
cairo-quartz-surface.c:2265:12: error: too few arguments to function call, expected 5, have 4
                         content);
                                ^
./cairoint.h:1335:1: note: '_cairo_surface_init' declared here
cairo_private void
^
./cairo-compiler-private.h:133:27: note: expanded from macro 'cairo_private'
#define cairo_private cairo_private_no_warn cairo_warn
                            ^
./cairo-compiler-private.h:120:31: note: expanded from macro 'cairo_private_no_warn'
#define cairo_private_no_warn __attribute__((__visibility__("hidden")))
                                ^
1 error generated.
make[3]: *** [cairo-quartz-surface.lo] Error 1

[Adrian Johnson (ajohnson-redneon)]

Should be fixed now.

[su_v (suv-lp)]

(In reply to Adrian Johnson from comment #17)
> Should be fixed now.

Thx a lot - build fix confirmed for quartz, quartz-image, xml and tee surface backends.

[Damien (damien-grassart)]

It seems the GL backend still doesn't compile as a couple uses of _cairo_surface_init weren't updated:

cairo-gl-source.c:76:5: error: too few arguments to function ‘_cairo_surface_init’
cairo-gl-source.c:103:5: error: too few arguments to function ‘_cairo_surface_init’

[Damien (damien-grassart)]

There's also a similar error for _cairo_path_fixed_approximate_stroke_extents():

cairo-gl-msaa-compositor.c:584:6: error: too few arguments to function ‘_cairo_path_fixed_approximate_stroke_extents’

[Sebastien Bacher (seb128)]

upstream commited some fixes, see
http://cgit.freedesktop.org/cairo/commit/?id=b1192beac7c5b56a8ff356d20af5ebfb65404109
http://cgit.freedesktop.org/cairo/commit/?id=30eb1b0e9778a96c2eb984f243dec5e3c8859e05
http://cgit.freedesktop.org/cairo/commit/?id=aa1323f04cd2c71317e9173fbe26fe7d0ba34908

[Sebastien Bacher (seb128)]

The fixes is included in that update
https://launchpad.net/ubuntu/+source/cairo/1.14.4-1