Trim Box size shows wrong

[Bruno Belo]

Goodnight, I've had a question for a while and would like some help: Why is the trimbox size shown a little larger than correct? As per the attached image, my file is 49.5x80mm (cropped) but affinity always throws in a little extra breakage like in the image 0.03mm in width and 0.01mm in height.

I have a problem with this, because in the printing shop where I print small stickers or small things in an assembly with several on the sheet, I have pre-made knives in Coreldraw or Illustrator or even Acrobat Pro with imposition plugins and these measurements are exact , and when assembling the file generated by affinity using the same number of lines and columns and spacing and placing the art on top of the knife they end up having a very noticeable difference.

My solution currently has been to use the imposition plugin in Acrobat Pro to crop the document to the exact size before doing the imposition, because if I use the trim box generated by affinity it will cause this problem. I've already tried exporting with no bleed, and using pdf for press or pdf for print and it's the same.

[Oufti]

I don't know if this is the cause for what you see but Adobe uses always PostScript points for size, as well internally as for PDF. Since these points are defined as exactly 1/72 inch, values in inches are also always exact but if you are using millimetres, there will be some rounding. 

P.S.

If rounding above is applied, I find same values you see:

Thus,

1 hour ago, Bruno Belo said:

I have pre-made knives in Coreldraw or Illustrator or even Acrobat Pro with imposition plugins and these measurements are exact

Copy their size values expressed in points units (pt) as they are set in these programs, and use these values in your Affinity document, even if they are not round millimetres. 

[thomaso]

In addition to @Oufti's hints, it is a known problem in Affinity caused by "thinking" in units of pixels, rounding pixel positions with decimal places. For example in these two short threads. (the first with comments from a serif moderator)

[Bruno Belo]

16 minutes ago, thomaso said:

In addition to @Oufti's hints, it is a known problem in Affinity caused by "thinking" in units of pixels, rounding pixel positions with decimal places. For example in these two short threads. (the first with comments from a serif moderator)

Well...the second case give me a chance to test, tomorrow i test using 296dpi on export or similar values to try affinity to calculate rounded values.

Thanks

[lacerto]

Obsolete.

[loukash]

8 hours ago, thomaso said:

it is a known problem in Affinity caused by "thinking" in units of pixels

8 hours ago, lacerto said:

it is related to Affinity's px based calculations

Meanwhile, this issue has been apparently tagged as a bug:
https://forum.affinity.serif.com/index.php?/search/&tags=AF-679

Check out particularly @lepr's posts on page 3.

[thomaso]

48 minutes ago, loukash said:

Meanwhile, this issue has been apparently tagged as a bug:
https://forum.affinity.serif.com/index.php?/search/&tags=AF-679

I doubt your linked tag 'AF-679' concerns this pixel affinity of Affinity. It appears to be about certain effects/filters with transparency causing increased object size.

Dan C comments in that thread:

A.)  " I've been able to replicate this here, both with Marks files and in a new document - it appears to simply be the presence of the Gaussian Blur layer and only seems to affect PDF export. I'm getting this logged with our development team now, as I cannot see any previous reports of this specific issue."
https://forum.affinity.serif.com/index.php?/topic/192980-annoying-white-borders-around-all-pdf-exports-designer/&do=findComment&comment=1132615

B.)  "I agree - I don't expect the PDF export to be larger than the canvas shown in Affinity, and equally when using Document > Unclip Canvas in Photo with such a document causes this white border to expand ad infinitum. Both of these issues have been logged with our team"
https://forum.affinity.serif.com/index.php?/topic/192980-annoying-white-borders-around-all-pdf-exports-designer/&do=findComment&comment=1132644

Note, also already in my linked thread of April 2021 Dan C confirmed + tagged a bug and commented twice, while the 2nd might even mean the 'integer pixel' issue is "by design" ("an intrinsic part of the Affinity exporter" ).

16th April:  "I can confirm this is a known bug that is already logged (afd-3100) with our developers, I will 'bump' this log with your thread now and we hope to have this fixed in a future update."

28th April:  "Unfortunately the Affinity apps will export to 'whole pixel' values, which is where the additional 0.1mm is gained when exporting. Unfortunately as this is an intrinsic part of the Affinity exporter, there's no way to disable or workaround this currently - my apologies."

[thomaso]

10 hours ago, lacerto said:

from 300dpi up to 19,200dpi. You might need to go at very high production DPI in Affinity apps to get to accuracy where the deviation no longer matters!

Interesting idea & result!

The sizes of the deviations make me wonder if the issue is rather at the end of a pre-/post-press process being to strict with its maths and auto-rejections by automatic pre-press software? Especially if I consider the standard bleed size of 3 mm or the width in the printed material caused by a cutting knife or laser I would assume that neither 1/100 nor 1/10 of a millimetre would matter and prevent an imposition or cutting process from working correctly.

(curious: even though it maybe a "simple rule of three" I can't get it: What maths/formula lead you to the 19200 dpi ?)

12 hours ago, Bruno Belo said:

I have pre-made knives in Coreldraw or Illustrator or even Acrobat Pro with imposition plugins and these measurements are exact , and when assembling the file generated by affinity using the same number of lines and columns and spacing and placing the art on top of the knife they end up having a very noticeable difference.

Can you show or describe an example where such a deviation of 1/10 mm or less causes noticeable (= visible?) issues in the production process?

I assume the resulting printed objects have at least a size of ~ 5 mm, while – apart from the aspects 'bleed' and 'material loss' – a certain deviation might also appear by the material (paper) and its possible expansion/contraction during the process at variable humidity (fluid ink) or temperature (friction) conditions, with or without air-conditioned rooms. [… different to e.g. the layout and production of computer chips with a precision in the macro / nano range … which hardly use DTP tools like Affinity, ID or CorelDraw]

[lacerto]

Obsolete.

[Oufti]

7 hours ago, thomaso said:

(curious: even though it maybe a "simple rule of three" I can't get it: What maths/formula lead you to the 19200 dpi ?)

19200 = 2400 * 2^3

 

7 hours ago, thomaso said:

Can you show or describe an example where such a deviation of 1/10 mm or less causes noticeable (= visible?) issues in the production process?

It can be a problem for automated flows, sometimes not wise enough to asset as insignificant such an error… 

[thomaso]

2 hours ago, Oufti said:

19200 = 2400 * 2^3

… and where from did you get the single numbers?

2 hours ago, Oufti said:

a problem for automated flows,

That's what I mentioned already – but where is a "real" problem at all if the layout PDF page for a book is a fraction of a mm larger than expected or wanted?

It is just a limit set in the pre-press software, either "by design" or by not caring. There are various possible ways to handle this, auto-rejecting the file is just one. Another would be to simply ignore the deviation and produce as usual, cropping before printing or when cutting as wanted by the automatism. I am sure, nobody will ever notice such a difference. And I am sure, in real and usual print products the deviations are a lot larger ("3 mm bleed").

Note for instance deviations in stamps (philately) or on tiny stickers used for model vehicles. There it occurs visible for the human eye, obviously larger than 0.1 or 0.01 mm.

[lacerto]

Obsolete.

 

[thomaso]

19 hours ago, lacerto said:

Probably not in a book project, but there might be real problem in an imposition job involving placing columns and rows of duplicates of a single design, and generally in printing industry 0.25 points is a meaningful accuracy at which all professional applications should aim at.

First, to be clear: My goal is not to argue for Serif not to fix this issue! – My argument rather concerns the various 'desperated' threads in this forum about the automated workflow of book print services (e.g. KPT) that reject certain PDF because of mathematical imperfection that wouldn't harm at all if the software would ignore some deviations (e.g. exceeded margin, objects with 'insufficient' bleed). In that way the "real" culprit are the strict limits of the prepress process.

=====
I understand the theory: in your example the last, bottom right card would miss its outer stroke and would be ~1.7 pt (0.6 mm) smaller than wanted. Considering the "real" use of the printed matter we both may feel about the discussion about such a deviation as a whataboutism. Personally I would prefer 100.00% accuracy and I wonder why you decided to see in particular 0.25 points as the right or acceptable tolerance – why not 0.5 or 0.1 pt? Is it because a printed stroke of 0.25 pt (= "hairline") is the smallest that is commonly used?

In practice the theory doesn't work (or matter) in my eyes for various reasons:

A.) I am not sure: Does an imposition software work this way? Or does it rather place the bunch of instances in a 'manually' defined grid, in this case the desired 89 x 44 mm, and thus create a another deviation issue but equally for each of the cards? (i.e. missing the stroke at two edges for every card because of overlapping instances)

B.) Your example uses the black stroke to visualize the deviation, that's fine to demonstrate this Affinity issue. But in practice a desired thin stroke at the card edges would quite likely use a different layout / prepress / production process, e.g. with bleed for each single card. Or it would rather be printed in a separate process after cutting as print on the edges of a cut staple of cards (compare: coloured book edges).

C.) If the card layout doesn't have a stroked edge then in your example the resulting cards would "just" differ in their text / content position, in a deviating size that would hardly be noticed and definitely not be visible for a single card.

D.) Also the cutting procedure matters and a resulting deviation will depend on the cutting technology and accuracy. For instance it would/could either get the actual 89.069 x 44,027 mm set, resulting in the tiny offset for each card – or it could result in slightly deviating sizes across a staple of cards (which could possibly be felt with the fingers at a staple's edge but wouldn't affect a single card in any obvious way (comparing the largest, a mid and the smallest card you couldn't tell which card dimension would be the desired, correct size)

E.) In a print process, several other aspects reduce the resulting accuracy (e.g. humidity, temperature, speed, paper feed, paper quality) while one might increase or reduce a deviation caused by another. It is common for a certain amount of printed sheets to be waste. In your theoretical example a practical handling would/could use just the satisfying card results only and throw others away (e.g. some columns / rows near the right / bottom edge of the printed sheet) + print a few more sheets in compensation.

F.) There might be special printed matters that require a tolerance even below 0.25 pt, (e.g. bank notes ?) and I assume those would use 'special' software to achieve sufficient accuracy (quite likely not Affinity) or they care by default for the required perfection in several 'manual' steps.

------
Oddly, if I open your PDF in APub a single card instance on page 1 is reported in the Transform panel with a different size than your mentioned 89,069 x 44,027 mm. With two decimals it reports 252,28 x 124,72 pt, switching the unit says integer 89 x 44 mm – whereas, additionally, an online prepress tool calculates 252,535 (± 0.255) x 124,828 pt (± 0.108) for the 89,069 x 44,027 mm.

Am I misunderstanding the layout? Currently it appears unclear what exact value is true for the selected object.

P.S.: I am more disturbed by the Affinity ruler and its weird and variable use of subdivisions "by design".

[lacerto]

Obsolete.

[MikeW]

2 hours ago, thomaso said:

...

In practice the theory doesn't work (or matter) in my eyes for various reasons:

A.) I am not sure: Does an imposition software work this way? Or does it rather place the bunch of instances in a 'manually' defined grid, in this case the desired 89 x 44 mm, and thus create a another deviation issue but equally for each of the cards? (i.e. missing the stroke at two edges for every card because of overlapping instances) ...

Imposition software can, like in this APub example, have the rows/columns set individually. Still, though, because Affinity applications create "extra" page width/height beyond the stroke, there will be the minutest of gap---which wouldn't matter in real life and produces the exact size of imposed sheet (when rows/columns are manually set) as an example from ID (which always/almost always produces an undersized sheet, at least when using non point-based integers and requires zero intervention.

Because of the under-sized ID pdf, my imposition software rounds up and still produces a small gap--which can disappear depending on the zoom level. What the ID-produced pdf won't do, however, is trigger an automated rejection.

My opinion is automated pdf checking ought to report any such discrepancy, the size of the discrepancy, and let the customer decide on whether to proceed or not. KDP and others are not printing labels nor business cards (afaik). They don't print 10-up where such discrepancies can accumulate into perhaps meaningful amounts.

Moo & Vista are a print services that do print such things as ganged-up business cards and other smaller documents on larger sheets. I've sent many business cards and postcard-sized jobs to each of them. Some of which were done in AD. Same kind of rejection on the first submission at Moo. I changed the page size based upon whole points and still got a warning that I was allowed to bypass (height was 0.08" taller, width was exact). I get no such warnings from other applications.

If Serif is rounding up using the pdf routine, the simple thing would be to stop if that produces + sizes. If it is the pdf routine does this automatically, there isn't much Serif can do short of always altering the code each time there is an update to the library.

[lacerto]

Obsolete.