Help needed with precision graphic work

Previous topic - Next topic

GarryP

I've been trying to do some precision graphic work and have come across a problem that's been bugging me, so I hope someone can help.

I've attached a sample screenshot, an example PDF, and the original SLA.

When placing some coloured blocks next to and on top of other coloured blocks there is sometimes a visible gap or line where they "touch" even though the blocks are positioned with exact coordinates and sizes.

If you look at the PDF you can see a blue line "poking through" between the top green blocks and a green one between the right-hand blue blocks. However, if you look at the SLA, you'll see that the positions and sizes of the blocks are such that there shouldn't - in common sense terms - be a gap.

Also, at certain zoom levels the problem disappears but it comes back when zooming further in. The same effect occurs both in Scribus and some of my PDF readers. (Adobe reader looks to be better than others.)

Can anyone explain why this happens?

(I've a feeling it's got something to do with floating point arithmetic precision and differences in rendering mechanisms but that's just a guess.)

And, more importantly, can anyone give me a good - easily achieved - solution or work-around that will work both on-screen and when printed so that the "gap" won't appear?

Or is this just one of those things that we've got to live with?

(Obviously in this simple scenario I could just create a big green block and put a smaller blue block over the top of it but that won't work for more complex work. Or at least I don't want to have to put the effort in to create lots of bespoke shapes.)

[attachment deleted by admin]

utnik

hi garry

this is not a scribus problem – it's a screen rendering issue.
i couldn't reproduce it with your .pdf file displayed by adobe reader (still the reference for .pdf files...)
but i know that lots of people know this phenomenon from files produced with illustrator or indesign.

i think, you have to live with it, as long as you don't use adobe reader.

utnik

GarryP

Hi utnik.

I've seen this happen in other software in the past too but was hoping for the best.

The same thing is evident in all of the PDF readers I've looked at including Adobe Reader - Reader just doesn't show it as much as others - and in Scribus itself.

I've attached a screenshot from Scribus that shows I'm not going mad and one also from Adobe Reader on another - similar - document that shows the gap (between the black and red shapes).

The Scribus screenshot was taken at 100% zoom with a 99dpi display size (recommended system setting on my machine). However, changing the display size to 101dpi makes the problem disappear - for this test - in Scribus but it is still evident in the readers, of course.

Also, changing the display dpi in Reader from 99 to 100 (or similar) moves the problem to other areas. With some settings it's fine horizontally but not vertically, other settings it's the other way round, or both. Each value produces its own gaps in different places.

I've checked the SLA XML and it looks fine as regards to positions and sizes. (I've not yet found a free application that'll let me interrogate the PDF data.)

I've also done some manual tweaking and moving the blocks by 0.34 points also seems to remove the gap in some cases but that's totally impractical.

I'm guessing that all of this is simply a case of: "If a pixel needs to be drawn in a position that isn't directly over a physical pixel - i.e. 10.5 pixels across - the system has to decide whether to put it to the left/right or above/below and sometimes it just puts it in the 'wrong' place." Like you say, a screen rendering issue.

All in all, I think you're right that I'll just have to live with it. It's not an ideal situation but I could take days or weeks trying various settings and work-arounds and readers and not come up with an answer that will be of any use.

If anyone else has come up against this kind of thing I'd be interested to hear about it though.

P.S. I know what I've written above meanders all over the place but I wanted to show the steps I've been through to get to my conclusion. Just in case anyone else is thinking of trying it for themselves.

[attachment deleted by admin]

mnawij

GarryP, I have used enfocus pitstop pro in acrobat 10 pro, your numbers are correct within the pdf regarding x:y coordinates. Curious there is solid color blocks underneath each other, the effect creating a knockout of the colors... I am wondering if the display is trying to accommodate this at the edges either an overprint or white split.  I do not see the white or color stripes where they meet on my iMac (less than a year old).  In Illustrator I would either merger the shapes into one or use the cut tool to get rid of whatever color was underneath before going to print...I think this is possible in inkscape.

Sorry for the delay just started on the forums, hope you are still interested.

GarryP

Hi mnawij.

Yes I'm still interested in this topic, but mainly out of curiosity rather than trying to solve a practical problem.

Your comments about knockout/merging are interesting and I'll have to look at doing some more tests at some point to see if I can get better results by using the relevant tools. (Who knows, but that's why they're called tests.)

Like I mentioned above, it's probably got something to do with the differences between document and screen co-ordinates and the problem of aligning them at different zoom levels (or something like that) but I really don't have the time to research it properly. It's just something I noticed and thought it worth mentioning.

I've an idea in my head of what's going on but explaining it here would take too long and probably wouldn't be of interest to anyone. And it will probably be wrong too but as long as it fits in my brain then it's good enough for my simple needs.

However, if someone can post a link to a good layman-readable article about this sort of thing that would be great. (E.g. 3D graphics - such as in the movies - must come up against similar things but you don't - unless by accident - see gaps between the polygons so there's got to be a solution. But it's probably too complicated for me to get my head around.)