MikeA
-
Posts
217 -
Joined
-
Last visited
Everything posted by MikeA
-
I'll find out shortly how good a job I've done of it. They've already shipped the two test books (turnaround in less than 24 hours, not bad—though they are very small books to be sure). In editors like Photoshop I'm accustomed to "assign" making major changes, visible on-screen, and "convert" making no change (or at least a change so small that I can't detect it). I was a bit surprised to see the noticeable differences when I changed color spaces within the Publisher document. Despite "Convert" being selected by default in the document properties dialog, some kind of "assigning" seemed to have occurred.
-
Meaning Document Setup : Convert. I should have put it this way: Unless I'm misinterpreting the "Lightroom UI" look of the document setup dialog, "Convert" is selected by default as you create the new document—so I'll simply leave it as-is. I can understand that it's better to create the document using the preferred color space and profile. For these tests it would have meant starting from scratch in the second document and re-creating it page by page. It took quite a while to make that first test book. Copying the finished file to a new name and changing its color space+profile afterward saved a huge amount of time I'd otherwise have spent making the thing all over again. But I should look into whether it's possible to have two documents (say, one CMYK and one RGB) open at the same time and simply copy entire pages or spreads from the completed document into a new, empty one. Not something I've tried yet with Publisher.
-
Thanks as always for the time you put into these replies. After going back and forth here 'n' there about the output preset I finally decided on PDF 1.4 (Acrobat 5). I'd have to go back through some of the older threads here to remind myself why the one you're referring to in your reply above didn't seem as if it would work out as well. As I recall, MagCloud itself (per their instructions for InDesign) seems content with PDF 1.4. I did wonder if RGB/16 would be overkill. The resulting PDF was 6 MB larger than the CMYK version. The two documents' contents are identical. Fortunately the difference in upload time was negligible. But I'll select RGB/8 the next time. If the Document Setup : Convert setting does not immediately convert images, then I'll stick with it for now. In both the RGB and CMYK versions I left the Convert image spaces box unchecked during export. In retrospect I wonder if that was the wrong setting. Is one ahead of the game by allowing Publisher to do the RGB-to-CMYK conversion during export, or on the other hand keeping the box UN-checked and leaving to the book provider to complete the conversion? In any case if either or both test books look awful, I'll know it's back to the drawing-board. I've just had a look at one of the pages with a solid black background — in the RGB version. To get it I used, simply, RGB=0,0,0. Looking at the CMYK sliders, I see that same object as: 74C, 68M, 67Y, and 90K. So hopefully nothing that happens during export will force it to CMYK(all)=100.
-
It certainly wouldn't hurt if the sliders and/or data-entry fields could "glow" at least a wee bit when they receive the focus. Nothing radioactive-looking, of course.
-
MagCloud, a division of Blurb, does not have templates for Affinity Publisher or instructions re: the desirable PDF export settings in Publisher. So for now there's some guesswork involved. The first .afpub made for the test had as its native color space CMYK, with the default CMYK profile selected. The second was an exact copy but with the native color space changed to RGB/16 and the garden-variety sRGB profile selected. Both PDFs passed MagCloud's preflight checks. In both cases I left the PDF export dialog's "convert images" check-box UN-checked. All of it will end up CMYK when MagCloud prints the books. But it will be interesting to see differences between the two. When I changed the native color space there was a noticeable change in contrast between white text on a black background. The characters' edges seemed to distinctly sharper in the RGB version. Could it have been only a screen artifact? Certain colors of the photographs had a bit of saturation boost in the RGB version as well — at least on-screen. I'd be interested to hear from people with a lot of pre-press experience: Given the differences in document color spaces and profiles used, would you expect significant differences in the printed pieces? (I won't be seeing them for a couple of weeks yet.) Something I didn't change in creating the documents: the Assign (versus Convert) setting found in Document Setup. This is one place where a "Lightroom style" UI does the user no favor: It's hard to tell which of those two buttons is "pushed" by default. For now I assume black means selected. The tool tips for these controls read "Assign color profile" and "Convert color profile." Does "Convert" apply to every possible object in the document, including photographs that were previously exported in RGB from their original raw format?
-
Having them "light up" on getting the focus is a nice idea. I imagine it would be a lot of work for the developers to add such a feature at this point in the program's development. I decided to put a few often-used tools into a single floating panel and keep it collapsed most of the time (character, paragraph, text styles, text frame, and transform). It seemed like a pretty good strategy until, kind of at random, the panel has begun vanishing without having been explicitly closed. I bring it back with Control+T for character attributes, then must add the other tools manually with several trips to View > Tools. Kind of irritating. But it's so random — when I run across it, it's just after I launch the program — that I can't imagine writing up a repro scenario. Thus — not much use as a bug report.
-
If there were such a thing as a user option for...not to put too fine a point on it... "forever disable, ignore, shun, and rebuke-leading-override-in-the-name-of-all-that's-holy" I would gladly switch the feature off and leave it off. And yes, the possibility of making an accidental change to such a field via just the wrong spin of the mouse wheel at just the wrong time — it's just asking for trouble. Case in point: clearly I managed to change the leading override of that one space character without realizing I'd done it. So: my bad — and how easy it is to make such a mistake. The latest revision of the raw converter Capture One implements mouse-wheelies this way: Either Spin mouse wheel to move sliders, in which case: Use Alt+mouse-wheel-spin to scroll the tools panel. Or Spin mouse wheel to scroll the tools panel, in which case: Use Alt+mouse-wheel-spin to move sliders. (Or: click within a slider's numeric-entry field and spin the mouse wheel sans modifier key—just like the old days.) It took me a while to become accustomed to that; the old way was "mouse wheel spin = do all of the above" but I'm used to it now. More or less. At least it isn't as easy now to make inadvertent changes.
-
I'll be damned. I thought I'd checked for all that very carefully and it was, I guess, the one character whose leading override setting I didn't spot. Thanks for that. All the more reason for me to dislike — the longer time goes on, the more intensely — the leading-override feature. Too many cooks and all that. Well, I don't know. Maybe these days leading override is just all the rage in publishing software. I could happily live without it. Thanks.
- 14 replies
-
- 1
-
-
- fonts
- paragraphs
- (and 2 more)
-
I've put a .zip file (Odd-baseline-shift_Publisher1.8.3.zip) on Google drive, containing the .afpub where I saw the problem. https://drive.google.com/open?id=1RNUrWti5S04BucMYzdgFbQG8QQfxKt7M The .zip archive contains the .afpub file (Odd-baseline-shift.afpub). There's also a "readme-first.pdf" that explains the problem. The PDF file contains links to the necessary fonts on fonts.google.com. It's a peculiar business. The odd baseline shift occurs in just the one paragraph as far as I can tell. The PDF "readme" describes which paragraph to look for.
-
I could do that, as I did keep the document around for testing. Does Publisher have a way to bundle up the document plus the fonts it uses into either a single .zip file, or at least copy the whole business to a single directory? I would need to include the fonts. The .afpub file is fairly small. With the fonts included, the .zip archive wouldn't be so small.
-
("W.a.d." in subject-line stands for "working as designed".) Before I call this a bug I'll post about it here — see if there's some "w.a.d." behavior I'm just not aware of. The situation: a block of text entered in a font (from Google Fonts) called Cormorant Garamond Semibold. I decide to add a run-in subhead using a font named Mukta (also from Google Fonts). I decide later to move the run-in subhead to a different paragraph. So I highlight that text, and the spaceband (old typesetter term meaning a word space) that follows it, and press Control+X. Immediately the baselines of all lines in the paragraph shift upward by a couple of points. I press Control+Z to undo the change. The baselines return to where they were before. I re-select the inline subhead, but this time I don't include the spaceband that follows it. Again I cut the text with Control+X. This time the baseline does not shift upward. Next test: I select the run-in subhead and simply delete it, leaving the spaceband behind (it is now the first character in the paragraph). No baseline shift. Then I delete the spaceband. The baselines shift again. Later, after making a few point-size changes to the run-in subhead, I can't replicate the unexpected baseline-shift behavior. When it was happening, I checked the baseline offset value in the Character panel and it was the same for all text (it was the nominal point size value for the paragraph as a whole). Whatever the culprit might be, this kind of thing could play complete havoc with a publication's baseline grid and so: wotthehell might be going on here? Ring any bells?
-
Above, Garry P pointed that out to me. It does work, and I'm embarrassed to have missed it in the UI.
-
There are limits in File > New > My Presets, a feature I would love to see improved. If there is already a preset named "Custom" (from some previous session) and you click the "+" button at the top right of the dialog — let's say you want to make something entirely different — you get only an error message about a previously existing preset with the same name. You must rename the existing "Custom" preset, then click "+" again—after which "Custom" is again your only option at the start. Then you have to rename it yet again. Alternatives: Press "+". The error dialog appears and gives you these options: 1. Replace the existing preset. 2. Update/edit the existing preset. Better (IMO): Press "+". Dialog appears in which you enter the name of your desired new preset. If such a name exists now (ignore case, please): Queries: Replace existing? Edit existing? And: Select an existing preset from the graphical list in the main part of the dialog box. Right-click the preset. A context menu appears that includes: Rename preset... Delete preset NEW FUNCTIONALITY: Edit preset Generally the inability to edit an existing preset without having to create an entirely new one is somewhat frustrating and I hope you can consider changing this.
-
My recollection of Libre Office is that it did not play nicely on my machine, but I'll give it another look. One of the reasons I settled on SoftMaker's TextMaker program is that it does a bang-up job of exporting to PDF format. I tried several other MS Office "clones" — can't remember now what they all were — and their export-to-PDF features ranged from poor to middlin'.
-
Publisher displays incorrect preset name in File > Spread Setup. To replicate: First test Create a preset using the settings shown in screen shot "MagCloud-preset.jpg." In my tests I'm using these settings for a preset I've named "MagCloud 8 x 8 CMYK". Link to screen shot "MagCloud-preset.jpg" (forum won't allow me to embed screen shots in posts): https://drive.google.com/open?id=1sUCBBb30Bh-qaQPKOD0dkqT9U5YjKcXP With "MagCloud 8 x 8 CMYK" selected, now alter its color space and color profile. Change only those settings, to "RGB/8" and "sRGB," respectively. The name changes at the upper right of the New Document dialog to "Custom." Click the "+" button to create a preset by that name. Change the name of new preset "Custom" to "MagCloud 8 x 8 RGB". Create a document based on "MagCloud 8 x 8 RGB". Unexpected result occurs — repeatable: In the new document, File > Spread Setup shows the preset as "MagCloud 8 x 8 CMYK" even though preset "MagCloud 8 x 8 RGB" was used to create that document. Second test Close new document and run File > New. Select the "MagCloud 8 x 8 RGB" preset. Change the page size to 8.01 x 8.01. The name in the upper right of the dialog now changes to "Custom". Leave the name that way and click "Create." Expected result occurs — repeatable: In the new document, File > Spread Setup shows the preset as "Custom". Third test Close the new document and run File > New. Select the new "Custom" preset and change the page size back to 8 inches x 8 inches, exactly. The name in the upper right of the dialog remains "Custom". Leave the name that way and click "Create". Unexpected result occurs — repeatable: In the new document, File > Spread Setup now again shows the preset as "MagCloud 8 x 8 CMYK" — not "Custom". Fourth test Close new document and run File > New. Select "MagCloud 8 x 8 RGB" preset. Ensure the page size is still 8" x 8". Change the margin settings from 0.125 inch to 0.126 inch. Preset name in the dialog changes to "Custom". Create a new document based on "Custom". Expected result occurs: In File > Spread Setup the preset name is shown as "Custom". Fifth test Close the new document and run File > New. Select preset "Custom" and change its margin settings back to 0.125 inch. (Page size should still be 8" x 8".) Leave the name "Custom" as-is and click "Create." Unexpected result here — repeatable: In the new document, File > Spread Setup now again shows the preset as "MagCloud 8 x 8 CMYK" (not "Custom").
-
You're right about the margin changes enabling the correct preset to appear in Spread Setup. But what if the margin settings were already correct? You don't want to change them unnecessarily in the preset. But if you don't change them in the preset, you get the wrong name in Spread Setup. Worse: Let's say I make the new preset with the same (desired) margin settings as before but with the updated color space and color profile. Create a new document based on it. Now of course the preset name in Spread Setup is not correct. I decide: Just live with it; change it to the correct value in Spread Setup and click OK. Doesn't work. The next time I open Spread Setup, the previous (incorrect) name is back. I can't change it no matter how many times I try. How could this not be a bug? The other settings look correct in the document, the incorrect preset name aside. The data in the various drop-down menus and data-entry fields are correct. But are they? I can't really tell at this point, can I? (In a former life I was a software tester of sorts. And yes, it made me paranoid about this kind of thing.) So how about a clumsy workaround? 1. Start with the original "CMYK" profile. 2. Make a new one based on it. Alter the new preset's page size. Alter its margins. 3. Save the new one to a new name ("temp," we'll say) 4. Make a document based on "temp". 5. Close the new document and return to File > New Document. 6. Select "temp" and now reset the page size and margins to what they should be. 7. Give this second new preset the name you actually want. On creating a new document from this one, I find it STILL gets the old, incorrect ("CMYK") preset's name in Spread Setup. Why? I have no idea. For now I give up. Bug 1, Me 0. I just hope Serif will notice this thread.
-
I have a document preset (preset — not .aftemplate file) I named "Magcloud 8in square CMYK." Color space: CMYK with the default CMYK color profile. I decided also to make a version whose color space is RGB, with the usual-and-accustomed sRGB profile. In the New Document dialog I single-click "Magcloud 8in square CMYK." In the settings panel to the right I alter only the settings I need to change (color space and color profile). These changes cause the label "Magcloud 8in square CMYK" at the upper right to change to "Custom." I click the "+" button there and a new preset named "Custom" is created. I rename "Custom" to "Magcloud 8in square RGB." I close the dialog without creating a new file — thinking that closing it might be required for the new settings to "take" fully. Then I select File > New, select "Magcloud 8in square RGB", and click Create. When I view the new file's Spread Setup dialog, the Page Preset value is not "Magcloud 8in square RGB" as expected. Instead, it is "Magcloud 8in square CMYK." The document has the correct color-space and color-profile settings — but the wrong "based on preset" name. I can certainly select the correct preset name in the Spread Setup drop-down menu, but why should that be necessary? What procedure do I need to change to make the new document's info conform to the preset I first selected and not the one I didn't select? (Possible bug, or a feature I don't understand yet?)
-
So I've found with the .docx files created by the Word "clone" program I use. It has no "based on no style" approach, excepting "Normal," which seems to be based only on itself and apparently can't be based on anything else. It's a perfectly good program in its own right, but using it as a source for text to be placed in Publisher might become an exercise in frustration, styles-wise. If MS-Word still supports basing any style on "no style," then I might end up having to use it after all. Ugh. (When I worked at Microsoft — not recently — only the most die-hard "lifers" there liked what the Office team did with Word when they switched to a ribbon-bar-only UI, a disease for which there was no cure. For shame. Well, never mind...)
-
Also new to Affinity Publisher and it has taken quite a bit of testing to understand what's going on with the text styles. Not that I understand what's going on with the text styles yet. :- ) At least one comment indicated it might not be a good idea to start completely from scratch with the styles, but that was my first inclination. When something appears overly complicated: Can it be made simpler? So lately I've been seeing what would happen if I start by telling Publisher to delete ALL unused styles — before I've added any text to the document. If I'm creating new styles from scratch, then it's up to me alone to figure out the relationships among them. If I'm placing a .docx file into the Publisher file, starting from "zero" might give me a fighting chance — figuring out how Publisher interprets the incoming document's styles and their relationships (which adds a new variable to something that already has a lot of them to begin with). It might be that I'll prefer something like this for the workflow: • Create a set of basic styles that work for me. This will take a while. • Export them to a file. • On starting a new document that can use such styles: » Before adding any text, tell Publisher to remove ALL unused styles in the .afpub document. » Now import the previously-saved styles Maybe it'll be useful, maybe not. Haven't tried it yet. It might be very effective for formatting, say, computer documentation, which I always tend to format much the same. It won't likely be useful in "one-offs".
-
I made a text frame containing text similar to what's in your example and found that it worked just that way here as well. For this to work properly, the selection had to be porte-manteau when the check-box was afterward selected within the Character palette. That affected only the one word I'd highlighted. Making the lines break differently that way caused other occurrences of the incorrectly hyphenated word to appear. Fixing those caused other such problems to appear when the lines re-wrapped. If this is a one-word-at-a-time sort of "fix," I can imagine the complete fix for a long document requiring a very long time to complete. I see that manually adding a soft hyphen (Control+Shift+<hyphen> in the Windows version) immediately after the hyphen in "porte-manteau" also seems to accomplish the task. But still — manual labor. I see that it's possible to insert that character via Find/Replace — but considering how many possible such compound words there might be and with no way to automate a solution via scripting — egad, what a lot of extra work it could involve. I used to cope with such things in QuarkXPress (we were using XPress Tags) by running scripts on plain text before importing it into the program. The scripts would add all of the necessary special characters. It's very fast and relatively easy to correct if you make an error and have to re-run the scripts and re-import the text.
-
Glad to have run across this while only playing with test files.
-
If the purpose is only to keep words such as "co-operation" within the same line, then this "runs outside the text frame" behavior might be a bug. You're right that it isn't proper "span" behavior. I don't know what's the advantage of having the text go wandering outside the bounding box.
-
'No Break' documentation
MikeA replied to MikeA's topic in Feedback for Affinity Publisher V1 on Desktop
That certainly occurred (to an entire paragraph) when No Break was selected during style editing and when I applied the style in question to a paragraph. In a paragraph not having that style: When I placed the insertion point within it and clicked No Break in the Character palette, nothing changed. The setting did not have its apparent intended effect until I'd selected all text within the paragraph. (Working as designed?) -
Experimenting with this last night, I found that some sequence of parameter-setting managed to divorce a child style from its parent (group) style. Afterward, altering the group style did not update the child style. I assume this means: Once you've manually altered the child style, altering the parent will not make a change across-the-board within the child style unless you reset the particular setting to "no change." >> The only real and immediate advantage I have seen is that using Group styles means I cannot inadvertently apply a Group Style which could happen If I used Paragraph Style to base things on resulting in the 'wrong' style being applied. I do admit that it is quite a minor advantage. I'm not sure I'd consider it minor. There are so many things that can go haywire in a large project. Anything that reduces the possibility of an error—especially considering how complicated the style inter-relationships can be in Publisher—strikes me as worthwhile.