Ken Hjulstrom

HI Walt, That worked perfectly! Thanks so much! I actually tried to move all of the content to a new document, but I tried to do it by selecting the pages from the original document in the "Pages" sidebar and trying dragging and then right-clicking on the selection to look for a "Copy" command, but neither were supported. I had seen the "Add Pages from File..." option, but I didn't explore it, thinking that it was intended only to import external non-Publisher content, such as Word or PDF documents, but using it to import an entire Publisher document into a new document worked file. One minor glitch I encountered, though it didn't affect the spellcheck of the new version is that after adding all of the existing document's pages into the new document, for the new document to be an exact copy, I had to delete the initial blank page, which is what the new document contained before I added the existing document's pages. Also, in my case, the new document started on the left side instead of the right, but this was easy to fix. Perhaps this was caused by the extra blank page in the new document at the start. As you suggested, I only used the new document for rerunning the spellcheck, which worked fine. Thanks again, Ken

Hi Walt, Since all I do is mark correct, but non-dictionary "words" as "Ignore spelling", it makes sense that these are held in the Publisher document somewhere, and if I could only figure out where, and "flush" them, and rerun the spellchecker, I'd be in fine shape. Curiously, my upgrade to 2.4.1 resulted in a "flush" of the "Ignored" words, which forced me to rerun the spellcheck, and probably mark the typo I noticed as "Ignore" by mistake. It's too bad I can't get Publisher to just "flush" these out again on command. Thanks, Ken

Hi Mike, I certainly agree with you that spellcheck on macOS is buggy. In fact, the main "bug" that I encounter is that sometimes Publisher will "forget" all of the "Ignore spelling" settings that I've indicated, which forces me to have to redo the entire spellcheck process, which for the document I'm working on now, about 160 "words", mostly foreign words or fragments of URLs. Following online advice, I attempted to view my macOS LocalDictionary, at ~/Library/Spelling, and it's empty, probably because I hardly tell Publisher to "Learn" any spellings. In my current case, I have a document that was pretty much all ready to be sent to the printer, but I found a final typo, caused by me, when I was attempting to use what I thought was a Publisher keystroke command, but "nothing appeared to be happening", when in fact, focus was on a text frame in my document, and my keystrokes overtyped what was originally there. The typo was easy to fix, but made me realize that there might be other occurrences of this sort of typo, which is why I want to redo the spellcheck on the entire document, since I wouldn't be spellchecking individual words that I wasn't sure were spelled correctly, but instead would be looking for random character typos that could be anything, anywhere in the document. I also considered exporting the Publisher document to a PDF and spellchecking the PDF, but my version of Acrobat (8.3.1) is too old to support document text spellchecking, and I don't seem to have any other tools that can spellcheck a PDF, and I'm not in a position to purchase a new version of Acrobat just to spellcheck one document. I'll probably just proofread the entire document manually, unless someone posts a Publisher-related solution here. Thanks, Ken

Hi Walt, In my case, I ended up using both a garish color and also white as the replacement, as both had their advantages. The garish color worked quite well at revealing the remaining black text, and white worked better, except I had to think for a few seconds when the white text revealed itself in areas where the document had black text on a gray background. The ideal method would have been to use a "format" of "invisible", but I wasn't able to find an option to accomplish this. Thanks, Ken

Hi, In a final visual check of my Publisher document, I noticed a new typo that's not a dictionary word that Preflight didn't catch, which makes me think that I may have mistakenly marked that text as "Ignore spelling" while resolving the spelling errors. Is there any way that I can "flush" my existing spellcheck input for this document so I can have Preflight do a fresh spellcheck using just its default dictionary so I can review the entire document again? Thanks, Ken

Hi walt.farrell, Thanks for the information and for the suggestion. I had just come back here to report that I had figured out that I could do something similar to what you had suggested, but instead of changing the character, to change the color to something garish (in my case, 100% magenta), to make any remaining "black" text stand out. Modifying your suggestion, I'll also try changing all "found" text to white, which should make it invisible. Thanks again, Ken

Hi, I'm the author of this query regarding a global text format change, in which I globally changed all text that was formatted as "pure black" (CMYK 0.0.0.100) to "rich black" (CMYK 60.40.40.100). One of the problems I faced before making the global change was to make sure that all of the text that I wanted to change was "pure black" to begin with, and I was able to do this by exporting my Publisher document as a press-ready PDF, opening that PDF in Acrobat, and viewing the pages with the black color channel turned off, as any visible text would indicate that it wasn't "pure text" to begin with. After sufficient iterations of modifying the text color in Publisher and viewing the exported PDF in Acrobat, I got all of the "black" text to be "pure black", after which the global format change worked well. Now my document is complete, and as a final check, I'd like to verify that all of the "black" text in the document is the "rich black" that I want. The easiest way to accomplish this, if possible, would be to run a "negated" format search, which would find all text that did NOT have the color (CMYK 60.40.40.100). Is this currently possible? I don't see any option to specify a "not" condition in the "find" settings. The only other options I can think of to accomplish this would be to search for (CMYK 60.40.40.100) and be on the lookout for text that isn't found, or to convert all of the text back to "pure black" and to do the global format conversion once again, both of which will be rather tedious. Thanks, Ken

HI lacerto, The document I'm working on isn't musical notation; it's a 40-page magazine containing about 60 images, about 80% of which are full color, and text, mostly black, and mostly sized between 9 point and 12 point. In the sample print, text as small as 8 point looked good, so I'm hoping that the shop knows their machines well enough that they are confident that the "rich black" color blend that they suggested will work. My editor lives nearby the new shop, so I'll see if they can do a sample print so my editor can verify the print quality before committing to the full run of 200 magazines. Thanks for your thoughts and suggestions, Ken

HI lacerto, I agree that this is a bit odd, but the print shop is on the other side of the U.S. from where I am, so I'm restricted to remote correspondence only, and I'm relying on the shop manager to provide me with the color profile and "rich black" values that he feels will work best with his equipment. It turns out that the new shop is capable of digital printing only, whereas the previous shop was using an offset printing process, where I was instructed to use K-only text to eliminate any loss of clarity due to minor registration differences between the different color plates. We did have the new shop do a couple of test prints, with the first one having some color tint issues as well as the black text (at that time K-only) wasn't as clear as the printing done by the previous shop. The second test print came out very nicely, with the shop making some "adjustments" on their side. The new shop recommended the 60.40.40.100 "rich black", and I'm assuming that this is one of the adjustments that they did in preparation for the second test print. FYI, we had no problem with the first shop, but it was located in the UK, and the staff in our organization who had been responsible for picking up the printed magazines, packaging them, and mailing them out are no longer available, so we're switching to a more locally-located shop. Thanks, Ken

Hi thomaso. Thanks for this. It worked great, and let me convert all of the document's text at once! I didn't realize that it was possible to search for practically any formatting that's supported. Ken

Hi, I currently have a Publisher document in which all of the black text is "pure black" (CMYK 0.0.0.100). We'll be switching to a new print shop, which recommends that "rich text" (CMYK 60.40.40.100) be used. Is there a straightforward way for me to convert all of the "pure black" text to "rich black", or at least for me to be able to search for any instances of "pure black" so I can verify that all of the black text has been changed? Pretty much all of the document text is styled, but there are certain places where I've made adjustments to small portions of text (color, size, emphasis, etc.), so I'm hesitant to change the text color in the style description, lest I lose the small bits of "custom" color. In the past, when I needed to confirm that all of the black text was "pure black", I'd open the exported PDF in Acrobat, and turn off the black channel in the "Output Preview", and scroll through the preview, verifying that none of the black text was visible. In my current situation, I could use the same approach to do the opposite, verifying that all black text *was* visible with the black channel turned off. What would be really nice would be if Publisher had an option to globally replace all text of a specified color to a different destination. I'm assuming that such an option doesn't exist, but any suggestions for how I can make this change relatively easily and without the risk of losing special text attributes would be appreciated. Thanks, Ken

Hi, I just downloaded the 2.4 update for Publisher, and I'm noticing that the context-sensitive cursor icons seem to have gone away. The particular ones that I've noticed problems with are the vertical bar, which should activate when the cursor is on the border between either sidebar and the main central display, the double-ended arrow cursor for using resizing handles, and the cursor for placing an image. In all of these cases, the cursor is still functional, but I have no visual indication that the cursor is positioned properly to initiate these actions. When I'm close to the area where I'd expect the cursor icon to change, I see the cursor "blink" a bit, which makes me think that perhaps the activation area is much smaller than it was previously, perhaps just a single pixel. I've restarted Publisher, and this problem remains. Thanks, Ken

I managed to resolve the spellcheck "errors" that appeared in the Preflight list by saving the document file after every second or third correction, so as to save changes that I had made in case Publisher crashed. As I worked my way through the flagged "errors", I noticed that the Publisher crashes seemed to only occur if I double-clicked on the Preflight entry to allow the repositioning of the document display so the word in question was visible in the display. I eventually just scrolled my way through the document, looking for the words underlined in red (the ones that the spellchecker flagged), and correcting them without double-clicking the Preflight entries went smoothly with (I believe) no crashes, which leads me to believe that the cause of the crashes may be related to the process by which the double-click on a Preflight spelling "error" positions the document to place the associated word into the document display window. Ken

Hi, I'm using Publisher 2.3.1, and I've just run into a reproducible crash that appears to be related to the spellcheck process. This crash initially occurred in a 40-page document file that uses the "English (United Kingdom)" spellcheck dictionary. When I opened the document tonight, I had fixed all of the Preflight spellcheck "errors" with the exception of three instances of the word "aluminum", which were flagged as not being spelled "aluminium", as I checked with my editor to determine which version of English (UK or US) was to be used. Informed that UK English would be used, I successfully changed the first instance of "aluminum", and Publisher crashed when I right-clicked on the second instance. Upon restart, Preflight now showed a large number of spellcheck "errors", which was consistent with Publisher having "forgotten" all of the words that weren't actually misspellings, but were just proper names that weren't in the spellcheck dictionary, forcing me to go through them all once more, and specifying "Ignore Spelling" for each of them. When I tried this, though, the first "Ignore Spelling" setting seemed to work, but the second caused Publisher to crash again. I managed to trim the file down to a very "bare bones" version (attached here) that still exhibits the crash error. Steps to reproduce are: Open the file. In the Preflight section of the left sidebar, click the "Check Now" button. This should reveal two spelling errors, "Davvidson" and "sales@zzvid.org". Double-click the "Davvidson" entry in Preflight, which will select it in the document. In the document, right-click the selected "Davvidson" and select "Ignore Spelling" from the dropdown. This appears to work correctly. Double-click the "sales@zzvid.org" entry in Preflight, which will select it in the document. In the document, right-click the selected "sales@zzvid.org", which will cause Publisher to immediately crash and exit, with no warning. I'm wondering if this might be caused by some sort of local corruption of the retained collection of "Ignore Spelling" words. If this is the case, then I'd expect that you won't be able to reproduce the error that I'm seeing, and if this is the case, I'd appreciate any suggestions as to how I can fix this on my end. If you are able to reproduce the error, then this would appear to be some sort of bug. Thanks, Ken PublisherSpellcheckCrash_v3_27Feb24.afpub

I came here because I ran into somewhat similar printing issues as what have been reported here, and here are my thoughts and comments: What I did learn from the other posters here is that using the "Selection" option of the "Range" requires that I make my selection by clicking the page labels in the preview pane of the Print dialog. This may seem intuitive, but I don't recall using the preview pane to make page selections in any other app that I've used, and I was going to the "Pages" display in the left sidebar and selecting the pages that I wanted to print from the "Pages" thumbnails, and then wondering why Publisher put up a message box stating that "No pages from the document were selected to be printed". Personally, I'd prefer an option to be able to print pages based on selections made in the "Pages" sidebar listing as an additional means of page selection, as it can often be more convenient to make complex selections there, especially for longer documents. The Print dialog "Range and Scale" dropdowns seem to influence each other in unexpected ways, such as in this scenario, using a four-page test document: Open the Print dialog and select "Entire Document" in the "Range" option. All four pages appear in the Preview pane, as expected. I click on each of the page labels so all four of them are selected. Then, I change the "Range" option from "Entire Document" to "Odd pages". The pages that are displayed in the Preview pane are now pages 1 and 3, both still selected, as expected. Now I change the "Range" option from "Odd pages" to "Selected". The Preview pane only shows two pages, both of which are blank, so I have no idea what those two pages are. I would have expected that the switch from "Odd pages" to "Selected" would have restored the complete list of document pages in the Preview pane, which I can accomplish by changing the "Range" option back to "Entire document", which will restore the entire list of pages in the Preview pane, and *then* selecting "Selected" again, which will present the full set of four pages to select from. Thanks, Ken AffinityPublisherPrintCurrentPageIssue_22Feb24.afpub

Hi, I have an interesting problem. I needed a shape in Publisher that wasn't available in the available shape collection available in Publisher, but does exist in OmniGraffle, so I created an OmniGraffle document, dragged in the shape from OmniGraffle's stencil collection, copied it, and then pasted it into my Publisher document. Surprisingly, it worked, but it was imported as a group of three objects ("Curves", "Curve", and "Object"). By experimentation, I found that only one of the objects allowed me to insert an image inside it in Publisher, so I deleted the other two unneeded objects. This is working fine, with the exception that when the shape is "right side up" in Publisher, its rotation property shows a 180 degree rotation. Visually, this doesn't pose a problem, but a side-effect of this is that when I set the shape's text wrap setting to "Jump", the effects of the "Distance from Text" values visually work the opposite from what one would expect (increasing "Top" would push text away from the visual "bottom" of the shape. As a workaround, I solved this problem by inverting the shape in OmniGraffle before pasting it into Publisher, but I'm curious as to whether there's a way to "reset" the rotation of a shape from within Publisher, so intuitive behavior of the "Distance from Text" would occur for a shape that's being used inverted from its typical orientation. Thanks, Ken RightSideUpShapeWith180DegreeRotation.afpub

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