Jump to content


  • Content Count

  • Joined

  • Last visited

About garrettm30

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. I assume you copied the text box. Instead, try selecting the text inside the box, and paste it into a new box in Publisher.
  2. Hi, No matter what kind of composing engine each app uses, going from one app to a different app based on a different engine is fairly well guaranteed to result in reflow differences (except perhaps texts that are very short where the opportunities for reflow are at a minimum). I am one of several who eagerly desires some kind of multiline composer, such as the Adobe Paragraph Composer in InDesign and apparently the "Adobe Every Line Composer" in Photoshop (I have no experience with the latter—I only read about it in the documentation just now). However, whatever layout Adobe is doing automatically, it is quite possible for you to do manually. First, you mention leading, but that is interline spacing, a vertical spacing setting, so that is not the setting you need. Maybe you just mixed up terms, because I see you say, "If I play with leading to get everything on one line…" The setting you need is Tracking, which is the space between characters. You also want to notice the justification settings, including inter-word spacing. And finally, don't forget horizontal scale, if you use it in subtle amounts. Justification is inherently a game of compromise, but usually a subtle combination of tracking and horizontal scale will work. If you have some text that is set to your taste in Photoshop, I recommend you take a representative column and try to recreate the exact flow in Publisher. This is not something you would do every time in the future, but it is a useful exercise for learning how Publisher's text layout works. I did this a couple times myself, so that I could fine-tune my justification settings in Publisher and my understanding of what I need to do to get it the rest of the way. In this exercise, get a text frame of the exact size as in Photoshop, and take note of any difference that would affect available space for text, such as text-frame inset. Hyphenation would also make a big difference. Then paste the text from Photoshop to Publisher. Now your goal is to get the text to look just like Photoshop. Start with adjusting the justification of Publisher to come as close as possible to your settings in Photoshop (Note: I have not used Photoshop in years, and it was well before I had much understanding of typography, so I am really just speaking from my knowledge of InDesign). You won't be able to get it exactly the same with justification alone because of the different composition method and also because of the lack of glyph scaling as a justification setting that InDesign (and maybe Photoshop?) offers. Next, it is helpful to understand the difference of the composers. Most simple text composers like word processors (MS Word, etc.) use a simple line-by-line justification. It tries to fit as many words as possible on one line, and then when the next word will not fit, it evens out the spacing on the present line and moves on to the next line. Publisher is more advanced than simple word processors in its justification (for example, you should get better results with it as compared to MS Word), but this line-by-line limitation is still true of Publisher. So you end up with situations where Publisher was able to crowd many words into one line, but the next line may be overly gappy because that was the best it could do with that line. Software such as Adobe that offer multiline composers will try to strike a balance with multiple lines, so sometimes it will fit fewer words on one line if it means that a few lines down below comes out with better justification. Armed with that knowledge, you now know that Adobe may break a line sooner than Publisher for the sake of overall balance. So when you set up the justification settings in Publisher, you will want to get it so that Publisher never breaks before Adobe. Once you get justification settings as best as you can, then try to get each line to match the Adobe rendering, starting from the top line and working your way down. Don't do that with forced line breaks—depending your workflow preference, you might do that in production, but that negates the point of this exercise. Select the characters that would be a single line in Adobe, and carefully apply changes to tracking and horizontal scaling until it not only fits to a single line in Publisher, but inter-character and inter-word spacing looks basically the same. That's the basic idea. Of course you would not normally need to go to such extremes once you get in the habit of Publisher, but if you are getting better results in Photoshop than in Publisher, then this is a good way to study how Publisher works to achieve what you want. Then you will apply the principles you learned to get better results directly in Publisher in the future.
  3. Maybe not easy, but you could use Find/Replace to at least fix all of the text. Here is an example to deal with your situation: Open the Find and Replace Studio Make both the find and the replace text fields empty. What we want to do is find by text color: In the find format (the top right gear, first option), set the text fill color (in the "Color and Decorations" section) to match the wrong color. In the replace format (the second gear, but otherwise same process as in step 3), set it to the desired color. Click Find, and then Replace All. That will change all text in the document from the wrong color to the right color. By the way, I assume you did not use text styles when you set up this document, because otherwise, you could just edit the color of the text style rather than changing the text piece by piece or even find/replace. I can't think of any quick solution for other object types.
  4. @Chris Christner Thanks for uploading that file. There is a definite bug, and that file you shared will be useful for Serif at testing. What I can see is that the tool for aligning the columns is far out of alignment. With that file, hover over toward the edge of the fourth column until it gives the cursor in discussion. When you see that cursor, go ahead and click-drag horizontally. While you do that, watch the width of the first column. It resizes the first column. I am certain this is a bug, and I vaguely recall coming across something similar in another thread (maybe I even posed on it). Anyway, there is nothing wrong with the way you have set up the file, and it is not simply a tolerance issue as we first thought.
  5. Notice what kind of cursor it is. That is not the cursor for moving or resizing an object or text frame (which is what is shown in Thomoso's video). Rather, the cursor in Chris's screenshot and video is the one used when dragging out the width of the studio docks or when repositioning a horizontal guide. @Chris Christner Is it possible that there is a guide there that is misbehaving? This is just a guess, but maybe you have guides set to not show, and there is a guide in that position that is interfering when it shouldn't.
  6. I agree. PDF metadata is kind of hidden unless you know to go look for it, both when producing it and viewing it (depending on the software). So it is easy enough that a person might use Publisher for a long time before realizing this is happening. An empty field seems like a fair default.
  7. Clarification, in case it isn't clear already: the keep with next lines refers to keeping the end of the current paragraph with the first X lines of the following paragraph.
  8. That is most likely a printer setting. On my printer, I would need to set to the binding location to "short edge". The terminology of your printer will be different, but maybe that is a hint that will point you in the right direction. Here is a sample of where it might be. On another printer of mine, it is under "Printer Features."
  9. I tend to use the Text Styles studio when working with styles, but I am experimenting with using the contextual toolbar for applying styles in certain contexts when I wish to hide the side bars for extra space. In view of that, I am a little jarred by seeing what would appear to be a local override, when in fact it is not. Please consider this screenshot snippet from the contextual toolbar: When I see the plus after the paragraph style name (Block quote), I am led to believe that there is a local override in the selection of text, and indeed, it would be indicated in just that way if there were. But in fact, when I open up the Text Styles studio to confirm, I see only that the extra formatting was just the character style, but that is already indicated in the contextual toolbar. When I look at the the contextual toolbar, I read it as the Italic character style and the Block quote paragraph style with something else indicated by the plus. There is no something else. I suggest changing it so that there is no plus sign if the only additional formatting is a character style, since that is already indicated. That is my proposal, but I would like to hear what others have to say. Additionally, I think it would be nice to show the full listing of formatting as in the "Current Formatting" field at the top of the Text Styles studio. This would not be regularly displayed, as the contextual toolbar needs economy of space, but there should be some way to show it, whether by hover or by an additional menu item at the bottom of the dropdown such as "Show current formatting."
  10. Welcome to the forums. A Serif staff member may be able to help you some more, but just one obseravation about your OS. That may be it. Publisher officially supports 10.9 and later, but you can't be faulted for running it on an older system, because the Mac App Store lists compatibility as "OS X 10.7 or later." I point that out in case Serif needs to update the MAS system requirements, unless they really did mean it is compatible all the way back to Lion.
  11. Could you let us know whether the document you are working with started as a Publisher document or as an imported PDF, IDML, etc?
  12. Stepping away from software for a bit and thinking instead of the printed result, leading is neither a character nor a paragraph attribute, but a line attribute. Each printed line in a column of text could have different leading, but you could not normally have multiple leadings in a single line. However, when we get back to the software, we see text is conceived as being in a character->paragraph hierarchy; there is no separate line paradigm to which we could attach such "line attributes," nor would it be very helpful if we could, given that the delineation (ha!) of a line is not fixed because of the concept of reflow. So we can apply different leading to each character in the line if we wanted to, but in the end, that particular line will have only one actual leading. I point that out only to illustrate why it may be hard to settle on a definite way of thinking on this subject, because it doesn't fit the character->paragraph paradigm so neatly as other attributes. For my part, I tend to think of it primarily as a paragraph attribute with the option to "override" the paragraph default in specific (and even rare) cases.
  13. @Gabe I have tested further, and I found that the following spaces that are non-breaking in 1.8.3 are breaking in the 1.8.4 betas: thin space, hair space, sixth space, quarter space, third space, punctuation space, em space, and en space. As you mentioned InDesign and Microsoft Word, I likewise tested them. Indesign treats all of these as non-breaking the same as Publisher 1.8.3, while MS Word does the same except for em space and en space, which MS allows to break. Additionally, InDesign treats zero-width space as non-breaking, while MS Word along with Publisher in both beta and release treat it as breaking. I am inclined to agree with InDesign's behavior on that point, as otherwise I do not understand why both the zero-width space and the zero-width non-joiner exist if they are both breaking. To my fellow members for the amusement of general discussion, the history of these spaces has been troubled by the fact that the Unicode Consortium neglected to assign non-breaking quality to these characters, evidently in error. It has therefore put the Unicode standard at odds with the traditional usage of these characters, which surely contributes to the confusion such as the disparities among various software as I partially reported in the paragraph above. There has been recent proposal to fix the problem, but I do not know whether anything will ever come of it: http://www.unicode.org/L2/L2019/19115-fwsp-usability.pdf Whether or not Publisher should change to conform to current unicode rather than to tradition may be debated, but I would hope that Serif would not intentionally make a layout breaking decision in a double point update. Even if the user is aware of the change, simply swapping out thin space with U+202F is extra work beyond simple find and replace, because the widths are not equivalent and so reflow will happen. Such changes should be reserved to the bigger updates where layout changes are more often expected. For the record, I experimented with using U+202F instead of thin space several months ago, but I reverted my decision when I ran into some comparatively significant issue. Sadly I can't remember what it is, but in fonts and in browser space, U+202F has not been supported to the degree where it can be used with confidence. Layout programs have generally been more faithful in this regard, whether thin space or U+202F is used.
  14. The "thin space" is treated as a breaking character in the 1.8.4 betas, whereas it was previously a non-breaking character, such as in the 1.8.3 release. When I open the attached document in Publisher 1.8.3 release, this is what I see: But when I open the same document in beta, I see the question mark (last character in the frame) has been separated from the word it precedes: I have only noticed it today in beta 687, but I am sure it goes back to one of the earlier betas, because I have a printed document that was printed some weeks ago with an earlier beta. Edit: I should have noted that I am on an iMac with macOS 10.14.6. breakable_thinspace.afpub
  • 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.