vixm

I'm using macOS 12.6.2 with the current release versions of Publisher 2 and Designer 2 (2.0.3 in both cases). Summary: Embedded placed PDFs can get stuck in interpret mode, and changing the dropdown to passthrough does not switch them back. Steps to recreate: 1) Create an Illustrator file (or PDF) with a visually obvious interpret issue (eg. missing font), and make sure it defines a BleedBox bigger than its TrimBox2) Place and embed it into Publisher or Designer, using the default TrimBox3) Switch it from Passthrough to Interpret4) Switch the page box from TrimBox to BleedBox5) Switch from Interpret back to Passthrough The file is now stuck in interpret mode, no matter the setting chosen in the menu. Additionally, it is stuck rendering the TrimBox no matter what, just scaling it up and down to match the size of the BleedBox, or whatever other box is selected. Notes: This happens for .pdf and .ai files, so isn't specific to .ai. It also happens for PDFs exported from the Affinity apps. It affects the export result as well as the on screen display. Saving the Publisher file that the PDF is placed into, then reopening it, fixes both appearances, as well as the page box issue. The first file I noticed it on was one where I didn't have a font installed (1 Litre.pdf in error.zip attached), so I thought it was related to missing fonts. However, it doesn't happen with some of the files in no error.zip attached, which are missing this font, so I'm not really sure what differentiates them. I also removed the text from 1 Litre.pdf and it still happens. error.zip no error.zip

I'm using Publisher 2.0.3 on mac OS 12.6.2, with GPU acceleration turned on. Summary: If you use Resource Manager to replace a passthrough PDF, while not viewing the page that the file is placed on, the preview in the Pages panel doesn't update with the new file until you touch it again. How to recreate: 1) Create a Publisher file with 2 pages. 2) Place a PDF on page 1 in passthrough mode. 3) View page 2 in the main window. 4) Using Resource Manager, replace the PDF. The page preview in the Pages panel won't update. 5) View page 1 in the main window. Main view will update, but not the preview in Pages panel. 6) Draw a rectangle on page 1. Pages panel preview still doesn't update. 7) Move the placed file to a different location on the page. Pages panel preview will update. This only happens for PDF or Illustrator files (essentially PDF) in passthrough mode. Does not happen for pixel images, Affinity documents, or interpreted PDFs. It happens whether the PDF is within a picture frame or not.

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). 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.

I'm using macOS 12.6.2 with the current release versions of Publisher 2 and Designer 2 (2.0.3 in both cases). I've been testing some more and this is more inconsistent than I thought. I can make it happen with a PDF exported from Designer that has nothing but 2 rectangles in it. It happens with the original PDF I had the problem with, even if I remove the offending text. But then I export a PDF with a missing font (https://www.fontshare.com/fonts/aktura) from both Illustrator and Designer, and it doesn't happen. Files mentioned above and more are attached. The ones in "error.zip" recreate the issue. The ones in "no error.zip" don't. I don't understand why. There was another problem where colors appear wrong temporarily as soon as the file is placed (green looks teal instead). If I only switch from passthrough to interpret and back (not all the steps in #3), it fixes that, and the file always looks right after. I didn't get a screenshot of this, and can't seem to recreate. Will post if I do. I also made this happen again just now in Publisher. It's interpreting on screen, the export preview is doing something weird where 100C+100Y CMYK green shows as 255G RGB, and the scale is off, but then the PDF exports perfectly, correct size, passing through the PDF font embed and all. The file I'm using here is "1 Litre.pdf" from the error.zip file attached. At this point it wasn't even embedded, nor did I do any of the remaining steps in #3 of my last post. As soon as I placed it, this happened. error.zip no error.zip afpub export of placed 1 Litre PDF.pdf

Ok, I ran into this again today, and the behavior I saw is clearly a bug, rather than a missing feature. Can this thread be moved please? Here are my observations: 1) This is irrelevant. The Affinity apps depend on having a PDF compatible Illustrator file, and a file saved without that will not render at all. It's a choice between interpreting or passing through the PDF data. Great. 2) The Passthrough/Interpret menu is only available for .ai files when they're embedded, not linked, unlike .pdf. The default is Passthrough though. My original request is still partially valid. Can we expose this setting for .ai files in linked mode too? Or is the intention that .ai files are never interpreted when placed? 3) This menu can say "Passthrough" while getting stuck interpreting. To recreate: a) Create an Illustrator file (or PDF) with a visually obvious interpret issue (eg. missing font), and make sure it defines a BleedBox bigger than its TrimBox b) Place and embed it into Publisher or Designer, using the default TrimBox c) Switch it from Passthrough to Interpret d) Switch the page box from TrimBox to BleedBox e) Switch from Interpret back to Passthrough The file is now stuck in interpret mode, no matter the setting chosen in the menu. Additionally, it is stuck rendering the TrimBox no matter what, just scaling it up and down to match the size of the BleedBox, or whatever other box is selected. 4) This happens for .pdf and .ai files, so isn't specific to .ai. It also happens for PDFs exported from the Affinity apps. 5) It affects the export result as well as the on screen display. 6) Saving the Affinity file that the PDF is placed into, then reopening it, fixes both appearances, as well as the page box issue. I noticed other erratic behavior too, but this is the only one I could figure out how to recreate reliably. I'm hoping the solution to this fixes the other issues. I've seen it render on screen as passthrough, while interpreting for export, and vice versa. At one point switching from Passthrough to Interpret would be instantaneous, but going the other way would take 5 or 6 seconds, not that I ever need to do that. I was just testing. I got it into a state where, if you carry out the steps in #3 first, any further instances of the same file, placed into the same document, would be stuck the same way immediately upon placing, but it doesn't always do that. This is probably what was happening in my first post, and why I thought renaming to .pdf was working? It was being seen as a unique file. I'm still not sure what happened, because I almost never embed files, so there must some other trigger. I definitely had .ai files being interpreted with messed up text. If I figure out how to recreate any of the other issues, I'll post.

When selecting which pages of a Publisher document you want to export, the UI currently looks like this: This will export the current page. This will export all pages. And this will export only the first page. I think a "Range" option should be added to the dropdown menu, and only have the text field active when that option is selected, not "All Pages". If there's anything already in the text field, selecting "All Pages" from the dropdown does not clear it. Many times I've done this, thinking I'm exporting all pages, but forgot to clear the text field, and exported less than the full document. Better yet, make them radio buttons with the text field next to the "Range" one.

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

Yes, I understand what is happening. I'm saying this behavior is wrong, especially in an app called "Publisher". 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: 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. 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? 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.

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".

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

Hi, 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. When I set a picture frame's scaling to "None", that setting isn't honored when using "Replace File" or when dragging a new file into the picture frame. Instead, it does a min fit based on the bounding box of the outgoing file for some reason. Example: I create a 1x1" picture frame with scaling set to "none" and drag a 2x1.25" file into it. The central 1x1" area shows. I drag a 2x2" file into the same picture frame, expecting its central 1x1" to show, but it's placed at 1.25x1.25" (62.5% scale), showing more than its central 1x1" area. It's being min fit into the 2x1.25" bounding box of the previous file. If I drag the 2x1.25" file back into the frame, it's now min fit to the 1.25" width of the outgoing file, and its height becomes 0.781". If I keep repeating this process, the area used for the file within the frame gets progressively smaller. I've attached test files to recreate the issue with. The "none" scaling setting works as expected (place the file at its native size and crop to the frame) when the frame is empty (either the placed file was deleted or the frame is newly created), so I'm not sure why the replace behavior is different. It feels like there's an invisible container between the outgoing file and the frame, and the incoming file is being min fit to that? If there is, the constraints for the file aren't editable, so there's no way to control that. I can get most of the desired behavior by placing a file, masking it with a rectangle, and disabling all constraints on the file, but then I lose the drag and drop functionality of frames. Hope this can get fixed. Thanks! 2x2.pdf 2x125.pdf

When dragging a file from Finder directly into an occupied picture frame, it also always uses TrimBox, even if the file already in the frame used MediaBox. The Replace function at least preserves the choice of the file being replaced.

Currently Publisher always places using TrimBox, but I need to use MediaBox most of the time. Thanks!

Hi, I'm testing out Designer and Photo for use as Acrobat's Object and Image Editors respectively. This is useful (compared to importing into Designer), when you might not have access to all the required fonts (Acrobat uses the embedded fonts), or the layout breaks on import to Designer, but you still need to edit certain elements of the PDF, eg. change the color of a shape, adjust brightness of a photo etc. With the PDF open in Acrobat, you first select objects to edit, then Acrobat creates a "subset PDF" with just those objects, saves it to a temp directory, and automatically opens it in your editor of choice. After editing, you're meant to overwrite that "subset PDF" and return to Acrobat. Acrobat detects the changed file and reflects those changes in the original PDF. When using Illustrator and Photoshop as Acrobat's designated editors, they naturally prompt you to save changes directly to that "subset PDF" after editing and closing, so the workflow is fairly seamless. With Designer or Photo, the prompt is to save a new .afdesign or .afphoto file instead. To make this work, I have to click File > Reveal in Finder in Designer, then File > Export, and drag the file from Finder into the export dialog, telling Designer it to overwrite. It would be great to avoid all the extra steps by adding a "Save over PDF" option similar to the existing "Save over PSD". Under the hood it could do the same steps I've been doing manually, and maybe add a second preference to select which PDF export profile to use when saving? Thanks!

Hi, I do page layouts in Publisher (but this could be applied to all three apps), where I need to place files supplied by others. Most of the time I'm sent PDFs, but often enough I get Illustrator files. The only behavior when placing an Illustrator file in Publisher is to interpret it, which doesn't always preserve the layout correctly. Illustrator files have been able to embed a PDF version into the .ai file for about 20 years now, and that behavior has been default for at least 15 years IIRC. Could we get the option for Publisher to use that PDF data, with passthrough, then fall back to interpreting the Illustrator data (with a warning?), in the unlikely event that PDF data isn't present? IMO this should be default behavior, but I'm fine with having to enable it manually. Currently I rename .ai files to .pdf. That tricks Publisher into seeing the PDF data and doing passthrough. It works perfectly, but it would be nice to skip the renaming. Thanks!