Jump to content

MikeA

Members
  • Content Count

    182
  • Joined

  • Last visited

About MikeA

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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".
  6. 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?)
  7. 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.]
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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?
  13. 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.
  14. 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.
  15. 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?)
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.