Pixel misalignment in Publisher

[NotMyFault]

Hi, based on an similar bug report form @DM1 I found that Publisher creates pixel layers that are misaligned by a fraction, despite transform panel states it is perfectly aligned (6 decimal digits chosen in preferences). 

The issue becomes visible when you switch to view mode pixel, or switch to Photo (Studio Link) which is always using pixel view mode.

Obviously, the grid (show grid) is slightly mis-placed when working with pixel art.

On desktop (create DIN A4 document, double-sided) it shows mis-alignment

on first page, to x axis.

on page 2+3, to y-axis (Continues on all later pages)

 

Affects MacOS and iPad. Can't test on windows.

 

misalignment.afpub

Edited January 15, 2023 by NotMyFault
Corrected which pages get affected

[Old Bruce]

My Math chops are not up to checking the Procedural texture you have there so I will only say that I think that the formula may be misleading you.

[NotMyFault]

13 minutes ago, Old Bruce said:

My Math chops are not up to checking the Procedural texture you have there so I will only say that I think that the formula may be misleading you.

You can spot the same issue even without PT filter, just use black rectangle on white background. PT filter helps to make this better visible. Just deactivate the filter in the file - same result.

Further tests show that the misalignment is mostly 1/3 or 2/3 of a pixel. Not exact 1/3, only almost.

 

Image below shows:

• grid in red with 1/3px 
• selected black rectangle, bounding box active in blue, perfectly pixel aligned
• transform panel: perfectly pixel aligned
• Document is 64x64 px, no bleed, no margin
• 

 

 

 

 

[Old Bruce]

I am not seeing any misalignment. I did of course use a 1 pixel grid to check. The only way I can get anything like your screenshot is to have Pixels turned on as the View Mode  from the Designer Persona.

[NotMyFault]

1 hour ago, Old Bruce said:

I am not seeing any misalignment. I did of course use a 1 pixel grid to check. The only way I can get anything like your screenshot is to have Pixels turned on as the View Mode  from the Designer Persona.

Yeah, that is the essential precondition.

[debraspicher]

Does it export the same way?

[loukash]

On 1/13/2023 at 12:14 PM, NotMyFault said:

misalignment.afpub

It's the bleed.
The bleed must have an integer pixel value on document creation.
It doesn't even help if you change the bleed later, the pixel grid will remain offset.

Since the standard bleed is 3 mm, make it a habit to create every new document with 36 px bleed. Don't change it to non-integer values later, otherwise it will be off again.

See also 

 

[NotMyFault]

26 minutes ago, loukash said:

It's the bleed.
The bleed must have an integer pixel value on document creation.
It doesn't even help if you change the bleed later, the pixel grid will remain offset.

Since the standard bleed is 3 mm, make it a habit to create every new document with 36 px bleed. Don't change it to non-integer values later, otherwise it will be off again.

See also 

 

I zeroed out bleed while creating the document (not later), the misalignment happens anyways.

Next, the misalignment is only on certain pages (namely facing pages, excluding first and last), whereas bleed is on all pages.

[loukash]

Just now, NotMyFault said:

I zeroed out bleed while creating the document (not later), the misalignment happens anyways.

Hm, worked for me: Created an RGB A4 doc with 36 px bleed, copied your two rectangles, aligned them to integer pixels as well, and all is perfect.

apu2_misalignment_recreated_fixed.afpub

[NotMyFault]

I will try again with 36 instead of 3.

[NotMyFault]

Same result. The misalignment is about 1/3px. So the first and every 3rd double-page is almost aligned, the next off by 1/3, the next off by 2/3. To be repeated.

No matter if bleed is 0 or 36px.

I put a rectangle into the master page.

bleed 36.afpub

[NotMyFault]

side bug: Publisher forgets to update the "Window" Menu with given name after save as.

 

and with Photo persona:

[loukash]

In any case, this bleed pixel grid offset is a serious bug that needs to be fixed a.s.a.p.!

Similar (same?) bug also affects afpub docs with pages with multiple sizes. If you have an A4 page and you add an A5 page, the latter will be off the pixel grid because its absolute origin is at the left-hand side of the A4 page…  

That all was already in APu v1.

Ideally, each page should have its own "absolute" pixel grid starting at the page origin, not at the bleed origin.

[NotMyFault]

I have an idea what could cause all this.

In Designer, when you add artbosrds, you can place them on fractional positions. But the grid shows relative positions to the dartboard origin, so pixel alignments gets off.

Interestingly, only in y-axis.

But if you switch to pixel view, you see the misalignment damage in both axis.

 

Pages and Artboards are twins in may aspects, similar like symbols, groups and Layer layers.

 

Something is totally messed up with Pages, Artboards and grid.

 

[loukash]

6 minutes ago, NotMyFault said:

bleed 36.afpub

Aha!
Now I see it: The misalignment starts on page 2!
There is a vertical misalignment between spreads!

My in the meantime three-quarter-educated guess is that the pixel grid origin is on spread 1, but the vertical gap between spreads is not an integer pixel value.
Same in APu v1.

WTF?

[loukash]

And here's your "not exact 1/3, only almost" offset:
The vertical gap between spreads is exactly 354.330709 px = exactly 30 mm @300dpi… 

[loukash]

So… to align your objects to pixel grid on all pages:

• always round your page sizes, bleeds and margins to integer pixels: A4@300 dpi = 2480×3508 px
• on page 2, your spread origin must be y=0.669291 px to align, then use integer values in Transform panel
• on page 3, your spread origin must be… er, what's the math…?  3508-0.669291+354.330709=3861.661418 … uhh… 1-0.661418  = y=0.338582 px
• on page 3, your spread origin must be…

Nurse! Nurse!!! My brain hurts! Nuuuuurse!!!

[loukash]

Either that nutty math above, or this deranged one:

h = initial page height in mm
s = distance from spread 1 top to spread 2 top in pixel
o = page offset in pixel
y = new page height aligned to pixel grid in mm

s = ( h + 30 ) / 25.4 * dpi
o = frac(s)
y = h - o [px]

Perhaps someone more math savvy than me can translate it into a proper equation.

I need sleep… 

Edited January 15, 2023 by loukash
en.wikipedia.org/wiki/Fractional_part to the rescue

[debraspicher]

That's not a real surprise since "misalignment" of Artboards in Designer cause the same problems with pixel layouts. I'd say it's an issue with pixel preview as I have a few accuracy issues with it on my current build, however, I checked export and though hard to see with the first file, it also effects output. So I guess pages have unseen document-wide positioning relative to the pixel grid... similar to artboards.

[loukash]

25 minutes ago, loukash said:

someone more math savvy than me can translate it into a proper equation

y = h - { ( h + 30 ) / 25.4 * dpi } px

Would that be mathematically correct based on en.wikipedia.org/wiki/Fractional_part?
(Disclosure: my last math lesson was around 1982 or so…)

12 minutes ago, debraspicher said:

That's not a real surprise since "misalignment" of Artboards in Designer cause the same problems with pixel layouts.

That's true.
The major difference being that we can align artboards to the absolute pixel grid ourselves, based on the left-most and top-most artboards' origin.
But we have no influence on the gap between Publisher spreads. It remains firm at 30 mm.

It could be worked around if APu would accept non-integer DPI but that doesn't seem to be the case: according to my math [cough, cough], e.g. 299.72 DPI should theoretically work because then the 30 mm gap would be integer 354 pixels. 

[loukash]

10 hours ago, loukash said:

y = h - { ( h + 30 ) / 25.4 * dpi } px

Would that be mathematically correct based on en.wikipedia.org/wiki/Fractional_part?

Alright, it seems that curly brackets aren't necessarily telling clearly what what to do with their content, so the clearer equation would likely be:

y = h - frac( ( h + 30 ) / 25.4 * dpi ) px

Where h = initial page height in mm.

[loukash]

Another day, another workaround, one that works in APu v1 for sure (I will have to reboot the Mac to Catalina to test it in v2):

1. Select your New Document preset, assuming you want DPI ~300
2. Change units to Pixel
3. Round all values to the next integer pixel
4. 1 page only! do not create multiple pages yet!
5. Once the blank document is created, go to Document Setup > DPI: 299.72 – now it will stick, unlike in the New Document dialog.
6. Add as many pages you wish (tested with 1000).
7. As long as you have Force pixel alignment active, all objects should be pixel aligned even on page 1000.
8. You can now switch document units back to mm/inch/whatever.
   Note that objects with integer mm values logically won't always fully align to the pixel grid. 
   But 10 mm = 118 px, so alignment and sizes in 5 mm steps will still snap to the grid.

The trick:
DPI 299.72 will set the firm 30 mm vertical gap between spreads to integer 354 px.
Thus since every page now has an integer pixel height as well, fractions of pixels won't add up. (Well, perhaps there might be a minor rounding error if you line up like 10000 spreads DIN A0…)

If you need/want to align to integer 1 mm, then you should apply DPI 304.8 in step 5 – i.e. the spread gap will then be integer 360 px.
1 mm @ 304.8 DPI = 12 px, so you can easily align in 0.25 mm steps.

[loukash]

On iPad, APu 2 doesn't accept fractional DPI values, it will round up or down.
So the only workaround to keep pixel grid alignment over multiple spreads is to use integer DPI that will convert those stupid 30 mm into integer pixels.
And there are not many candidates. The math is fairly simple, and one of those values will surely look familiar:

DPI 127
DPI 254
DPI 381

Yep, DPI 254 should look familiar to you because 1 inch = 25.4 mm.

Serif, please fix this disaster!

[loukash]

7 hours ago, loukash said:

(I will have to reboot the Mac to Catalina to test it in v2)

Bad news.
Same as on iPad, the DPI field rounds fractions to integer. So the only DPI values that will keep all pages aligned to pixel grid are 127, 254, 381, 508, 635, 762 etc.

Or go back to v1 where you can enter fractional DPI as per my workaround above.

[loukash]

Now for some good news:

For a print workflow, it seems that at least some of the misalignment is only a display issue:
If I export a PDF/X-4 or Press Ready from a page that appears totally off pixel grid in Photo persona, all "numerically" aligned pixel objects are aligned nonetheless, incl. pixel brush strokes.

Not so if I export to bitmap format, or PDF/X-1, X-3: rasterized vector objects will be off the pixel grid like on the display preview.