Dave Harris

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.

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?

There's a bug in how the Column end zone interacts with the flow options, in this case the widow and orphan control. That's what causes an extra line to be moved - and then the short paragraphs mean that more lines get moved to avoid widows and orphans. This will be fixed in 1.8 (but the fix may not make the next beta). The Column end zone doesn't extend past the last line (or paragraph boundary), so it should be safe to set to a large value. The reason it is a value rather than a checkbox is that if the text engine is not allowed to hyphenate a very long word, you may end up with a last line that is either very loose or very ragged. Sometimes a hyphen may be the lesser of evils.

OK, there is a bug in the interaction between Column end zone and Prevent orphaned first lines and Prevent widowed last lines that can cause it to move an extra line. Because there are several paragraphs of two and three lines, that bug ends up causing the large gap. If all three options are off, the word "hangon" is hyphenated at the end of a column. If Column end zone is then set to 80mm, that word is moved to the next column, which is correct. However, that leaves the last line of the paragraph as a widow at the top of the next column. If Prevent widowed last lines is switched on for that paragraph, it should move one line from the previous paragraph. It actually moves two. That makes a new widow, so if Prevent widowed last lines is switched on for the paragraph that moved, two lines are brought forward. That makes an orphaned first line, so switching on the option to control those moves a third line forward. The bug should be fixed in 1.8 (although it may not make the next beta). Thanks for reporting it.

Thanks. I'll need some time to look at this.

Indent to here should be in the next 1.8 beta. As should Right indent tabs, and hopefully Last line outdents.

Mykee, sorry for not getting back to you quicker. Setting the zone to 285mm should work fine. I've not been able to reproduce the behaviour where it moves the entire line or paragraph to the next page. Is it possible there were some other settings, such as Keep together or Prevent orphaned last lines involved? Can you attach a small sample document which show it going wrong, so I can examine what is happening?

This will be in 1.8, and the next beta. Petar, can you give an example? If a line begins "The, I think it would look weird if the opening quote was not the same size as the T.

The feature I think you are asking for should already be covered by the Column End Zone. That should prevent hyphenation at the end of the last line of a column, if you set it to a suitably large value. You can use several inches if you don't mind very long words being pushed to the next column. I just tried it in 1.7.3 and it seemed to work. You say it doesn't work for you. What did you try, and what happened?

The PDF should look the same as the main canvas view. If the text is truncated or is drawn below the bottom of the text frame, that's how it will be in the PDF. If you are happy with that you can go ahead. It won't upset Publisher.

I believe this is a known bug that has been fixed in the current Publisher beta for 1.7.3. It will be fixed in Designer too, when that gets updated.

Ah, this is in a Table of Contents. It looks like paragraph numbering doesn't interact well with ToC. The ToC will effectively freeze fields when it copies them, but it doesn't freeze numbered lists the same way. This is a bug. I'll log it to be fixed. It looks like the ToC text styles apply their own numbering, and used different settings. If you use the same settings but make the ToC list non-global, it should work reasonably well. Also, after you edit the main text you will need to update the ToC. On this spread it is the master pages that have the wrong z-order. They can be reordered, although it's not as easy as it should be. If you go to the Layers panel, unexpand the second master page, you should then be able to drag the first master page to below it. I'll log this to be improved too. I've attached Testfile2.afpub that shows what I think you want. Testfile2.afpub

It uses z-order to decide the ordering of unconnected frames. It doesn't use x/y position because if you had a 2x2 arrangement, you might want it to left-to-right then top-to-bottom, or top-to-bottom then left-to-right. If you go to the master page and use the Layers panel to swap the text frames around, it should work as you want. I'm not sure I understand you, but I notice you have Global ticked only for the level 1 list. It should also be ticked for the level 2 list. That's why you are getting 0.1 instead of 2.1.

I agree there's a bug here. The bug is triggered by putting No break on the space after the words as well as the words themselves. With that attribute, it can't break before the next word. It does scan back to the start of the No break range, but stops one character too early so doesn't find the break after the previous space. I'll log this to be fixed in a future release.

It can also be done with paragraph formatting, using Flow Options > Start: In Next Column. This version can be used in a text style, eg a heading style.