Jump to content
You must now use your email address to sign in [click for more info] ×

Dave Harris

(Ex) Staff
  • Posts

    2,454
  • Joined

  • Last visited

Everything posted by Dave Harris

  1. Ah; the text tool is selected, but there's no blinking text caret. The right-click menu makes that clear. If it was the text menu, it would have text options like Character Traits, and it actually has general object options like Group. So there is a bug, which is that clicking with the text tool in a frame that is past the end of the story doesn't set the caret - it gets confused because there is no text in the frame. Once that has happened it proceeds as I described earlier. It doesn't involve sections. I can reproduce it with a simple document with 2 empty linked frames. Thanks for reporting it. I'll get this fixed.
  2. It seems to me you can get that layout by setting the main left indent to 75, the first line indent to 0, and in the Bullet section set the bullet Tabstop to 5. The drawback is that it doesn't update dynamically if something changes the position of the Indent to here character, but in this case you can change the left indent when you change the tabstop position.
  3. This is more or less by design. Generally, when you select a text frame with the Move tool rather than a Text tool, you are not working with a text selection. In this case when you paste, you replace all the text. This was designed mainly for the situation where you have some placeholder text that you want to replace. In Publisher people often design layouts filled with placeholder text, and then later want to replace the placeholder text with real text, and don't want to have to manually select all the text to do it. If you switch to one of the Text tools, so you have a blinking text caret, the new text will be pasted at the caret position as you want. I appreciate this has surprised you, and I will log it to be reviewed. Meanwhile, be reassured you have stumbled across a design choice, rather than a bug or Publisher being unreliable or non-functional or unstable.
  4. I'm sorry you've been having this problem. It is triggered by the interaction between the drop cap, text flow and the text wrap. I've attached an example file that demonstrates it. This is about the simplest document I could make. In your file the key text wrap was around the heading frame that flows into the main frame. We do have a fix for this internally, but it probably won't be included now until 1.8. In the meantime, a workaround for this type of layout is to resize the main text frame so it doesn't overlap the object that has the text wrap. 1.afpub
  5. It's a bug. In 1.7.1 if two text frames overlapped and both had wrap then they'd both wrap around each other. We tried to fix that in 1.7.2 by making the one on top win, but unfortunately the code triggers even if the one on top is not wrapping. This will be fixed in a future release.
  6. If you have both No break and a soft hyphen in a word, the soft hyphen wins and the word is broken. This is because No break can be applied as part of a style, so is more likely to be part of some general policy, where-as the soft hyphen has to be inserted into the specific word, so the user is more likely to have considered exactly what they want for this particular instance.
  7. The inconsistency is by design. It's because Publisher can edit them and Designer can't. At some point we'll probably give Designer the ability to edit them too, and then they'll be the same again. There is a bug in Designer 1.7.2 in that Convert to Text Frame ought to work like Convert to Text Path, but doesn't. It always preserves the stroke and fill which you then have no way to edit.You have to remember to clear them before doing the conversion.
  8. One way is to place a soft hyphen at the start of the word. If a word has soft hyphens anywhere in it, they will be used instead of the auto dictionary-based hyphenation, and if there is just one at the start of the word it prevents auto-hyphenation altogether for that word. Another way is to mark it as No break. This can be done from the Positioning and Transform section of the Character panel, or as a paragraph or character style. I think that's reasonable behaviour for auto-hyphens, but I agree it would be better if soft hyphens could be deleted like that. In fact, if you switch on Show Special Characters, it shows the soft hyphen as being moved to the start of the next line. I'll log this to be reviewed.
  9. It will be fixed in 1.8. This is the first font I've come across where it's actually an issue.
  10. InDesign doesn't bother slanting the caret when the caret is in slanted text, so isn't affected. We do slant the caret, with the intent and expectation that the caret will then match the text it is in.
  11. I can reproduce it with Tahoma. I've not tried anything else. It happens because the font gives the soft hyphen character (U+00A0) the same glyph index as a normal hyphen (U+002D). It then kerns 't' with the normal hyphen's glyph index, effectively specifying that 't' kerns with soft hyphens. Arguably the font should not give soft hyphens any outline at all; we already have code that prevents them being drawn, but they were still being passed to the OpenType engine. Looking into this I've found several other issues where kerning or other OpenType rules are affected by things they shouldn't be. For example, if you have an index mark between "AW" it won't kern. If between "fi" it won't form a ligature. A floating object pin will also make a difference. I've logged this to be fixed in a future update. Thanks for reporting it.
  12. Thanks for the files. It looks like the font specifies an italic angle of 88 degrees. We current respect the font designer's choice as long as it is less than 90 degrees. I'll flag this to be reviewed.
  13. Sounds like a numbered list would work to generate the numbers. If you need the count to span multiple tables, you can tick the Global checkbox and change the Restart numbering rule to Manual Only. Then tick Restart numbering now on the first day of each month. It's probably a good idea to do this in a paragraph style, and possibly have a second style (based on the first) for the first day of the month.
  14. Find and Replace should be able to find the No Break attribute too.
  15. It seems fixed to me. Create a text frame with text and a shape, select both, group, scale with the extra bottom-right text handle - text gets bigger. Ungroup - text stays the same size.
  16. Thanks for the report. It is indeed a bug, and I've logged it to be fixed.
  17. Thanks; I understand what you mean now. I've logged this to be looked at.
  18. In the first line it looks like you have a normal space and then a non-breaking space before the word "above". If I resize the frame it will break at the normal space, which I think is correct. It's easier to see what is going on if you use Text > Show Special Characters. I can only get it to break at the "ff" in "effectiveness" by resizing the frame so narrow that it can only fit a couple of letters per line. There's no particular reason why it shouldn't break there.
  19. It sounds like the default attributes for text frames have been set to include a fill. Is this Publisher? If so you can change the fill from the View > Studio > Text Frame panel. Otherwise using Edit > Defaults > Factory Reset should nuke everything. If this is happening with new documents too, then using Edit > Defaults > Save will save the fixed settings. These option are there so you can set object defaults to whatever you want.
  20. This happens because you have set the Baseline adjustment to -42pt in the Character panel, which is a lot given the 18pt text. The selection highlight is in the right place, but the text is drawn somewhere else. Normally baseline adjustments are used for making superscript-like effects, and I suspect it would be better not to use it as you have done here. There is probably some other way to achieve the appearance you are after.
  21. Currently we support either artboards or multiple pages, but not both in the same document.
  22. Have you tried it? The paragraph needs to be empty (or a list), and not contain other tabs, and the caret needs to be at the start. It's actually pretty common UI in DTP and word processing apps. MSWord and Apple Pages are examples. In Publisher Tab can also change the paragraph style if the style has Next level set. For example, from the default text styles apply Bullet 1 to a paragraph, then press Tab with the caret at the start. It should switch styles to Bullet 2, then Bullet 3, which will change the indent and the bullet too. If you don't like it, you can disable it from Preferences > Auto-Correct > Use tab to alter paragraph level instead of inserting a tab. That also stops the delete key from removing the indent.
  23. That is supposed to work; it's a bug that it doesn't. There actually is another way, but it is even more obscure. Select the path text and then the Fill tool. In the context toolbar should be a pair of controls labelled Context. Change the second one from Text to Frame. Then most of the UI for stroke and fill will affect the path rather than the text. The arrow head controls on Stroke panel seem OK. This also works for text frames and art text. You can use the Fill tool for direct manipulation of gradients. Only Publisher has that Text/Frame context control. We are intending to improve this, but it won't be until 1.8.
  24. Thanks for reporting this. I've logged it to be fixed in due course.
  25. It looks like you are measuring from descender to ascender. The distance being set is baseline to baseline. For your 72pt text which you have set with a leading of 74.4pt, that distance should be 74.4 + 12 = 86.4pt. That is the distance I am getting. The default Space after is 12pt, and it stays as 12pt because there's no mechanism for it to scale with the text size.
×
×
  • Create New...

Important Information

Terms of Use | 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.