White gaps around rectangles in PS/PDF

[Rikster]

Whenever the document size is not an integer number of pts there are
roundoff errors in the PS/PDF export code which introduces visual gaps. I
am working at 300 dpi so there is almost no chance that I'm just going to
get lucky and have something be an integer multiple of pts.

I solved the problem by manually searching and replacing all occurrences of
the rounded-off document size with the correct floating point value.

Example file 1: Black rectangle on document where the size is 72.25 pts
square

Example file 2: postscript output obtained by saving as a ps file. Zoom in
and notice white gap at bottom of document.

Example file 3: manually corrected postscript for comparison with file 2.

[Rikster (rikster)]

Originator: YES

File Added: box_test.modified.ps

[Rikster (rikster)]

Originator: YES

File Added: box_test.ps

[vonHalenbach (lustik)]

Thank you for your bugreport with the attached testfiles.

[Rygle (rygle)]

Still happening in Inkscape 0.46 Win32, but only when saving to ps via cairo with the page size the same as the small square. If I print to a ps file, it just prints the black box in the corner of a normal A4 page, which is what I think would be expected behaviour.

I am wondering how this might impact a case in real life. Does this only happen on the edge of documents, and if so can you use some sort of standard bleed technique where objects overlap the edge? So, if I change the page size to A4 and then stretch the black box to go slightly over the margins around all the edges, then save as ps or print to a ps file, I get no white margins. This seems to be what commercial printers do all the time. Last time I had something commercially printed they asked for a 5mm bleed, and told me if I didn't do that they'd stretch the image to make a 5mm bleed and simply crop the edges off.

Is there another case where this happens that does not involve the page edges?

[rikster (lpad.nomad)]

Unfortunately it does affect things besides the page edges, although the effect may be small enough to ignore. Using a bleed zone gets around the white rectangle problem but only in a print environment. PDF printing for on-line documents, however, is still completely affected. Second, a bleed zone only solves the white rectangle issue but doesn't solve the problem that postscript will be using a different coordinate space from Inkscape.

My original project was to design a business card so I did have a bleed zone outside the printable area. The problem is that objects are placed in the document referenced to the bounding box. I've made another example file where the "page" is 1.2"x1.2". This reflects my desire to have a 1"x1" final product with 0.1" margins on all sides for the bleed zone. I have placed a blue square at (0.1, 0.1) which is at coordinates (0,0) on my desired final document. If I print this to postscript and then read it into the gimp at 300 dpi I find the following problems. A 1.2" square document should be 300dpi*1.2"=360 pixels on a side but the actual document is 363. The black rectangle which is specified in inkscape as 1.2"x1.2" comes out as only 361x361. This is the origin of the white gaps. Finally, I expect the blue square to be .1" or 30 pixels above the bottom of the page. Instead it is 32 pixels. 2 pixels / 300 dpi = .007" which isn't much so perhaps it can be ignored. On the other hand, designers can use inkscape to theoretically place objects to .001" tolerance and this certainly destroys that kind of accuracy. In addition, I made the blue square 0.2" tall or 60 pixels but the resulting square is 61 pixels tall. This is only a .003" error but it is still annoying.

I am still using Inkscape 0.45.1.

[Jan David Mol (jjdmol)]

I have a similar problem with A4, which is also of a fractional size in points. Steps to reproduce:

1. create a new document (A4)
2. enable snapping to page
3. create a rectangle covering the page
4. save as pdf
5. open pdf in evince

Notice the white border on the bottom and the right.

Inkscape claims the page is 595.28 x 841.89 while pdfinfo on the created pdf returns 596 x 842.4.

[Jan David Mol (jjdmol)]

I am using Inkscape 0.47pre4 r22446.

[su_v (suv-lp)]

related: bug #168275 “wrong PDF export with rectangles”

[Jan David Mol (jjdmol)]

For me, the translation error is (at least) at CairoRenderer::setupDocument, in which the pixel size is rounded up to an integer before it is converted to points. This leads to exactly the difference I see in the point sizes of the source and target. The offending code:

    NRRect d;
    if (pageBoundingBox) {
        d.x0 = d.y0 = 0;
        d.x1 = ceil(sp_document_width(doc));
        d.y1 = ceil(sp_document_height(doc));
    } else {
        sp_item_invoke_bbox(base, &d, sp_item_i2d_affine(base), TRUE, SPItem::RENDERING_BBOX);
    }

    if (ctx->_vector_based_target) {
        // convert from px to pt
        d.x0 *= PT_PER_PX;
        d.x1 *= PT_PER_PX;
        d.y0 *= PT_PER_PX;
        d.y1 *= PT_PER_PX;
    }

(PT_PER_PX is 1.0/1.25)

In gdb at the end of the above lines:

(gdb) print d
$4 = {x0 = 0, y0 = 0, x1 = 842.40000000000009, y1 = 596}

Manual calculations show the desired result without rounding errors:

(gdb) print sp_document_height(doc)
$5 = 744.094482421875
(gdb) print sp_document_width(doc)
$6 = 1052.3621826171875

(gdb) print sp_document_width(doc)/1.25
$10 = 841.88974609374998
(gdb) print sp_document_height(doc)/1.25
$11 = 595.27558593749995

[su_v (suv-lp)]

The ceil() of sp_document_*(doc) was already in the initial commit of Cairo renderer for PDF export (r13110).

Link to above quoted code in r22000 of 'cairo-renderer.cpp' - line 570
<http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/extension/internal/cairo-renderer.cpp?revision=22000&view=markup>

[Johan Engelen (johanengelen)]

I removed the ceil as it does not seem to make sense. (there is no rounding when the export area is set to only the drawing, so a non-integer value should not be a problem). removed the ceil in r9306.
Please check if this fixes the issue.

[su_v (suv-lp)]

I have not been able to reproduce the originally reported issue with the samples provided in comments #0 and #5 with Inkscape 0.47 r22583 - i.e. this bug must have been fixed earlier (likely when switching to cairo-based PostScript export).

The problem reported by Jan David Mol in comments #7-10 is the same as bug #168275 “wrong PDF export with rectangles” - reproduced with Inkscape 0.47 and confirmed fixed in Inkscape 0.47+devel r9307.

Setting bug status to 'Fix Released' as it seems to have been fixed in earlier releases (and I missed to carefully test the files when I confirmed the bug in comment #9). Please re-open if this issue was closed in error.