Publisher V2 calculates size of placed PDF files incorrectly

[LEpete]

I'm using Publisher 2 (v 2.0.3) on macOS 12.6.2., Intel Macbook Pro 2019, hardware acceleration is turned on.

Publisher shows the the size and scaling of placed PDF-files in pixels and dpi (this is the first mistake) in the upper left corner. The little dropdown offers a button "original size" to set back any scaling to 100%.

Even though it doesn't make any sense to show the size of PDFs (only) in pixels, the scaling in percent and the button "original size" are very usefull and absolutely indispensable when working with true to scale plans.

While the whole thing seems to work ok with PDFs that are vector based only, it breaks completely once there are pixel based elements in the placed PDF file. For some reason Publisher then estimates a wrong size of the PDF. Strangely enough, when placing the file it is shown and placed in the right size, but the scaling already shows a wrong percentage (of course it should 100% right after placing a new file). Pressing the button "original size" causes the placed file to get a wrong scaling, making it impossible to go back to the original scaling of placed documents.

As I said, it is essential when e.g. working with true to scale plans or something similar, to be able to controll the scaling of placed documents. The size of PDFs should never be shown in pixels only, since any PDF file has proper physical dimensions, that should be shown in whatever document units are set to (e.g. mm, inch...). Pressing the button "original size" should of course set the scaling to the original size.

Please fix this!

I think there is already a post about the same problem, but since it only describes the case of replacing PDFs but not the general problem with the scaling of any placed PDF I decided to open new topic.

pdf_test.zip

[loukash]

2 hours ago, LEpete said:

Publisher shows the the size and scaling of placed PDF-files in pixels and dpi

PDF is based on PostScript, so the same unit conventions apply:
https://en.wikipedia.org/wiki/PostScript#Units_of_length

I.e. pixels@dpi are essentially still the "native" PDF unit, based on "1 pt = 1 px @ 72 dpi".

3 hours ago, LEpete said:

The size of PDFs should never be shown in pixels only

You can always see the placed dimensions in your document units in the Transform panel and in the Resource Manager.
Correspondingly, if you place your example PDF at 100 %, the placed size will show exactly 201.676 × 142.578667 mm.

Since a placed PDF is usually intended to be printed from an APu document, pixels@dpi is definitely the most essential piece of information that I, for one, want to see when selecting the object. Especially if I know that the PDF contains pixels.

In other words, looks to me as being "by design", not a "bug".

You may want to post a feedback/feature request in the corresponding forum if you think that the info display in the context toolbar should be switchable to other units.

[loukash]

Upon further inspection:

• T02-test_pixel.pdf contains images @144 dpi. APu respects that, hence the absolute size 2382×1684 @ 144 dpi = 1191×842 pt
  Since you're placing the PDF directly by clicking with the Place tool on the page, APu assumes you may want to fill the page and scales the PDF correspondingly while your document resolution is set to 300 dpi. That's definitely by design.
• T01-test.pdf doesn't contain any resolution info whatsoever because there are no pixels. Hence APu can only assume the default PDF resolution which is – as noted above – 72 dpi = 1191×842 pt = 1191×842 "px". Since the content is all vector, it doesn't even make a difference. Again, looks to me "by design", not a bug.

So if you want them both to be placed at exactly the size you want, place them into Picture Frames of the same size. That's what they are meant for.

Edited January 12, 2023 by loukash
copypasta the wrong value… :)

[LEpete]

23 minutes ago, loukash said:

PDF is based on PostScript, so the same unit conventions apply:
https://en.wikipedia.org/wiki/PostScript#Units_of_length

I.e. pixels@dpi are essentially still the "native" PDF unit, based on "1 pt = 1 px @ 72 dpi".

You can always see the placed dimensions in your document units in the Transform panel and in the Resource Manager.
Correspondingly, if you place your example PDF at 100 %, the placed size will show exactly 201.676 × 142.578667 mm.

Since a placed PDF is usually intended to be printed from an APu document, pixels@dpi is definitely the most essential piece of information that I, for one, want to see when selecting the object. Especially if I know that the PDF contains pixels.

In other words, looks to me as being "by design", not a "bug".

You may want to post a feedback/feature request in the corresponding forum if you think that the info display in the context toolbar should be switchable to other units.

You may be right about the technical background with PostScript that uses pt, but I disagree with your conclusion that the resolution of a placed PDF (pixely@dpi) is the most essential information in this case. As far as I know, one PDF can include multiple pixel based images with different dpi, and also might be vector only. So in both cases (probably the most cases), the shown information pixels@dpi are useless or simply wrong.

Using the Transform panel only helps a little. Once a placed PDF is scaled and not the original size anymore, you can't simply jump back to 100%, unless you know the exact dimensions of the file. The button in the shown screenshot above should of course do exactly this operation, but it doesn't, since AP calculates the size of the PDF wrong.

You can try in the attached sample file (first post): On page 2, select the placed PDF and press the button "original size". The page and the placed PDF are both DIN A3, but pressing the button resizes the placed file to something different. In my opinion, this behavior can't be "by design" as you mentioned. I can't think of any useful application.

[loukash]

31 minutes ago, LEpete said:

On page 2, select the placed PDF and press the button "original size". The page and the placed PDF are both DIN A3, but pressing the button resizes the placed file to something different. In my opinion, this behavior can't be "by design" as you mentioned. I can't think of any useful application.

45 minutes ago, loukash said:

APu can only assume the default PDF resolution which is – as noted above – 72 dpi

^ Alright, that's what APu 1 does. (I got a bit confused as I had both versions open and placed the PDFs into each.)

Whereas APu 2 assumes the DPI of the target document, i.e. 300, if the PDF contains no pixel image and thus no dpi resolution info.

So here I am not sure if it's a bug or "by design". 
You are definitely correct that the original dimensions info is then lost.

(That aside, while placing your example image a few times into a blank document, Publisher 2 crashed on me three times. There's definitely a reason why I'm sticking with v1 for the time being… )

[LEpete]

Sorry, I missed your second post while typing...

19 minutes ago, loukash said:

• T02-test_pixel.pdf contains images @144 dpi. APu respects that, hence the absolute size 2382×1684 @ 144 dpi = 1191×842 pt
  Since you're placing the PDF directly by clicking with the Place tool on the page, APu assumes you may want to fill the page and scales the PDF correspondingly while your document resolution is set to 300 dpi. That's definitely by design.

I don't know what you mean by "fill" the page. Doing exactly the same but in a new file with document size A4, the placed files are still placed as A3 and not scaled donw to fill and fit the page. I think this is rather raleted to the document settings DPI. They are set to 300 dpi.

19 minutes ago, loukash said:

• T01-test.pdf doesn't contain any resolution info whatsoever because there are no pixels. Hence APu can only assume the default PDF resolution which is – as noted above – 72 dpi = 1191×842 pt = 1191×842 "px". Since the content is all vector, it doesn't even make a difference. Again, looks to me "by design", not a bug.

But it doesn't scale like its 72 dpi, it thinks it is 300 dpi (see first screenshot). Probably again just the 300 dpi from the document settings. But in this case, it's right and even the button "original size" works as intended.

19 minutes ago, loukash said:

So if you want them both to be placed at exactly the size you want, place them into Picture Frames of the same size. That's what they are meant for.

That doesn't help with the scaling problem. I want to have the button "original size" resize the placed PDF to its original size (100%) in means of physical dimensions (mm, cm, inch...).

[LEpete]

1 minute ago, loukash said:

^ Alright, that's what APu 1 does. (I got a bit confused as I had both versions open and placed the PDFs into each.)

Whereas APu 2 assumes the DPI of the target document, i.e. 300, if the PDF contains no pixel image and thus no dpi resolution info.

So here I am not sure if it's a bug or "by design". 
You are definitely correct that the original dimensions info is then lost.

(That aside, while placing your example image a few times into a blank document, Publisher 2 crashed on me three times. There's defintely a reason why I'm sticking with v1 for the time being… )

Yes, it does crash often and feels very slow when placing PDFs, even with small simple files. Placing PDFs seems to me like a big construction site in AP, not ready to use at all!

Thanks for your feedback anyway!

[loukash]

5 minutes ago, LEpete said:

I don't know what you mean by "fill" the page. Doing exactly the same but in a new file with document size A4, the placed files are still placed as A3 and not scaled donw to fill and fit the page.

You're right, my bad, wrong assumption on my part… 

7 minutes ago, LEpete said:

Probably again just the 300 dpi from the document settings.

I tested it a few times now, and yes: v2 defintely assumes DPI based on document settings for vector-only PDFs.
But as noted, in general that doesn't make that much of a difference because vector objects don't have any "resolution".

(I'll have to reboot my Mac to El Capitan to check out how InDesign CS5.5 handles this.)

 

[vixm]

1 hour ago, loukash said:

I.e. pixels@dpi are essentially still the "native" PDF unit, based on "1 pt = 1 px @ 72 dpi".

Sorry, but this is blatantly wrong. The native PDF unit is the Postscript point (1/72 inch), a real world physical length, and has nothing to do with pixels or dpi. You can define another user space unit for convenience when programming a PDF, but only relative to points, so always a physical unit. If you wanted to work in mm, you would set UserUnit to 2.834645669291339 for example.

The entire purpose of PDF (it's in the name: portable) is output device independence. That includes ppi/dpi independence. In this case, we can think of the Publisher document like an "output device". Publisher is likely breaching the PDF specification too, by displaying the wrong 100% size for placed PDFs.

Other than dealing with contained pixel images, or special considerations when rendering on a raster output device, PDF does not care about pixels or dpi, and the specification barely mentions either of those terms. But please don't take it from me. Have a read:

https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.7old.pdf (page 200).

1 hour ago, loukash said:

Since a placed PDF is usually intended to be printed from an APu document, pixels@dpi is definitely the most essential piece of information that I, for one, want to see when selecting the object. Especially if I know that the PDF contains pixels.

I don't get this. If you're printing, shouldn't you be more concerned about making sure things have their true physical size on page? I can understand wanting all your images to hit a minimum ppi for print output, but DPI estimation doesn't show you this. It only shows the maximum image ppi found inside the PDF.

You can have a 600ppi image and a 72ppi image in the same PDF, and you'll never know the 72 is there unless you pick the PDF apart manually. Publisher will happily keep showing you 600.

That said, I've already shown that Publisher will passthrough the full resolution image from a placed PDF, to Publisher's PDF export, regardless of the Publisher document dpi setting, in this post: 

A 600dpi image, inside a PDF, placed inside a 300dpi Publisher doc, will retain all its dpi when exported (unless you turn on image resampling in PDF settings), so you have even less to worry about. This is great.

If I wanted to turn this "find image DPIs within a PDF" thing into a truly useful tool, I would probably put it in the resource manager, or another panel, and show all of the following values:

Minimum actual ppi within placed file (at 100% physical scale)
Maximum actual ppi within placed file (at 100% physical scale)
Minimum effective ppi within placed file (image ppi at present scale on page)
Maximum effective ppi within placed file (image ppi at present scale on page))

The last 2 would change as you scale the file up and down inside Publisher, providing some great feedback, I agree. But the functionality you have now isn't this, and it's not worth breaking placed file scaling for.

[loukash]

2 minutes ago, vixm said:

Sorry, but this is blatantly wrong. The native PDF unit is the Postscript point (1/72 inch)

That's what I meant but it may have been lost in translation, English being only my 3rd language.