Dave Harris

Can you upload a document where they are set wrong, so we can see what is happening and fix it?

You can set the text background colour from the Character panel. It's next to the Font style and colour.

Could you expand on this? What were you expecting that doesn't happen?

PDFLib used to support it, but decided to stop doing so in recent versions. I've not been able to convince them that it is needed.

Thanks. I had actually been testing on an older version, 1.8.0.499, where it works. It does crash as you describe on 1.8.0.518. So it is a relatively new regression. I've logged it to be fixed.

1.7.3 has a lot of problems in that area. 1.8.0.518 should be a lot better. I just tried with a new blank document and it seemed OK. Do you have a more detailed recipe?

In InDesign is it both an inline graphic and a drop cap. I just tried in in Publisher, and it didn't work as well as I expected. The image gets sized and positioned correctly, but the next character gets drop-capped as well. You can avoid this in the 1.8 beta by setting the character count to 1. I'll tweak it so that using the auto character count only affects the image. Either way, I think the feature is better than in InDesign because the image scales automatically. This means you can change the number of lines dropped in a text style, and it will update the images in all the paragraphs that use the style. You can achieve a similar result by using a floating graphic that wraps to largest side, but that's not as texty. I've attached a document that shows both techniques. PinDropCap.afpub

If you add text to Preferences, it will pick a random chunk of it each time you insert filler, just as it does for built-in text. Alice in Wonderland is out of copyright now, so you can find it online, eg at The Literature Project. The built-in text starts at "So she set the little creature down" and goes to the end of the chapter. It looks like it uses different quote marks but is otherwise the same.

Rob, if you have both Publisher and Designer, you can use the Designer persona from within Publisher, so you won't need to switch between apps as often as you may think. You can also use the Photo persona in Publisher if you have the Photo app installed. We didn't want to talk about this in public before Publisher was released, but now we can. We think it is brilliant.

Fitzj, I believe you can do that in Publisher already. Have you tried? If you make the graphic pinned inline, it should behave like a character in virtually every way, including for drop caps.

The intended rule is that text wraps around objects with wrap outlines, with the exception that two text frames won't both wrap around each other if that would leave a space empty of text. In that situation, z-order decides which frame wins. The frame underneath wraps to avoid its own text being hidden by the frame on top. In your example, the yellow frame has a wrap outline, so the orange frame wraps around it. This doesn't leave a space empty of text because the yellow frame is ignoring wraps on other objects and so fills the overlap with orange. So the z-order rule isn't needed. The rationale is to avoid both spaces empty of text and spaces with overlapping text. If we change the rule as you suggest, then the area of overlap between the orange and yellow frames will be filled with text from both frames. In practice such overlapping text becomes an ugly mess that cannot be read. So that's why the current behaviour is as it is. I appreciate it is not quite what you expected, but do you agree now that it is being consistent and simple? It's arguably simpler than InDesign's behaviour because it doesn't have a special case of ignoring z-order for graphic objects. When you say it is "incorrect", is that just because it is different to InDesign or has it caused you a problem in a real document?

1) The positioning problem is due to an interaction between the drop cap and optical alignment with justified text. If in the first line you switch optical alignment off for 'T', it is positioned correctly. This will be fixed in a future update. 2) I can't reproduce this. I doubt it involves the drop cap. Exactly what did you type to make it happen? 3) and 4) This happens because the text is justified and that is interacting with the kerning. In effect the drop cap gets its own little box. Kerning changes the width of that box, and then justification applies letter spacing to fit the whole box. It behaves as expected with left-aligned text. I agree it's wrong and should be fixed. Thanks for reporting these. As far as I can tell, none them are to do with the new Characters feature in 1.8. They all happen in 1.7.3, too, if you have the same combination of justified text and optical alignment, so they aren't a new problem with drop caps, and it's no more unusable than it used to be. There's a drop cap field Distance to text that can help with positioning, rather than trying to kern between the drop cap and the following text.

You should find that most Apple shortcuts work even if they aren't listed. For example, Ctrl+k will delete-to-end-of-line by default. Also holding down a letter like 'a' will offer a range of accented variants. Support for this stuff is partly provided by MacOS. Exposing it in a way that lets users disable it seemed a bit pointless. If you define a shortcut to use Ctrl+k, it will hide the Apple text command, but I doubt many people use it. The few Apple shortcuts that didn't work are things like Cmd+Left, that were used for changing kerning, leading, and baseline. One issue to be aware of is that if you switch to Apple shortcuts, so Cmd+Left becomes move-to-line-start, then shortcut for kerning changes. So it's not just text entry commands that are affected. Previously we had two buttons, Reset and Clear all shortcuts. Both of them would remove all user customisation without warning. 1.8 effectively adds another Reset, to different defaults, and it works the same way as the other two. I think this is clearer and simpler than having the three buttons work differently with some only affecting a handful of shortcuts and some affecting all. We've never had an "Are you sure?" prompt for the old two buttons so we didn't add one for the new button either.

That's because the Normal style has its Next style set to [No Style]. I'm not getting the hidden control characters.

I'm not seeing that behaviour with the file attached. Are you sure you didn't set the frame to be Justify Vertically?