MikeA
-
Posts
217 -
Joined
-
Last visited
Everything posted by MikeA
-
I'm jealous that you can attach screen shots to your messages. It still doesn't work for me in this forum. I've written again to Serif asking when it might be fixed. The rules around the pixel objects surely don't work for me. And I ran across something else unexpected (it might be working as designed, but *I* didn't expect it). I was talking about this tiny project with someone in another forum. I told him: the goal is to take two pasted objects (something that was too large to get into a single screen shot), make them a single object, and draw a rule around the completed rectangular object. These two objects are (initially) Images and not Pixel objects. His suggestion: start by using geometry-merge. I checked Publisher's help file. Following those instructions, I selected the two objects in the Layers panel, then went to the Layers panel's menu looking for the Geometry sub-menu, as suggested in the help file. But there isn't any Geometry sub-menu in the Layers menu, at least on this machine. The help file suggests as an alternative: Select both image objects and right-click. That did turn up a Geometry context menu. Then, selecting any of the Geometry operations caused both images simply to disappear, leaving the bounding boxes transformed as expected. Almost the same thing happens if I first convert the two objects to picture frames, but in that case one image disappears and the other remains visible. Well—that's clearly not going to work. (Bug, or working as designed?) Selecting both and grouping them, then drawing a rule in the conventional fashion puts a rule around both of them, of course. So that won't work.
-
Affinity Publisher newbie here. After working in Publisher with an image that had changed from "image" to "pixel", I found I was no longer able to draw a thin rule around it in the way it can be done with a text frame or image frame. There's always the Outline layer effect, but it does the job only partway. With Outline there don't seem to be controls for how the corners are drawn—they are always rounded. But is there a way to alter the corners using some other controls in the program?
-
That's what I did after seeing a previous reply in the thread: repositioned the image (a group consisting of image+two text frames) by entering integer values into the Transform panel.
-
The document units setting is Pixels. Is that sufficient to determine if they are integer pixel values? If not, what additional settings should I adjust to find out?
-
I can't imagine wanting to add an adjustment to an image-less frame, but it's interesting to know that it can be done. A simple setup, perhaps: Establish some default settings at the beginning. Then, update them when need be.
-
Ok, well, that's what being a newbie will do for a person. I hadn't realized you can add a layer effect to the frame itself even without an image being present. Thanks.
-
W and H are integer values. X and Y are not. So I reset X and Y as integer values, then exported again. Same result—thin white rule.
-
The image frames on the master pages are empty. So presumably this had to be done during the first document setup by first populating the frames on the master pages, changing the images to greyscale, and then removing the images (leaving the frames intact). Serif Persons: is this procedure documented somewhere? I can't seem to find it in v.1.8.3's help file. I didn't make an extensive search for it. I entered "smart" as the search term and looked only at the smart-master-pages topic.
-
I placed an image into a Publisher document page and added text within the image area. After grouping all of the elements, with the group selected I exported to JPEG ("Selection with background"). The resulting JPEG file contained a thin white border that was not in the original file. Then I tried exporting using the "without background" setting. Same result. Then I tried it as a PNG ("selection with background"). Same result. Next I tried it as a PNG without background and finally the thing was exported without the thin white rule. This has happened several times when I've exported a selection to JPEG. (The quality setting is always 85 or higher.) So it doesn't appear to be some peculiarity of a particular image. I don't want to have to export first to PNG, then open the PNG file in some other program and re-save as JPEG. Is there some way to save from Publisher to JPEG without the unwanted rule around the image?
-
At approximately the 4-minute/20-second mark in the video, he drags a master onto a document page and all three images on the page immediately switch from color to monochrome. This is left unexplained. What are the setup steps required to achieve this effect? The brief entry in the help file does not appear to mention this, either.
-
The controls available within a frame are a bit easier to see on-screen — I mean, they're indicated pretty clearly. That weighs in their favor even if using them does increase the complexity of the document. I finally stopped using them in preparing the book of photographs when I realized the images were not looking better when surrounded by thin black rules — no need for a copy-able/paste-able frame with a consistent border size and color, then. But when a rule is called for... Fumbling around a bit with the cropping tool I found that adding a crop leaves the bounding box simply not displayed—then, adding a rule around the image leaves the rule invisible (it's outside the cropped area). Do I understand correctly that if I use the rasterize/crop feature I then completely removing the surrounded (cropped-out) portion of the image?
-
Interesting. Depending on my OCD level for the day, I'll think either that the differences are negligible or that they're very obvious. Then again 300% is a pretty extreme enlargement.
-
Thanks for the further information. If optimization could foul up the print job, I'll live without it. I just now uploaded the PDF to the on-demand book company and while it wasn't lightning-fast, it didn't give me fits. The export settings I used — PDF 1.4, downsampling on, JPEG compression=99 — produced a file just under the maximum allowed (300 MB). If I'd used the JPEG-mini files I could probably have added a few more images and used quality=100. But this is good enough for now. Well, assuming the book doesn't look like dog-meat-on-a-stick when they're done with it. : ) It's been a long haul learning Publisher from the ground up and acquainting myself with font-related tools I haven't had to think about for years. Thanks a lot for your advice along the way—it was extremely helpful.
-
I appreciate your taking the time to do all that. I made a note of most of the file sizes I obtained after doing some more of this (compatibility setting for all exports from Publisher: PDF 1.4): Files marked "[C]" were done with JPEG-Mini Pro compressed source files. Those marked "[F]" were not compressed via JPEG-Mini. The numbers within the filenames indicate compression level in Publisher export dialog. [F] 4/25/2020 19:36 387,526,265 Boise2018-NOCOMP.pdf [C] 4/25/2020 15:35 388,483,998 Boise2018_JPEG-NOcompr.pdf (unexpected result; export with uncompressed JPEGs is smaller, somehow) [F] 4/25/2020 19:39 244,546,273 Boise2018-Compr100.pdf [C] 4/25/2020 16:28 210,858,408 Boise2018_JPEGcompr-100.pdf [F] 4/25/2020 19:43 210,600,433 Boise2018-Compr99.pdf [C] 4/25/2020 16:23 182,725,987 Boise2018_JPEGcompr-99.pdf [F] 4/25/2020 19:46 173,309,855 Boise2018-Compr98.pdf With source files compressed with JPEG-Mini and a PDF compression setting of 90, the PDF's size dropped to ~83 MB. Switching for a couple of tests to PDF/X-1a:2003 produced crazy-large files and I gave up on that idea quick-like. In another discussion about this, someone mentioned using Acrobat to optimize his PDFs' sizes. That's an expensive solution for someone like me who isn't in the trade. Perhaps there's other software specialized for that purpose and without all of Acrobat's bells and whistles. Then again those kinds of tools might produce optimized files that aren't suitable for press.
-
In making a book of photographs to be printed by a print-on-demand company, I found I'd exceeded their 300 MB per PDF limit even before I had all image files placed in the Publisher document. The idea of further JPEG compression was not appealing but I decided (holding my nose the entire time) to try compression settings during export to PDF. The results surprised me. No compression: 388.5 MB No compression (2nd time around): 363.4 MB (why the difference?) Compression setting 100: 211 MB Compression setting 99: 182.7 MB Compression setting 97: 139 MB Compression setting 95: 114 MB Compression setting 90: 83 MB I take it this means that the max quality setting (100) still involves re-compression of the images. All along I'd thought 100 means: no compression. Apparently not. So if output file sizes are plaguing you, perhaps the slight JPEG compression will be helpful. Before starting the tests I ran the original JPEGs through the compression program JPEG-Mini. It made a whopping difference in the files' sizes and without noticeable loss of quality. But using the JPEGs compressed with JPEG-Mini as source files within the Publisher document doesn't seem to have provided a lot of savings during export to PDF. Perhaps JPEG-Mini's major advantage is a "web thing" and not a "print thing".
-
I'm putting together a small book of photographs and as a newcomer to Publisher I'm not sure what are considered best practices for working with images. I can give an image a border (a thin rule) whether or not it's in a frame. Then again, I can't seem to assign a style via the Styles palette (specifying a particular rule width and color) to images lacking frames. Using the Styles palette is pretty quick and the results are predictable. I could be missing something here. There might be situations I haven't encountered in which not having a frame would cause problems in the future. What might they be? On the other hand, is using an image frame simply overkill a lot of the time? (If I want to lock the image "in the raw," that's one command within the Layers palette. But if it has a frame, I have to lock the frame and image separately ... somewhat irritating that there's no option to lock both at once as it doesn't seem possible to select both at the same time...or, is it?)
-
I'm going to try pasting in a screen shot of what I see. Haven't been able to do that in the forum but I'll try again... nope. It failed yet again. That's getting really tiresome. Ok, I'll upload the screen shot to Google Drive. https://drive.google.com/open?id=14sR5KIneuQcA_McwKzfjU08WeF-IPOHN [Edit: Now I see... the dialog you displayed is what appears when you open the document when items are missing. The alerts I displayed are the ones that appear the moment the files go missing. Then, it sounds as if the workaround (such as it is) will be to save the document with the error uncorrected, close it, re-open it, and try to automate relocating the missing items that way—which does work as you noted. Thanks.]
-
The only sort of notification—a small popup window—I've seen so far contains only a Resource Manager button. No Yes button in sight. If you're using the Mac version, perhaps its way of handling this differs from how the Windows version handles it.
-
I could certainly have closed it without saving. But I wasn't entirely certain what had just happened and I wanted to be damsure the thing got back into its original condition, quick-like. I'd submit that one among several possible reasons for archiving is simply to collect files in a single location (without necessarily having to link them to that location). Well, I'll find other ways to do this in the future. Yes, a single click to re-link to all files in a given folder would be well worth having.
-
I did a first-time test of the make-collection feature and got quite the surprise. I made a temporary directory of the hard drive. With a small Publisher document open, I selected Document > Resource Manager, selected all image files shown there, and clicked Collect. For the destination I selected the temporary directory and then the collection was made. After checking to ensure that all files appeared in the temporary Collect directory, I removed it. At that moment Publisher announced a loss of linkage to all of the image files in the document. It appears the program had just re-linked all images to the versions that were copied to the Collect subdirectory. (Had I missed an option that specifies: only copy them — don't re-link them?) Then I had to re-link all of them manually to their original location. I'm glad it's a small document. If I had to do that in the document once it's finished, I'd be at it all day as there does not appear to be a way of doing it in a batch (which would make sense if the missing image files were all in the same directory—which, in this case, they were). Restoring the links seems to be a one-file-at-a-time operation. As far as I can tell, Publisher's online help file (the topic on making a collection from the Resource Manager) does not mention the change of linkage in this situation. Is the feature working as designed? The "gotcha" of suddenly changed linkages could be a nasty surprise indeed for the unwary with a large document containing image files residing, originally, in multiple locations.
-
Thanks, @GarryP and @h_d. I made what I expect is a classic newbie error. That toolbar was not showing and the alignment options weren't visible. Not sure when I hid that toolbar, but it wasn't in plain sight. Certain UI features seem to vanish on their own initiative sometimes, when I go in and out of preview mode. Maybe this was one of them. Or maybe it was just a newbie error. You're right — I think the two-centerings-in-one-command-please is worth a feature request.
-
1. Is there a single Publisher command that is the equivalent of executing both Align:Middle and Align:Center via a single command? 2. On a double-page spread, Align:Center puts an object in the precise center of the spread. Is there an alignment command that quickly centers an object within the page where it is located, rather than the current spread?
-
Today I received the small test books from MagCloud. Overall impression: not bad, not bad at all for the price. (MagCloud uses a dull-coated stock that doesn't seem to be the best possible—at those prices, how could it be?—but it could be worse.) I followed all prior advice about the PDF version (1.4) for both test books. One was in CMYK color space and the other in RGB—in both cases, with profiles embedded. I expected the RGB document to print with the colors seriously "off". To my surprise, they weren't. Deep shadow areas in images were lighter than in the CMYK version, but to my surprise the RGB document printed with better saturation in yellows. Blues — no appreciable difference that I can see so far. Skin tones look about the same in both versions (slightly too magenta for my taste; time to re-profile the monitor, I guess). But that slight boost in yellow did catch my eye. Large expanses of dark grey are noticeably lighter in the RGB version — and very slightly yellowish. The oddest result was that apparent sharpness (of fine details in images) seems slightly higher in the RGB version. This kind of thing usually requires "pixel-peeping" viewing distances to detect, but I noticed it almost unconsciously...then, pixel-peeping distances confirmed it. I am guessing the effect might be only some "artifact" of a particular press run, but I don't know yet. It has been an interesting experiment. One thing I know now: If you're going to print a book on MagCloud, give it at least 24 pages so that you can select "perfect" binding. The web site notes that the alternative for shorter books is saddle-stitching. But these test books were so short that I guess they were stuck with using staples — and the stapled binding is just no fun at all.
-
Thanks as always. When I have nailed down this Publisher-to-MagCloud routine (two sample books will be arriving in a few days) I plan to write up the procedures I followed. If you'll permit, I'd like to include a couple of quotations from your posts about this.
-
And speaking of that — to return for a moment to the matter of how to specify black for press work like this... MagCloud's recommendations are much the same as yours. Don't set all CMYK values to 100, for starters. For black text, they recommend 0C 0M 0Y 100K. I thought I'd see what would happen if text is set to RGB=0,0,0 and then the CMYK sliders are examined afterward. (This test document is in CMYK color space.) So, set text color to RGB=0,0,0. The CMYK sliders now display 74C 68M 67Y 90K. Not much like 0C 0M 0Y 100K. But is that so far off as to be ill-advised for some reason? Knowing as little as I do about preparing documents for 4-color printing, I don't want to make possibly bad assumptions. Then I give the type some random color, then reset the CMYK sliders to 74C 68M 67Y 90K. I again have what appears on-screen to be black type. Switching to the RGB sliders, I now see 2,2,3 — not exactly 0,0,0 as before, but close. (Close enough?)