inkscape fails to print thin lines to PDF

Bug #1174909 reported by Jürgen Weigert on 2013-04-30
58
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Unassigned
cairo
Fix Released
Medium
cairo (openSUSE)
Fix Released
Medium

Bug Description

When using very thin lines, export to PDF may not show them all.
Below 0.018mm lines are missing. Especially curved lines.

Also the print preview does not show them.

This is with inkscape-0.48.4 on openSUSE-12.3

Attached thin_boxes.svg which reproduces the issue when printed to pdf.

In , J6 (j6) wrote :

When using very thin lines, export to PDF may not show them all.
Below 0.018mm lines are missing. Especially curved lines.

Also the print preview does not show them.

This is with inkscape-0.48.4

In , J6 (j6) wrote :

Created an attachment (id=537342)
samle svg file

boxes and circles with different line width. This svg also renders nicely when loaded in firefox. From there I can print to PDF with all elements, except for width 0.001mm (acceptable)

In , J6 (j6) wrote :

Created an attachment (id=537343)
pdf printed with firefox

please note that
a) scaling is ca 2% too small, although 100% was selected
b) the final box and circle are missing. 0.001mm is maybe just too small.

(not sure if these qualify as additional bugs)

In , J6 (j6) wrote :

Created an attachment (id=537344)
pdf printed with inkscape

Note that

a) all boxes are there (even the 0.001mm line width)
b) circles are missing with line width below 0.018mm

Jürgen Weigert (jnweiger) wrote :
Jürgen Weigert (jnweiger) wrote :

pdf as saved by the inkscape print dialogue.

Note that

a) all boxes are there (even the 0.001mm line width)
b) circles are missing with line width below 0.018mm

original report https://bugzilla.novell.com/show_bug.cgi?id=817724

In , J6 (j6) wrote :

forwarded to https://bugs.launchpad.net/inkscape/+bug/1174909 -- not sure if this is SUSE-specific at all.

Alvin Penner (apenner) wrote :

- not reproduced on Win 7, Inkscape 0.48.4
- not reproduced on Windows XP, Inkscape rev 12287
- in both cases I get the attached pdf file, in which the box at .001 mm is missing
- are you using the Print Dialog to generate the output, or are you using the File->Save As...?
- if not using Save As, could you give it a try?

su_v (suv-lp) on 2013-05-01
tags: added: cairo exporting pdf
su_v (suv-lp) wrote :

[Corrected version]
Output as well as export results vary depending on cairo version:

Tests with Inkscape 0.48.4 on Mac OS X 10.5.8/OS X 10.7.5:
cairo 1.10.2: objects <= 0.001 mm missing (local test)
cairo 1.11.2: objects <= 0.001 mm missing (thin_boxes_Win7.pdf)
cairo 1.11.4: all objects visible (local test)
cairo 1.12.2: all objects visible (local test)
cairo 1.12.8: circles < 0.018 mm missing (is.pdf)
cairo 1.12.14: circles < 0.018 mm missing (local test)

Results are the same whether saving a copy as PDF or printing to file via GTK print dialog.

Jürgen Weigert (jnweiger) wrote :

Thanks suv for testing these cairo versions, this is most helpful!
I had cairo 1.12.8 installed.

Testing other cairo versions confirms your findings on my system:
 cairo 1.12.99~git20130329 circles < 0.018 mm missing
 cairo 1.12.2 all objects visible

Downgrading to cairo-1.12.2 is a useful workaround for me.
Both 'save as' and 'print to file' now work as expected.

In , J6 (j6) wrote :

Apparent workaround:
Downgrade to cairo-1.12.2 -- we currently ship 1.12.8 which causes the issue.

In , J6 (j6) wrote :

(In reply to comment #5)
> Apparent workaround:
> Downgrade to cairo-1.12.2 -- we currently ship 1.12.8 which causes the issue.

The issue is also present with cairo-1.12.15 (as seen in home:pontostroy:X11)

Jürgen Weigert (jnweiger) wrote :

The issue is also present with cairo 1.12.99~git20130508, (pdf creator string has cairo-1.12.15)
Reproduced by rendering PDF from a GooCanvas via cairo. No inkscape involved.

Changed in cairo (openSUSE):
importance: Unknown → Medium
status: Unknown → Confirmed
Jürgen Weigert (jnweiger) wrote :

issue still exists.
cairo 1.12.16: circles < 0.018 mm missing

Jürgen Weigert (jnweiger) wrote :

Reproducer using the python cairo bindings. (Standalone, no inkscape involved)

We render a series of circles and rectangles with different line width into output.pdf

Cairo 1.12.16 shows me the 0.018 lines and above.

Jürgen Weigert (jnweiger) wrote :

bisected down to this commit http://cgit.freedesktop.org/cairo/diff/?id=bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442

commit bdf83008f4b2c723fd8e65e2a92bc47a2e7bc442
Author: Chris Wilson <email address hidden>
Date: Sat Aug 25 08:39:30 2012 +0100

    compositor: Skip invisible strokes

    If the pen is reduced to a single point, it is effectively invisible
    when rasterised, so skip the stroke composition.

    Signed-off-by: Chris Wilson <email address hidden>

commit fc38d7375d4f0342ece91596d71f0ce56aa2c975

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.

Created attachment 97205
reproducer

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

Created attachment 97207
Example output from the reproducer when good.

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.

In , J6 (j6) wrote :

Created an attachment (id=586045)
suggested fix.

Jürgen Weigert (jnweiger) wrote :
su_v (suv-lp) wrote :

Setting bug status to 'Triaged' for now - the report can be closed as 'Invalid' for project Inkscape once a better solution is included in stable upstream release (unless upstream says this must be solved differently, e.g. in the clients' code).

Changed in inkscape:
importance: Undecided → Medium
status: New → Triaged

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?

Could somebody review the suggested change there?

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.

Changed in cairo:
importance: Unknown → Medium
status: Unknown → Confirmed

Juergen,

I am inclined adding this patch to GNOME 3.14 for openSUSE 13.2;

I assume you have been running on one of the upstream solutions for a while now? Did you see any negative impacts?
Which of the two solutions are you operating? I'll just go with the one you tested already.

Changed in cairo (openSUSE):
status: Confirmed → Unknown

I am running with our own patches.
Did you see a working upstream solution?

I see that https://bugs.launchpad.net/inkscape/+bug/1174909 just got downgraded from confirmed to unknown.

Please pull into Gnome 3.14

(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!

he, first look, then talk, right?
We actually already have that patch in Factory and openSUSE 13.2.

So from the openSUSE perspective, I am closing the bug as FIXED and hope for upstream to come up with an even better solution matching them.

Changed in cairo (openSUSE):
status: Unknown → Fix Released

@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?

is there anyone wanting to review that one?

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.

Created attachment 118381
cairo test for thin lines

This patch contains a cairo test for thin lines.

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.
>
>

(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.

I've commit my patch and testcase.

@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

Should be fixed now.

(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.

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’

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’

su_v (suv-lp) wrote :

@Jürgen - have you been able to test with latest cairo git master (upstream committed a fix)?

A more troubling aspect of this problem is that in Inkscape's exports it also affects objects with a visible fill - if they have a tiny stroke width, they are not included in the exported PDF file. Since strokes of filled objects with a very tiny width might not be visibly noticeable at regular zoom levels, this problem affects many more use cases than just those exporting/printing line art for cutting/plotting.

Changed in cairo:
status: Confirmed → Fix Released
su_v (suv-lp) wrote :

Still reproduces with lp:inkscape/0.92.x r12725 and latest cairo 1.15.5 (git master @55e0b21):

Steps:
1) Open the example from comment #1 in Inkscape 0.92pre4 r15275
2) Add solid fill colors (light grey for rects, red for circles)
3) Save a copy as PDF
Result: red-filled circles <= 0.018mm missing in the exported PDF file.

Hachmann (marenhachmann) wrote :

Btw. with Cairo libcairo2 1.15.2-0intel1 on LM 18.2 and Win10, this also affects any curved segments, as far as I can see.
Could someone please reopen this issue for cairo?

See also:
https://answers.launchpad.net/inkscape/+question/647107

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

Other bug subscribers

Related questions

Remote bug watches

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