Dave Harris

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.

Sorry - that's a recently introduced bug. Should be fixed in the next beta.

The approach Joachim explained can be used to update any pre-existing style. The trick is to avoid applying the style you want to update. You can do that by using right-click on the name of the style, or a normal click on the menu icon to the right of the style name, in the Text Styles panel. Either of those will bring up the menu for the pre-existing style without applying it. You can then edit or update it safely.

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.