MikeA
-
Posts
217 -
Joined
-
Last visited
Everything posted by MikeA
-
By now I've learned enough about Affinity Publisher that I'm ready to create a small book of photographs to be printed by an online book service that uses a four-color process. I have just noticed something in creating a template, which I first set up in CMYK color space using the default color profile for CMYK: In Publisher's dialog shown via File > Document Setup, there an option to select "Assign" or "Convert." However, the option to select Assign, versus Convert, does not appear in the dialog displayed via File > New. Thus the option appears only after you've created the document. I assume these terms have the same meaning here as they do within a program like Photoshop—what should the program do color-space-wise when an image is opened or placed? Is this option's absence from File > New intentional? If so why would that be? Whichever option is selected—Assign versus Convert—what is the effect when placing images exported from a RAW editor in, say, sRGB or Adobe RGB once they are imported into the document? There doesn't seem to be any "leave in native color space" option—it's assign or convert. The purpose of selecting CMYK is that the book company requests that text be in CMYK color space. This is presumably to avoid "full" black which can cause problems on the press. But now I am wondering if this kind of document should be in an RGB color space throughout its creation, and then converted to CMYK on export to PDF—with Publisher instructed to leave images in their native color space at that time. Advice much appreciated.
-
Ah, the Finish button. I'm at no risk of anyone's accusing me of being observant — I keep not seeing that button and must have clicked away to go to some other page (at which point the 'detachment' is switched off, of course).
-
Glad you could confirm it—thanks. And thanks for the reminder about 'edit detached.' Yes, that does enable easy deselection of the text frame. >> the software thinks there's nothing to deselect. Makes sense—except that when you click within the locked text frame, its contents are still editable. So to that extent it is selected. I first thought that to restore 'un-detached,' you should right-click the master page entry in question (in the Layers palette) and select 'edit linked'. That doesn't 'lock' the text frame, however. I've tried all of the items in that part of the context menu, but none seems to undo the 'edit detached' command. Perhaps it can't be done there? I did restore the "complete" connection to the master page when I clicked the page's thumbnail image (in the "Pages" panel) and re-attached its master page there. At that point the text frame in question became locked again and once again Control+D (etc.) stopped working.
-
As I'm learning Affinity Publisher I'm getting accustomed to one of two ways to deselect an object: press Control+D, or press the Esc key twice. I can also click with a tool outside, say, a selected text frame—but I prefer to use the keyboard when I can. I've run into a situation where neither method works. Start with: facing master pages that will be the masters for a book. Each contains a text frame. On the document pages created from the master pages: Once I've selected these boxes with the text-frame tool, I can no longer de-select a text frame by pressing Control+D or by pressing the Esc key twice. And in the Select menu, the "Deselect" menu item is inaccessible ("greyed out"). But if I draw another object onto the page—say, a text frame (that is, a frame that isn't derived from a master page), then pressing Control+D and pressing Esc twice both work, and Deselect is accessible again in the Select menu. Is that working as designed?
-
I've put together a small Publisher document that displays the problem and will add it to a new message in the Bugs forum. If the can't-attach-a-file-to-a-post problem is still with us, I'll put it on Google Drive and add a link to it. If all else fails I can email it to Serif. In that post I'll link to this one, for reference. (edit) Wow ... this forum software is becoming quite the challenge. I started that new message, inserted a link into it — and the entire message simply disappeared. Maybe I'll have to send this in email to Serif after all.
-
Later today I can try this: I'll remove everything from the document except the page on which the problem occurred, and see if it happens again there. As I'm still unable to upload anything to the forum — I sure hope they can fix that — I'll have to upload it to Google Drive and then post a link. I'd hoped it was just a one-off problem that would be fixed when I closed and re-opened Publisher. After I'd been working in the "problem-child" document for a while, I noticed Publisher becoming sluggish, and odd things happened. For example, I drew out a new text frame with the Frame Text tool, placed the insertion point in it, and ... no insertion point. I began typing and the screen jumped as if I'd scared it to death. When I zoomed back in on the text frame, it contained nothing. I closed and re-opened Publisher, and at least that stopped happening. Wonder how I'd solve the floating-image problem if it were to surface suddenly in a long document being used for a real-world job. Thanks.
-
I'm glad to have found this thread. I've been trying to do this as well. When I select (with the Move tool) an image that isn't yet linked to anything, then click Float with Text, the image shifts position to an unexpected place on the page and is then linked to the text. But right away the image's frame is now locked ("x" characters instead of resizing handles). The image itself is unlocked. If this is done with an image placed onto the page without a frame, then the image becomes locked when I click Float with Text. That aside, in the Layers palette the lock symbol does not appear for the image or its frame. Toggling locking on and off again has no effect. So for now, the frame+image cannot be moved into the right position. Moving the "Float" line connecting the image to the text moves the image around on the page, but still it can't be moved to the correct position. When I'm attempting to drag it, I see a small label appearing over the top of the image. It reads "0 objects." I thought clicking the Float with Text control might toggle the setting off and then I'd have control over the frame or image (or both) again. It does toggle the setting — but the "unlinking" immediately turns the image into something unrecognizable. In the Layers palette, it has become extremely thin and very, very stretched in the vertical dimension. It disappears from view on the document page. I can at least delete it via the Layers panel. Clearly I'm doing some things wrong here. How to 1) set up this "float" with the image remaining movable; and 2) unlink the image if need be and have it remain intact? Thanks. [Edit ... it's some setting in that particular Publisher document. I tried it in a brand-new document and neither problem described above occurred. In the other document, it occurs on all pages. What might I have done wrong in the document that has the problems? Is it possibly corrupted, somehow?
-
I followed your procedure to the letter. Yes, I'm sure.
-
I didn't note the exact thread — it came up in a search here — but it was kind of an old one. Having been through that confusion, I daresay you're right about its source. :- )
-
I found only a little bit of information about regular expressions in the online help. It appears that Publisher supports Perl-style REs. They don't cover the topic extensively (of course that'd be an entire book unto itself. You're right: both ".*" and ".+" would work for what you're doing in the video.
-
@R C-R How interesting. Thanks for posting the screen shot. I'm going to see if the forum will let me post one of my own ... [a moment later: nope. The forum bug persists. Cannot attach screen shot. <grumble>] I followed your procedure exactly and then on opening a new document and editing style "Base": Where you see: Edit Text Style ("Base") > Character > Position & Transform > Leading Override : Auto I see: Edit Text Style ("Base") > Character > Position & Transform > Leading Override : 0 pt. I'm using Windows version 1.8.2. Are you using the Windows or Mac version? Judging by something I learned a few days ago, the Mac and Windows versions do not handle certain text style operations the same.* ________ * I saw a video in which a Mac user of Publisher manually formatted some "[No style]" text, then immediately opened the context menu for style "Body" and updated it—and then attached the updated style to the text she had just formatted manually. In the Windows version, to do that I would first have to assign the style to the text, then format the text manually. Only after that does the "Update [name of style]" option become available in the style's context menu.
-
>> The Character panel Leading Override automatically defaults to the Paragraph Leading, Mike. I don't see why setting it to Auto would be needed. What I'm saying is that I've observed the leading override value not always defaulting to the paragraph leading setting. As a result I ended up with bizarre, irrational-seeming line height settings... finally hacking around in the program for quite a while and trying different things revealed that the override setting, when it was "off," was causing the problems. Small wonder someone in another thread commented that he'd been banging his head against the wall with Publisher's leading settings and could not figure them out. I suspect he'd run up against this same problem and didn't know precisely what the problem was. Neither did I... (As I said in the other comment, using a setting of "auto leading [some multiple of the nominal point size]" is no way to typeset a book — notwithstanding the type designer's own specs for default leading. I've never worked on a book whose designer specified, say, "12 / some multiple of the nominal point size." Just Say No To 'Auto' Leading™.
-
I'm not finding the Leading Override setting consistently defaulting to "Auto." Example: I just re-opened a document I've been working on. I have not edited its Base style. When I right-click Base in the Text Styles panel and select Edit, then in the editing dialog click Position and Transform, I see that the Leading Override value is 0 pt., not Auto—not at all what I want. Next test ... I started a new document, selected Base in the text styles panel, then selected Edit Base. Once again the override value was shown as 0 pt. I changed it to Auto and saved the change. Then I selected Edit Base again. The value had returned to 0 pt. But I've already seen that in some circumstances a leading override of 0 point has a disastrous effect, so I'm not liking that "0 pt" as the default value. Next: Edit the style Body (derived from Base) and try to set its default override value to Auto. Same thing happens — it's back to 0 pt. when I edit it again. I'll skip the details about other things I tried. For the moment I'll try this approach and hope it does what I want. 1. Edit style "Base". 2. Set its point size to some familiar default such as 12 and its paragraph leading to an exact value rather than simply "1". (Auto leading is no way to typeset a book. Or anything else. IMO.) 3. In the edit style dialog, set the Leading Override value to "Auto" (and hope that when it reverts to displaying "0 pt." that's only some kind of bug in how the value is displayed.) 4. Select the Save Styles as Default option in the Text Styles panel and hope that it sets application-wide defaults (for all new documents). As most styles are derived from Base, hopefully this changes their Leading Override settings all to "Auto". This Leading Override "thing" (unlike baseline shift) is unknown territory to me and adds a variable I'd be happy to live without.
-
@BryceB Thanks for making that video. One thing I noticed in the discussion about regular expressions: unless Affinity Publisher's implementation of regexes is different from what I used in Perl, then: .* means not "one or more of any character" but "zero or more of any character." If you want "one or more," use: .+ If Affinity Publisher supports this, there's also: .? ... to mean "zero or one of the preceding character or expression (in this case: "any character"). Now of course I'm going to have to find out if it also supports greedy vs. non-greedy matches. How time will fly... It was interesting to see that you were able to use "$1" for the "captured" buffer. A comment I saw here a couple of days ago used "\1" instead. So then I thought: Affinity Publisher must require "\1" rather than "$1". Clearly it doesn't. In Perl, "\1" can be used in the replacement string but is more likely to be used within the search string — to refer to something captured to a buffer via parentheses — within the same search string. I was surprised you were able to use "Apply 'Body' to Paragraphs". I would have thought the command should be "Apply 'Body' to paragraphs and preserve character formatting" (or "...and preserve local formatting"). After reading that Publisher doesn't yet support style merging, I'm tempted to go about it this way: 1. Style everything precisely as needed in the word-processing program (I use the Softmaker Office editor called TextMaker, which writes .docx format). 2. Import the word-processor file — Publisher will create new styles named to match those of the incoming document. 3. Tell Publisher just to delete all unused styles in the document. Wonder if it'd work. :- )
-
Can Character > Leading Override be set to Auto as the default value for all styles — thus, applicable to every new document? Is that done by selecting Save Styles as Default in the Text Styles panel's "hamburger" menu? Or is there some other way to configure "application-wide" default settings for text formatting? If the former — maybe about 90% of the job gets done quickly by making a new document, editing style Base, selecting the "Auto" setting for Leading Override, and then immediately selecting Save Styles As Default.
-
>> Zero is not "no override". No override would be the value you see in the Character panel before you make any changes. For Arial, the Character panel will show a default of (if I remember correctly) "(12.4 pt)". Yes, I finally saw that 'zero' doesn't mean 'no override'. For now I'm assuming that selecting ’auto' for the Leading Override value is the right thing to do if you want to ensure that you're getting precisely the baseline-to-baseline height you specified in Paragraph > Leading. Once you select Character > Leading Override > Auto and confirm it by pressing Enter or Tab, the value shown in the Leading Override field immediately changes to the same value that you previously set in Paragraph > Leading. It wouldn't hurt for Serif to expand the documentation in that part of its online help file, explaining the behavior a bit better. They could, for example, include an example. :- )
- 17 replies
-
- 1
-
-
- leading
- leading override
- (and 4 more)
-
@walt.farrell >> You select the complete line. In that case you can increase or decrease the leading, which will adjust the baseline of the entire line. So when you set the leading to 0, the line moves up and overlays the prior line. I assume by "increase or decrease the leading" you mean "increase or decrease the leading override. In the situation I was referring to — a multi-line paragraph automatically line-wrapped within its text frame — selecting 0 or more character(s) and then changing Paragraph > Leading (as opposed to Character > Leading Override) affects the entire paragraph, not just the line containing the cursor and/or a few selected characters. The initial confusion is: to me "override" connotes a temporary condition. So NO override — a value of zero — would make sense as meaning "don't change anything." But in some circumstances "zero" has quite a dramatic effect. :- )
-
@GarryP Thanks for your reply. >> While Publisher allows you to apply a Leading Override to a set of characters I think it determines the actual Leading for the whole line of text by taking the largest setting that has been given to any of the characters in that line. I think this must be right. I have observed the "override" setting seeming to make its own decision about what it's supposed to be at times — leaving me wondering: exactly what leading did I set for a given paragraph? Not meaning just the nominal value, but what's the actual line height? So: If I have established a particular line height via the Leading field in the Paragraph tab, do I guarantee getting precisely (and only) that value, baseline-to-baseline, only if the entire paragraph's (or text style's) Leading Override setting is "Auto" initially? I don't want to leave this kind of thing to chance; I need to ensure a predictable result. >> If you want to shift a few characters up or down then you can use the Baseline Override setting just above the Leading Override. Yes, that makes more sense to me. It's clearly an attribute applied to specific characters and seems completely predictable.
-
Publisher is the first page-composition program (or word-processing "engine") in which I have encountered a Leading Override option. The program's online help notes: "The Leading Override setting can be used in cases where you have a handful of characters that need special handling, for example, because they use different fonts with sizes that look visually different." "Handful of characters" — and Leading Override's being in the Character palette, not the Paragraph palette — struck me as meaning it's an optional setting that can be applied to a few selected characters for special purposes. But that doesn't seem to be the case. If I have several lines of text that are wrapping within their text frame*; if I select just a few characters in one of the lines; if I enter "0" for the Leading Override — nothing happens. [ * Meaning: Publisher itself is doing the line-wrapping — these are not forced line breaks.] If I select a line by putting the cursor at the start and pressing End while holding down the Shift key, I select all text on the line excepting the final space at the position where Publisher wrapped the line. If I enter "0" for the Leading Override — nothing happens. If I extend the highlighting to the right by one more character (thus highlighting the space at which the automatic line-wrapping has occurred) and then enter "0" for the Leading Override — the entire line jumps upward to the point that the line is now superimposed directly on top of the preceding line. It's as if someone had entered a carriage return without a line feed. What is the logic or algorithm here? Why did that final space have to be selected? If Leading Override is not for baseline-shifting a few selected characters, then what is its purpose? What would be a typical use case? A related question: When you've established leading either via text style or via manual formatting, do you get the precise nominal value only if the Leading Override setting is "Auto"? If that is in fact the case, I'm wrong in thinking it's an optional setting. Entering the correct value in that field might be critical to ensure you're getting the exact line-height value you've set via the Leading field. Why would I think so? I noticed finally: When the Leading Override setting is "Auto," its value in the Character palette seems to become identical to — and to be updated in "real time" to remain identical to — the Leading value in the Paragraph palette. When "Auto" isn't used, the Override field's value seems to make its own decision about its current value. So it could possibly be causing incorrect line-height values without a user's realizing it.
-
I’ve been struggling with this feature myself today. I've used plenty of text "setting" system, ranging from photo-typesetting hardware to page composition programs. This is the first time I've encountered such a thing as "Leading Override" in software and have found it pretty confusing. I'm about to make a new post about it and hope that someone will be able to steer me in the right direction. It does work . . . but how it works seems very strange indeed.
-
Callum — thanks for your reply. I don't know how many times I've used this in word-processing programs — many, many times. I hope the company will consider it in the future. Perhaps it could be context-dependent, meaning: • If the selected object is a rectangle or text frame, or the like, Control+Shift+C copies its characteristics and Control+Shift+V pastes them to another such object. If a non-similar object were selected as the "destination," the paste-formatting command would have no effect. • If the selected object is highlighted text, Control+Shift+C copies its formatting and Control+Shift+V pastes its formatting to other selected text. If the selected "destination" item is not text itself, again the paste-formatting command would have no effect.
-
Maybe the commands I'm after are before my eyes and I'm just not seeing them... Programs like Microsoft Word have "copy and paste text formatting" commands. The commands store character formatting and you can later paste the formatting to other text. With some editors, if a paragraph marker was part of the original selection, you can even paste the copied paragraph formatting—not just character formatting. Something like that could be very useful in Publisher. But are there such commands for use within text frames and I've just missed them? I see a keyboard shortcut for "paste style" but it seems to apply only to objects, not text formatting.
-
Hmm. I might steal that. : -)
-
That's an interesting one — the offset pattern of the dots. The old CG phototypesetting equipment's insert-space/insert-character command would have lined them all up underneath each other. Memory Lane is fun, no question about it, but I worry about what those loaves of bread might look like by now.
-
That's a good tip, thanks. Now all I need to do is get it to work consistently. Could be just more user error, but I got that to work one time, then cleared the style out (as it were) and started over to ensure I could replicate the right steps. The setting didn't "take" all the time. I don't know why yet.