Dave Harris

Not ideal, but you can use shift-click to select everything in the Layers panel, then unlock them all, then select it on the canvas and use Find in Layers Panel. Once you know where it is, you can use Undo to restore the locks.

Multi-level numbering and bullet styles are already supported. The default text styles list has "Numbered 1", "Numbered 2", and "Numbered 3" as examples. They use a combination of the list Level (each level gets its own counter), the Text field to set the 1.2.3 format, and usual paragraph indents.

The default font, colour and other formatting for the number have to come from somewhere, so they come from the first character of the paragraph. You can override it by specifying a character style in the list format.

In the latest release there is an option in the More section to control whether images are converted. By default they are for all PDF formats except PDF/X-3 and PDF/X-4.

This is because of how the style is set up. We have an option Restart numbering which defaults to Any Non-List, and your style does not change that default. Change it to Below Current Level to get the behaviour you expect. The default is intended to make it easier to format blocks of text as numbered lists without having to set Restart numbering now on the first paragraph. On my Mac the Level 1 style shows as [No change]. Presumably whoever created the style felt that the default was OK for level 1, but wanted something different for level 2. Two lists with the same name will be numbered consecutively even if the paragraphs they are applied to are intermingled with different lists. The Global checkbox will make the numbering consecutive across different stories, too. Useful for things like auto-numbering figure captions. Half-checked means that the style does not change this field. Instead the setting will be inherited from a base style, or left unchanged at whatever the text the style is applied to had it. The checkbox should cycle between checked, unchecked and half-checked each time you click it.

Yes.

I have a tool that explores a PDF at low level, without drawing it, to see the operations it would draw with.

For me it becomes a shaded rectangle, drawn with a soft mask that is a transparency group that is also a shaded rectangle. If I hide the other objects, there are no bitmaps or raster elements in the PDF; it's entirely vector. This requires a PDF format that supports transparencies (so not PDF/X-1a or PDF/X-3), and also needs Allow advanced features checked in the PDF options (this is off by default for PDF for Export and PDF For Web presets). The File > Export > PDF panel will have (Nothing will be rasterised) next to the Raster DPI field when the settings are correct. Here is the PDF: 1.pdf. However, if I then reimport the PDF into Affinity, the transparency group is rasterised during the import. This is because PDF transparency groups are more general than what Affinity can support, and it's not yet clever enough to recognise the simple case of a gradient that it produced itself. I get similar results from Designer 1.6.1.

Currently blank lines at the top and bottom of a run of decorated paragraphs won't get the decoration. This was a mistake which should be fixed in the next build. I hope that covers your situation.

There are two ways of using it. One is to position the object by hand, and tweak the rules so it maintains that position as it flows by making it relative to the appropriate thing. In this mode, Publisher does what it can to preserve the position you set manually. It actually worked roughly the way you suggest originally, and the object would jump about as you changed the rule from Inside Left to Outside Right or whatever, and the early feedback was that this was annoying. The other way of working is to tick the Lock position box, and then the object is positioned entirely by the rules and will jump about as you change them. It will also jump when you first pin it, if the box is ticked by default. This can be useful if you know you always want the same relative position. I think both approaches are reasonable ways of working that should be supported, and switching between them by ticking or unticking the box feels at least plausible. However, I agree Lock position may not be the best name for the checkbox. By the way, does everyone realise you can reposition the pin of a floating object by dragging it? If Lock position is checked, this will also move the object; otherwise, it updates the offset.

Both Character and Paragraph studio panels list their respective styles in a drop-down list.

I can only see a docx file. If I import it and autoflow, none of the pictures are hidden. Presumably you are then manipulating them in some way to make them vanish, but I can't guess how. The only behaviour I see is what I already described. Moving the image up has the effect of giving the image a negative advance, pushing the baseline down and leaving the image where it is. Push the baseline down far enough and it will go into a different frame. If there is no frame large enough, it will go into overflow. Moving the image down gives it a positive advance. This reduces the vertical space it needs so may move the baseline up, eventually moving the image to the previous frame. Currently inline images can overlap following lines, so some of the text may get hidden behind the image. You can see what is happening by checking the Advance in the Pinning panel; setting the Advance to zero will reset the image. If this does not explain what you are seeing, please attach a publisher file that includes a hidden image.

If you attach a simple document with a picture that is disappeared as you describe, I'll take a look at it.

You can force text to be converted to curves with a setting under File > Export > PDF > More > Embed Fonts. Assuming that isn't happening, Publisher may convert fonts to curves automatically. That can happen if the text has a gradient fill or bitmap fill, or if PDFLib doesn't understand the font.

The way it works now is not the way it is supposed to work. It is supposed to reduce the document size; it's a bug that it doesn't. We're not intending a "tracked" feature. This hasn't been fixed already for internal reasons I can't explain here, but we've not forgotten about it.

I think I addressed that point in my final paragraph. If you move the inline image so its baseline goes into overflow, it won't be drawn on the page. If that's not what's happening, could you give an example?

That point is addressed by the second paragraph in my post. Inline characters can't be moved from side to side, and moving up or down may only affect the text baseline.

I'm afraid this is by design, and not a bug. As I recall it is how arrowheads work in Illustrator, so it is actually a fairly standard approach for drawing packages. They would work like that in Designer regardless of when they were added to the software.

Only floating images get the line showing where in the text they are pinned to. They need it because the pin can be far away from the image. Inline images always have the same position as their pin so don't need the line. Inline and floating generally behave very differently: pinned objects are almost two features rather than one. Inline images behave like characters. Because inline images behave like characters, you don't get much control over how they are positioned. You can't move them from side to side with the mouse, because they have to stay between the characters to their left and right. You can change their size, and move them up or down. When the images are larger than the paragraph leading, doing that has a similar effect to changing the height of a very tall character. The leading increases or decreases to accommodate it. Essentially I think the inline images are working as intended. I have imported your document into OpenOffice and it has similar restrictions. They can't be moved horizontally. This sounds like the inline image is too large for the frame and has gone onto the next frame, or into overflow. If the latter, it will still be listed in the Layers panel, but the visibility checkbox will be unticked (and disabled). If you show overflow text for the frame, the image should be drawn again. Then you can decide what to do about it - make the text frame bigger, or the image smaller, or use autoflow, or whatever.

And to make all the default formatting of the current document be the starting defaults for new documents, use Edit > Defaults > Save. This will affect things like shape colour and stroke as well as text.

There are two factors involved here. The first is that the shape has wrap settings. When it is not pinned, the text wraps around it. When it is inline, it behaves as if it were another character, and characters don't wrap around characters. They just avoid each other by being placed one after another along the baseline. The default pin location is picked with the text as it was before you pinned, which then moves when the text stops wrapping. I'll see if we can do something about this, but in the mean time I'd suggest you switch off wrapping for the shape if you intend to make it inline. The second factor will become more apparent if you do that. It's due to the shape being taller than the text leading, so when pinned inline both it and the line of text it is pinned to are pushed down so that it can fit below the previous line. When you unpin it, the text jumps back up but the shape stays where it is. If you pin it inline a second time, it gets a different pin location because it is now above different text. I don't think there's much we can do about this. It may help to know that the default text location for inline pins is under the bottom left of the shape's frame box. (For floating pins it uses top-centre of the box.)

It looks like the labels for Advance and Base position have got swapped around on Windows. When you click up on what is labelled as Base position, you are actually increasing the Advance, which correctly moves the object down. We'll get this fixed. It's just a cosmetic issue, though, albeit confusing.

The menu options are separated by a divider because they work in two different ways. The first three options are dynamic: they are done at draw time by glyph substitution, possibly using OpenType features, without changing the underlying characters. This means they are part of character formatting and can be used in text styles. It also means they can be switched off, because the underlying characters are still there. The other options are one-shot. They don't just effect how the characters are drawn, they actually edit the text as if you had typed in the capitals yourself. This means they aren't formatting, and can't be part of text styles or switched off. That's why they behave differently and why the second group don't get ticks.

The main use of Advance is for small shifts to get things to line up visually. You can use Base position to place the bottom of the object at the text baseline or the text descender, but neither may be quite right. Similarly the left and right border can adjust the horizontal spacing, or create overhangs. A large negative advance will push the shape's own baseline down, but a large positive baseline won't push the following line's baseline down. Perhaps it should, to be consistent. The Leading override option on the Character panel may help.

A Group style is one that you never intend to apply to text. Group styles are not included in the list of Character and Paragraph styles in the text context toolbar, or in the Character panel or Paragraph panel. They are listed in the Text Styles panel, but separately from the other styles, and clicking on them does nothing. So all you can do with them is base other styles on them with Based on. The idea is that you use them to share formatting between the other styles, and/or as a way of organising the Hierarchical view in the Text Styles panel.