Ken Hjulstrom

Hi lacerto, Thank you for the detailed information. Since I don't have direct contact with the new print shop representative, it's a bit difficult to get any more parameters from them than the one I posted here intiailly, but I used a "Compatibility" value of PDF/X4 for the current print shop, so I'm going to stick with that unless the new print shop has a problem with that setting, at which time I'll be able to work with them directly to sort out any parameter issues. I'm preparing a magazine that contains articles from a variety of authors, and most of the submitted articles are accompanied by image files that come from all sorts of sources. I don't believe, though, that any of the images particularly contain CMYK colors, and I use Affinity Photo to convert all submitted image files to TIFF for inclusion in the magazine file. I'm not sure if this conversion guarantees that all of the image files will contain RGB colors only, though. Your comment about PDF/X-4 not converting color spaces led to something interesting in my Publisher Export dialog. As I stated in my initial post, I've been using PDF/X-4 Compatibility, and with the "Convert color spaces" checkbox unchecked. Just for fun, I tried checking that box while I still had the PDF/X-4 compatibility specified, and clicking on the unchecked checkbox had no effect, which makes sense to me, if PDF/X-4 doesn't support color space conversion. I then switched the compatibility to "PDF/X-3 2003", and I was then able to check the "Convert color spaces checkbox". But I then switched the compatibility setting back to PDF/X-4, expecting that the "Convert color spaces" checkbox would once again become unchecked, but to my surprise, it remained checked! I then unchecked that box, and I was unable to check it after that. A UI bug, perhaps? Thanks again for your help, Ken

Hi, My organization is switching to a new print shop, and the new print shop has provide the following information regarding how I should prepare the PDF document for submission: "only thing I would suggest is exporting the PDF with Output set to "Convert to Destination (preserve numbers)" and use the "US Web Coated (SWOP) v2" color profile" I'm currently using the following Export options, which work well for our current print shop: Compatability: PDF/X-4 Color Space: As Document Profile: Use document profile Convert image color spaces: Unchecked Honor spot colors: Checked Overprint black: Checked I'm assuming that I should set the "Profile" export option to be "US Web Coated (SWOP) v2", but what combination of the other settings are equivalent to the InDesign "Convert to Destination (preserve numbers)" specification? Thanks! Ken I know that my "Profile" export option

Thanks! This approach makes sense, but it can be confusing if you don't know this approach, as there's no visible cue that this is what has to be done, nor did I find anything about creating presets in the Publisher "help" menu. Thanks again, Ken

Hi, I think I figured it out. Apparently, if I make a change to one of the settings of an existing preset, this enables the "Create preset" option. For a PDF export preset, changing the "Resample" value in my existing preset enabled the "Create preset" option, but changing the "Raster DPI" did not, so apparently, this only works for a subset of the export options. In my opinion, the "Create preset" should be enabled without the need to have to alter an existing preset, which to me is not only an obscure way to initiate the creation of a new preset, but is rather "scary", as I tend to not want to tweak export parameters that have been working well for a long time. My intial approach was to "make a copy first, and then alter it", which doesn't seem to be supported? Thanks, Ken

Hi, I'm using Publisher 2 2.3.0, and I'd like to make a copy of an existing Export preset that I created with a version of Publisher 1 back in 2020. When I open the "Export" dialog and select the Export preset that I created and then click on the "hamburger menu" icon to the right of the Preset dropdown, the only active options that are displayed are "Delete preset" and "Rename preset". The "Create preset" option is disabled. is this the correct approach to creating and/or copying presets, or is there another place in the UI where I should be doing this? Thanks! Ken

Hi thomaso, Thanks for the info. I've attached the following files: SpotlightOnly_31Aug23_v1.tiff: This is closer to the actual graphic that I'm placing, so recoloring the text portion in Publisher would be a bit difficult to accomplish, if it could be done at all. If I were actually placing a rectangle, I agree that just setting its fill color in Publisher would be the way to go. DesignerExportInfo.png: This is a screenshot of the export settings that I used in Designer. I wasn't able to get the 100 K in the exported file until I specified the "CMYK 8-bit" pixel format option. In the "ICC profile" options, there is one that's named "Generic CMYK Profile", but I didn't try that, since I figured that I had verified that the exported file's black color was in fact 100 K, then the export wasn't the source of my problem. But I could very well be wrong about this. PublisherDocumentColorInfo: This is from Publisher's "Document Setup" dialog. The color parameters here have been specified by the print shop, so I really don't want to change these. Your thoughts or suggestions would be appreciated. Thanks again, Ken

Hi, I created a TIFF image in Designer that contained CMYK text that was 100% black, placed it into a Publisher document, and was surprised when the exported PDF still displayed the supposedly 100% black content when I viewed it in Acrobat with the black channel disabled. While researching this, I created a CMYK rectangle in Designer, exported it as a TIFF, and opened the TIFF file in Photo, and verified with the Color Picker Tool that the black fill was actually CMYK 0,0,0,100. I then opened a new Publisher document and placed the rectangle TIFF file into it, and when I checked the color of the rectangle with the Color Picker Tool, it shows as CMYK 68,67,65,74, and not CMYK 0,0,0,0 as I expected.. Is this a bug, or am I doing something wrong here? Screenshots of Photo and Publisher, as well as the Designer-generated TIFF file are attached. Thanks, Ken CMYK_BlackRectangle.tiff

Hi, I periodically use Publisher 2 to create a magazine that contains many images. When I'm done, Preflight generates quite a few "Placed image DPI too low" messages" that I need to clear up in order to have a suitable press-ready PDF. Due to the nature of the magazine layout process, the original DPI of images may reduced below 300 DPI if it's sufficiently enlarged, and I ignore these warnings during the layout process, since there's no point in upsampling images until I'm sure of their final dimensions in the magazine. I've just finished my most recent magazine layout, and now have 79 images that need to be upsampled so they'll have a high enough resolution for printing. There doesn't seem to be a way to use Photo's batch job feature to do a bulk upsampling of these image files, since Photo can only "see" the internal DPI of the image files, and not how much the DPI has changed due to resizing of the images in the Publisher file. Currently, the way that I upsample these image files is to open each one in Photo, go to Document | Resize Document, and modify the "Width" value by multiplying it by "(desired_dpi / current_publisher_dpi)", and then exporting the file over the existing version. As an example, if the image width is 189 px, the current Publisher DPI of the image is 200 DPI, and I want the Publisher DPI for the image to be 325 DPI, I'd change the "189 px" width to be "(325/200)*189 px" and click "Resize", making sure that the "Resample" checkbox was checked, and then do File | Export to export the file over its old version. and then go back to Publisher's Resource Manager window and use the "Update" option to update the old version of the image in the document with the new one (all of the document's images are linked). Outside of using Photo's batch job facility to grossly upsample all of the images, is there any way to accomplish what I'm currently doing manually in a more efficient manner? It would be nice if there were some way that Publisher's Preflight would have an option to upsample each image for which a warning were displayed so it would end up with a consistent DPI of my choosing, but I don't believe that such functionality currently exists. But is there a more efficient way to accomplish what I need to do? Thanks, Ken

I'm currently working on a document that contains a number of spreadsheet screenshots with rectangular highlights around some of the cells. The highlights are constructed as rectangles with a red stroke and no fill. In order to bind the highlights to the screenshot, I've grouped them. When I'm setting up the next screenshot, I typically click on the "highlight rectangle" in the previous screenshot to select it, and then do command-c to copy it, followed by command-v to create a copy. When I do this, the second copy is still a member of the same group that the original belongs to, which poses a problem if I just drag the copy to its new location, as it will be bound to the incorrect screenshot. I know that I can use the "Layers" panel to drag it out of its original group, but I'm wondering if there might be an easier way to do this, such as using a modifier key during the "paste" or "drag" operation, which would "pull" it out of its group without my explicitly having to use the "Layers" panel to do this. Thanks, Ken

I just found what appears to be a bug in the paragraph "spacing" controls in Publisher ("Left Indent", "First Line Indent", "Right Indent", "Last Line Outdent", "Space Before Paragraph", and "Space After Paragraph". While copying and pasting values between these controls, I accidentally deleted the entire contents of one of these controls (I typically just select the numeric values for copying and pasting), and I noticed that the tool tip for this control no longer contained the text that describes the control's purpose, but instead contained the text "String is empty". This is technically correct, but when I used the associated spinner to repopulate the control with a numeric value, the tool tip still stated "String is empty". I was able to restore the correct tool tip text by selecting all of the text in the control, and manually entering a numeric value AND accompanying unit. Steps to reproduce: Open a new Publisher document (I don't think the initial settings matter at all) Using the Frame Text Tool, add a text frame to the blank page Type text into the text frame (it doesn't matter what text it is In the "Spacing" section of Paragraph properties, the upper left control will show an initial value (for me, it's "0 in". Hover the mouse pointer over this control, and the control, and a tool tip will appear that reads "Left Indent" (this is correct). Select all of the text in this control and delete it. The control is now empty, and hovering the mouse pointer over the control now reads "String is empty" (technically correct, but this starts to blur the line between whether the tool tip is reporting the purpose of the control vs. the validity of its contents). Click once on the up arrow portion of the adjacent spinner control. This will repopulate the control to what appears a valid value (for me, it's "0.01 in"). Hover the mouse pointer over the control, and the tool tip still reads "String is empty" Repeated use of the spinner control will change the displayed value, but the tool tip still will read "String is empty:. Curiously, while the input control is in this state, hovering over the same control in another Publisher document that's open at the same time will still result in the tool tip reading "String is empty". Select all of the text in the control and manually type "0.in" into the control. Hovering over the control now displays a correct tool tip, reading "Left Indent" I haven't tested this on similar input controls elsewhere in Publisher, or in Photo or Designer, but I wouldn't be surprised if all of these controls were susceptible to the same odd behavior. Also, while investigating this issue, I somehow got the tool tip text to display "A unit type modifier was found but not expected", but I haven't been able to reproduce this. Thanks, Ken

Yes, I just confirmed that that's exactly what the problem was. I set the keyboard setting to "ABC" and ran my test again, and there was no crash when pressing a key. While in the same file, I then switched the keyboard setting back to "Romaji", hit a key, and got the immediate crash. Thanks for noticing this. Ken

I tried using the Text Frame Tool to create the frame links, and I got the same results. Regarding the start side of the facing pages, I get the same results whether the start page is on the left or right. Actually, I first encountered this problem with the start page being on the right, but I switched it to the left, as it allowed both pages to appear side-by-side in the screen recording without the need to scroll up and down. Also, by accident, I just realized that the crash can be caused by pressing ANY key after setting the text frame links. I've caused the crash by pressing a letter key, the Shift key, and an arrow key.

Hi MikeTO, Attached here is a screen recording of my creating a new Publisher document that shows the crash. After setting up the text frame links, I hit the "Command" key, which caused Publisher to crash. Ken Screen Recording 2023-05-15 at 10.32.39 PM.mov

One workaround that I discovered is that if I use File | Save to save the document, then it saves fine, and the "Command" key crash does not appear to recur for that document. I typically use Command-S to save, though (or Command-Tab to cycle through open apps), and it took a while for me to figure out that it was the "Command" key press that was causing Publisher to crash. Ken

Here's a screenshot of what the document looks like just before pressing the "Command" key crashed Publisher. To create this from scratch, I did the following: File | New For page size, select "Letter" On the "Pages" tab, check "Facing Pages", for "Arrange", select "Horizontally", for "Start on", select "Left", and for "Number of pages", select "2". Click "Create". You should now have two empty pages displayed side-by-side. On the left page, use the Frame Text Tool to create two text frames on the page, not overlapping, and one to the right of the other. I don't believe their position on the page matters. On the right page, use the Frame Text Tool to create one text frame somewhere on the page. I don't believe that the position matters. With the Move tool active, click in the leftmost text frame on the left page to select it. Click on the "link node" on the lower part of the right edge of the frame. The frame will now be shaded blue. Move the mouse pointer over the rightmost text frame on the left page (it will become shaded blue), and then click in that frame to create a link between the left frame on that page and the right frame on that page. Now, still with the Move tool, click on the "link node" on the lower part of the right edge of the rightmost frame on the left page, which will shade this frame blue. Move the mouse pointer over the text frame on the right page (it will become shaded blue), and then click in that frame to create a link between the right frame on the left page and the only frame on the right page. Press the "Command" key on the keyboard, and Publisher will immediately close down, with no notification. I hope this helps. If not, please let me know, and I'll make a screen recording. Thanks, Ken

Hi, I'm experiencing a repeatable Publisher crash when pressing the Mac "Command" key after setting up links between text frames. I've attached a Publisher file that can reproduce (for me, anyway) the crash. The following are steps to reproduce the crash: Click in the rightmost text frame on Page 1 to select it. Click on the "node" on the right edge of the selected text frame to highlight the frame and enter the mode for text frame linking Move the mouse pointer to the leftmost text frame of Page 2, which will highlight it. Click in the leftmost text frame of Page 2, which will create a link between the rightmost frame on Page 1 and the leftmost frame of Page 2. Press the "Command" key on the Mac keyboard, which will crash Publisher with no warning. I'm running Publisher 2.04 on macOS Ventura 13.3. A copy of the crash log is also attached. Since I encountered this issue while doing production work, I'm now going to look for a workaround. I'll post any successful workarounds here as I find them. Thanks, Ken AddingColumnLinksCrash_14May23.afpub AddingColumnLinksCrashLog_14May23

I'm using Affinity Publisher 2 Version 2.0.4, and the handling of BADFINGER seems to work fine for me. Using the "Nederlands" dictionary, I created a new document consisting of the text of your post here about "BADFINGER". Running Preflight, "BADFINGER" was flagged as a "Spelling Mistake", but when I right-clicked on that word in the document and selected "Ignore Spelling", the "misspelling" actually was ignored upon subsequent loads of the document. Your report of Publisher "forgetting" all of the "Ignore Spelling" indications that had been specified in a previous instance of the document is exactly what I had been experiencing when I first made this post over two years ago, but I don't recall experiencing this issue in the past few months. Ken

HI, I'm working on a 40-page magazine file in Publisher. Page 2 contains a thumbnail of the front cover, so to generate the thumbnail, I set focus to the cover page and then use the "Export" operation with the "Current Page" option to export the front cover as a TIFF file. This works fine. However, when it's time to export the entire document to a PDF, when I select the "Export" function, the export file type is "TIFF", as I would expect, since this was the file type specified in the previous export. However, when I use the dropdown to change the file type from "TIFF" to "PDF", the preview display on the left half of the "Export" dialog displays "Generating Preview" (which is expected), but what isn't expected is that every spread in the document opens in the MacOS "Preview" app (I'm using a Mac). At best, this is unexpected, and at worst, this is a bug. At the moment, I'm up against a deadline, so I don't have time now to generate a small test file, but for the file I'm working on now, I can get the spreads (or at least some of them) to open in the "Preview" app by doing the following: With a Publisher file open (the length may matter; my file is a 40-page document which is 21 spreads), select "Export". In the file type dropdown, select "TIFF" While the preview image is loading, select "PDF" from the file type dropdown. This should cause at least one spread to open in the MacOS "Preview" app in addition to the image appearing in the left-side preview pane of the "Export" dialog. If this cannot be reproduced, please post back, and I'll try to create a sample file that exhibits this behavior. Thanks, Ken

Hi lacerto, Thanks for the input. I did some more testing, and discovered that the main reason that I wasn't seeing the dot leaders is that the tab stop that I specified for the dot leaders was to the left of the position where the tab character was located on the line. What's odd about this is that if this is the reason why I didn't see the dot leaders, is that I *did* see the underline and strikethrough leaders, so it seems as if there might be some inconsistency between the different leader types. Another problem that seems to remain is that I can't get the dot leaders to work in cases where I've specified a non-zero "Left Indent" paragraph value along with a zero "First Line Indent", which would indent all lines (generated by wrapping) following the first line to be left-aligned to the tab stop of the first line. I've attached a sample project that illustrates this problem, and the workaround that I'm currently using. Am I doing something wrong in "Test #2" here? Thanks, Ken TabLeadersInTableCells.afpub

Hi, I'm trying to create a tab with dot leaders for a paragraph inside of a table cell, and I can't seem to get any character leader to appear. I can generate underline or strikeout leaders fine, though. I was able to reproduce this easily in a new document: Create document Add a table Type text in one of the table cells, then a tab, then more text Go into the Tab Stops settings in the Paragraph settings and set a tab stop Select the "Tab stop leader character" option for that tab stop, and there's no change Am I doing something wrong here, or is this broken? I'm using the latest version of Publisher 2. Thanks, Ken

I see what's happening here. You're probably correct regarding the 72 dpi threshold, but that's probably the default value. Preflight allows you to create custom profiles (click on the three horizontal lines to the right of the profile name), and you can customize the settings. I just noticed that I'm using a custom profile, and it appears that in the past, I've tweaked the DPI threshold for generating a Preflight error to be 300 DPI (see attached). Ken

FYI, here's how I initially lay out my document and manage the Preflight DPI errors in the documents I create. As I stated in another reply here, I'm assembling a magazine that contains a series of articles, written by different authors. Most articles contain images that are submitted to me having widely differing pixel densities and intial dimensions: I arrange the document elements (article text and accompanying images) so as to produce a pleasing layout and also to fill each page. I usually resize images in order to adjust the flow of the accompanying text so the text nicely fills the space not used by the images. When I'm done with the layout, I check Preflight to see if there are any DPI errors. There are usually quite a few (for the document I'm working on now, I have 69 "Placed image DPI too low" errors). If I have DPI errors, I open the Resource Manager window and sort the list of images by DPI, from low to high. One-by-one, I open the images with a too-low DPI in Photo, go to Document | Resize Document, make sure that the horizontal and vertical dimensions are linked to each other and that "Resample" is checked, and in either of the "Size" values, after the numeric pixel size, I append "*[desired DPI]/[current DPI], and then click "Resize". For example, one of my images in Publisher has a DPI of 80, and Preflight is flagging it. When I open the image in Photo, and select "Resize Document", I see that its dimensions are "261 px" and "296 px". I change the "261 px" to "261*(300/80) px", and hit "Enter", which changes the image's pixel dimensions to "987.8 px" and "1110 px". I then click "Resize" and then export the resized image over the original lower-resolution version. I then check that image's status in the Resource Manager, and see that its status is "Modified". I select that image in the Resource Manager and click the "Update" button at the bottom of the Resource Manager window. After the update, that same image now reports a DPI of 301, and its associated Preflight error has disappeared. This works well for me, though it is a bit tedious. For a document requirement of 300 DPI, I usually use "325" instead of "300" when doing the image resizing, to allow for a bit of "wiggle room" should I need to adjust the image size in Publisher, and also to avoid negative round-offs during the document resizing process (using "300", I sometimes end up with Preflight errors reporting that the image I just resized is being flagged as having a "too-low" value of 299 DPI). It would seem to me that the only approach to automate what I'm doing manually would be if a script or macro could be run from Publisher, possibly using the Photo persona interface to do the resizing. What would be ideal would be if the other image resizing parameters could be specified in a profile, which would allow for the user to specify a default resampling method and destination for the resized file. If this were supported, then it should be possible to offer a "Fix" button to the right of each of the "low DPI" Preflight errors, which would make fixing these very efficient! Ken

I believe that the Preflight "error" regarding low DPI isn't hardcoded to 72 DPI, but instead seems to be triggered if an image DPI is less than the DPI that's specified in the "DPI" value in the "Document" tab of the "Document Setup" window. I have my document DPI set to 300 DPI, and Preflight is showing "low DPI" errors for every image that has an effective DPI of less than 300. Ken

Yes, changing the DPI of the images so it's larger than the required amount would in fact work, but it will probably result in most of the images having an effective DPI that's very much in excess of the 300 DPI that my document will be generated with. In my case, there are two issues that make the pixel resolution a bit more difficult than for some other document creators: The images that are presented to me are created from many different sources, and from different contributors. Some images arrive to me at 300 - 400 DPI (photos from original sources), and others may be as low as 75 - 100 DPI (images downloaded from websites), so I'm not starting with images that have a consistent pixel density In order to achieve pleasing page layouts, I'll often resize images to either make a set of images all the same size, or to control the amount of space on a page that's available for the accompanying text. If there's a bit of empty space at the end of an article's text, I can usually fill this by enlarging of of the accompanying images slightly. The only reliable way to set the DPI of all images used in my document high enough so Preflight won't issue low-DPI warnings would be to set the pixel density of all images high enough so the density would be 300 DPI if the image were a full-page in size. Ken

Hi Walt, Thanks for this, but I have a feeling that they aren't going to work in my case. When I place images into my Publisher document, I often resize them in Publisher, which causes their pixel density to change. I can see how macros can work completely in Photo, but I can't see how the macros would be able to "know" what the size of the images are in my Publisher document, which I believe is necessary to perform the calculations needed to arrive at a particular dpi value within the Publisher document. Or is there a way that this can be done. Ken