DPI estimation affects scaling when replacing PDFs

[vixm]

I'm using the latest release version of Publisher on mac OS 12.6.2. Hardware acceleration is turned on. I've tested with a new document, as well as quitting the app, restarting, then opening a new document.

Steps to recreate:
1) In a new document, create a rectangle and set its size to 2x2"
2) Place 300 dpi.pdf, align it with the rectangle and make the rectangle its parent.
3) Turn off all constraints on the placed file. The cyan center and red outer area should be visible.
4) Use "replace document" to replace it with 600 dpi.pdf. Now only the center cyan area is visible, since the placed file is 4x4" instead of the intended 2x2". You can verify in resource manager that placed dpi is 300 instead of 600.

I think Publisher is doing what happens in Designer if you try to open a PDF directly. It's looking for the highest DPI image within the PDF and setting that as its "resolution". It's then trying to place the incoming file at the same DPI as the outgoing file, which causes the scaling. 600 dpi directly mapped onto 300 results in a 2x enlargement.

I created both files in Illustrator. Both are identical, including artboard size (2x2"), except for the background. Each one uses a raster PNG for its background with resolution corresponding to the filename. Both files were exported with PDF settings set to not downscale images, which is key to recreating this problem, and is something I still encounter regularly, despite the PDF/X presets existing.

I don't think this is the right behavior when replacing a file, especially something like PDF where there are defined physical dimensions. My goal above was to create a "frame" that would show the central 2x2" area of any PDF placed into it, regardless of size or resolution, but it's not possible.

Speaking of frames, this behavior isn't exhibited when using a picture frame, but that isn't necessarily because the picture frame is handling the file dimensions correctly. It's forcing min fit, as I've shown in another bug posted here, which breaks "none" scaling entirely when using the replace file feature.

Notably, this only happens when replacing an existing file. I can drag any "resolution" PDF directly into the document, or into an empty picture frame, and it shows up at accurate physical size with the correct (estimated) dpi showing up as the placed dpi in resource manager, i.e. 100% scaling.

300 dpi.pdf 600 dpi.pdf

[Hangman]

Unless I'm doing something differently to you, I'm not seeing that behaviour...

[vixm]

You skipped the step where I removed constraints on the 300dpi file before replacing, so yours is auto scaling.

Look at the dropdown after you place the 600dpi file. It says scale is 50%, which means it's seeing the 2x2" 600dpi file as 4x4".

 

[Hangman]

The key 'point' here is that your two pdf files use png backgrounds rather than vector backgrounds so subsequently the files have an actual resolution and you have the following:

• a 2" x 2" (600 px x 600 px), 300 dpi file which when placed in a 300 dpi document and displayed @ 100% (unconstrained) correctly appears at 2" x 2"
• a 2" x 2" (1,200 px x 1,200 px), 600 dpi file which when placed in a 300 dpi document and displayed @ 100% (unconstrained) correctly appears at 4" x 4"

So when unconstrained you are seeing the files displayed correctly at their respective sizes relative to the document dpi.

If you have a vector background for both (i.e., all the elements of the pdf file are vector) you won't see this scaling because the pdf documents will then be rendered at the desired resolution of the output device whether screen or printer.

 

22 hours ago, vixm said:

Notably, this only happens when replacing an existing file. I can drag any "resolution" PDF directly into the document, or into an empty picture frame, and it shows up at accurate physical size with the correct (estimated) dpi showing up as the placed dpi in resource manager, i.e. 100% scaling.

That is because, when dragging the pdf's directly onto the canvas they are constrained by default, if you select the pdf's you will see the constraints are on so you are seeing the following:

• a 2" x 2" (600 px x 600 px) file rendered at the document resolution of 300 dpi displayed @ 100% (constrained by default) which correctly appears at 2" x 2"
• a 4" x 4" (1,200 px x 1,200 px) file rendered at the document resolution of 300 dpi displayed @ 50% (constrained by default) which correctly appears at 2" x 2"

If you drag both your pdf's directly onto the canvas, select both and remove the default constraints, select the 600dpi file and select Original Size from the context menu dropdown so it's now dispalyed at 100% then you will also see it at its 100% unconstrained size which is 4" x 4".

For purely vector pdf files, Resource Manager and the Context Menu are misleading in as much as the displayed Original DPI is largely meaningless... Place both vector only pdf files in a 300 dpi Publisher document and the Original DPI for both is shown as 300 DPI, do the same in a 600 dpi Publisher Document and the Original DPI for both is shown as 600 dpi regardless of the DPI of the source document used to create them, again, this is because only raster images have a resolution.

Publisher Documents 300 dpi Top | 600 dpi Bottom (Note the Original DPI Shown for the same file)

[vixm]

Yes, I understand what is happening. I'm saying this behavior is wrong, especially in an app called "Publisher".

5 hours ago, Hangman said:

subsequently the files have an actual resolution and you have the following

No, they don't. This is something the Affinity apps are ascribing to the PDF. I understand why DPI estimation can be useful when directly opening a PDF in Designer for example, and I use it there, but this isn't the place for that. A PDF doesn't have a true "resolution" or DPI, only physical size.

The PDF standard is built on one physical unit, the point (1/72 of an inch). Everything else (inches, mm, cm, feet) is just a visual conversion, but still a physical unit that has an exact conversion back to points, so it stays consistent. A PDF can contain raster images, but the raster images don't determine some inherent resolution for the PDF. It's the other way around. The PDF tells the raster image what physical size it should be, and that determines the DPI of that specific instance of the image, in the context of that PDF. The same image could be repeated, on the same page, or in a different file, scaled up or down, and its DPI will be different.

If I'm using Publisher with my units set to points, inches (or any other physical unit), then physical size should always be the basis for determining scale, not pixel based scaling, and definitely not using the highest DPI image contained in the PDF as a reference. The size at 100% scale in Publisher, should be exactly what the PDF says the physical size of its page box is, ignoring all contents of the file. That's how it behaves when placing a file, but not replacing.

But even place isn't working correctly. You're supporting my point by showing that the "correct" place behavior is also just a workaround for the incorrect scaling model:

5 hours ago, Hangman said:

That is because, when dragging the pdf's directly onto the canvas they are constrained by default, if you select the pdf's you will see the constraints are on so you are seeing the following:

• a 2" x 2" (600 px x 600 px) file rendered at the document resolution of 300 dpi displayed @ 100% (constrained by default) which correctly appears at 2" x 2"
• a 4" x 4" (1,200 px x 1,200 px) file rendered at the document resolution of 300 dpi displayed @ 50% (constrained by default) which correctly appears at 2" x 2"

If my 600dpi file renders at 2x2" when dragged in, that means somewhere in the place function, it decides to honor the PDF page box and creates a bounding box at the correct physical size. Then, since scaling is based on pixels, the only way to fit the file into that box, is to "scale" it to "50%" on a pixel basis. Publisher is calculating everything in pixels rather than points.

Sidenote: You mentioned constraints here. That has nothing to do with it, other than helping hide the problem. If you replace a file with another of exactly the same aspect ratio, with default constraints enabled, everything looks right. The default constraints will adjust the scale value up and down, so regardless of DPI estimation, the incoming file fits the existing bounding box. But if you start cycling through files with different aspect ratios, the bounding box (and physical size of the image) shrinks continuously with each replace. Replacing with the original file doesn't restore it to original size. It has to be deleted and then do a new place operation. This is correct behavior if you want a "min fit within the old bounding box" constraint, but it is what I was trying to get away from by disabling constraints.

Where did the 4x4" come from in your second bullet above? It's a 2x2" PDF that happens to have a 600dpi image inside it. That doesn't make it 4x4". Ideally, the line next to "linked document" in Publisher should read: 2" x 2" (100%) and say nothing about pixels. I can't find anywhere in InDesign that shows the "dpi/ppi" of a linked PDF. It simply isn't a concept.

If you place a raster file (JPG, PNG etc.) into InDesign, then you see values for actual ppi (before scaling, read from file) and effective ppi (after scaling, size on page), because InDesign needs to work backwards from the pixel size of the raster, and its ppi, to calculate it's physical size on page. This is the opposite of PDF, where the physical size is defined.

5 hours ago, Hangman said:

For purely vector pdf files, Resource Manager and the Context Menu are misleading in as much as the displayed Original DPI is largely meaningless...

As you say, pixels are meaningless when dealing with vectors. The same is mostly true for PDFs, except that they can contain rasters with arbitrary DPI. That doesn't mean the rasters should drive the rendering size of the PDF. It isn't that way within the PDF. Why should it be when we go one level up into Publisher? What's the point of PDF page boxes at all then?

5 hours ago, Hangman said:

If you have a vector background for both (i.e., all the elements of the pdf file are vector) you won't see this scaling

This isn't realistic. I can't even get people to consistently save with a PDF/X preset, but I'm supposed to tell them only use vectors? No photos?

What happens if someone scales down a photo in a linked PDF, overwrites the file, then I open a Publisher layout and it automatically relinks the file? If I used no constraints, the whole placed PDF gets scaled up in Publisher, just so that one image inside the PDF maintains its size. That is ridiculous. It disrespects the PDF page box entirely.

If that was an ad that needed to fill a 3x3" area, now its 4x4" but still being clipped to 3x3" and 0.5" all around is gone. That's the entire margin and probably a lot of text. Problems.

Solutions?

I understand what's wrong conceptually here, but I don't care, as long as I can stop layouts from breaking. It doesn't personally affect me if calculations are done in pixels under the hood. Or if a 2x2" file with a 600dpi background says it's "50%" when it should say "100%". I'm only looking at the size in inches anyway.

Suggestions:

1) Keep pixel based scaling, but force bounding box = PDF page box * Publisher document DPI, regardless of DPI estimation. My "600dpi" file will end up with a page box of 600x600px @ 2x2", but since the pixel size is always calculated from the page box, the DPI of images within the PDF can change freely. No idea how practical this is.

That still doesn't fix the replace behavior specifically, so

2) Make the "replace" function mimic the "place" function. Delete the outgoing file, but save its scale (which will be consistent now since the only dpi we care about is the setting in Publisher), and the center anchor of its bounding box. Place the new file at that center anchor, calculating its initial size as in #1, then apply the scale value.

3) Maybe #1 isn't even needed? If you have the "dpi", scale factor (pixel basis), and pixel dimensions of the outgoing file, you should be able to calculate its original physical size, and its scale factor (physical basis). Do #2, but respecting the page box as "100%", like the place function currently does, then calculate and apply whatever pixel scaling value is needed to restore the previous physical scaling value.

#3 might be susceptible to carried forward rounding errors? Maybe store a physical scale value along with the pixel based one to avoid that?

Just some ideas. Hope this can get fixed. Thanks.

[vixm]

I wondered what would happen if, instead of using PDFs, I tried placing .afdesign files into Publisher files. Using the same 1200x1200 px and 600x600 px PNG backgrounds I started with before, I created two Designer files:

600px-bg = Designer resolution set to 300dpi. Placed the 600x600 PNG @ 2"x2" for its background, 300 effective dpi.
1200px-bg = Designer resolution set to 300dpi. Placed the 1200x1200 PNG @ 2"x2" for its background 600 effective dpi.

When either of these files is placed (or replaced) into a Publisher document (set to 300dpi), they behave exactly the same. Publisher is seeing the dpi set in Designer, so it has no estimation to do. Since it's always seeing 300dpi, they both show up as 2x2" or "600x600px @ 100%", even though 1200px-bg contains a 1200px image.

Furthermore, when 1200px-bg is placed into Publisher, then exported to PDF (downsample images turned off), the resulting file has a 1200px 2x2" square raster (see 1200px export.pdf). Publisher correctly exports the image contained in the .afdesign file, as-is (600dpi), even though everything is set to 300dpi. If I use the PDF from my first post, I get the same result, which is great.

PDFs should behave at least as well as Designer files do when placed. But PDFs don't tell Publisher their dpi, since that isn't a thing. DPI estimation tries to guess, but we've already seen the problem that causes. Maybe an option to force placed PDF dpi = document dpi could be added as a workaround? That would bypass the estimation and let it behave like a Designer file? Since it doesn't affect raster export resolution, there's no downside.

Sidenote: If I make 2 Designer files, where one is set to 300dpi, and the second is set to 600dpi, they exhibit the same behavior as the PDFs in my first post. This wasn't surprising, but points at a fundamental flaw in how Designer and Publisher deal with sizes. Even if a native document has defined physical dimensions, everything is being scaled via dpi estimation (or explicit dpi from Designer in this case), in terms of pixels.

With the 600dpi PNG too, dragging it directly into either Publisher or Designer results in a 4x4" image which I have to manually scale down to its correct size. That PNG has its ppi set to 600, but it's being ignored. Dragging the same file into Illustrator, regardless of the document's raster dpi, gives 2x2" @ 100%. Same for InDesign.

If document units are set to pixels, this behavior is fine, and should be expected, but not when using inches, cm, points etc. If I'm set to physical units, I don't want to think about the dpi/ppi values of incoming files at all if they have physical units. Those should be honored over everything else, including using ppi values in raster images to calculate their physical size.

Could there be a global setting added to all the applications for this? Something like "Always honor placed file dimensions"? I'm sure some people prefer the current behavior, but I think this would be more intuitive, and a big timesaver for many users, not to mention eliminating a source of error and confusion.

600px-bg.afdesign 1200px export.pdf 1200px-bg.afdesign PNGs.zip

[LEpete]

Hi, I think I have basically the same problem, but since you only describe the case when replacing PDFs, I opened another topic.