RM f/g

Thanks for the update and screen recording provided @RM f/g - I can confirm that I have 'bumped' this with our devs to bring it to their attention once again, as well as included the steps shown in your recording, whereby simply reducing the width of the table also causes the size to grow vertically unexpectedly without the need for return characters.
I hope this helps

I'd be even more pleased if it would also remember my prefered ‘Save into’ folder

I'd be even more pleased if it would also remember my prefered ‘Save into’ folder

Hi Jeff
Have a closer look at the text frame. You'll see two handles/nodes in the bottom right corner.
Moving the inner one will scale/transform the frame only, moving the outer one will also scale the contents of the frame.
Brilliant.

It's not in the dropdown list. You'll have to copy it from text elsewhere. ‘Indent to here’ is command + \ on mac or menu Text > Insert > Spaces and tabs > Indent to here.
In the screenshots you can see what it looks like in the Number text box and in the note itself.
Hope this helps.
 

Replace the paragraph break with a line break (shift + return). That should do it.

Replace the paragraph break with a line break (shift + return). That should do it.

Looks to me that you have the raw file linked to your afphoto file, not embedded.

Graphic Converter has some powerful digital asset management features such as the Browser which works with your existing file structure and has extensive metadata tools (for instance, ExifTool is built in), convert and modify, powerful batch processing, renaming tools, face recognition, ratings, labels and tags, non-destructive editing in Cocooner, basic RAW editing, cataloging to print or html, etc etc. It took me a few days just to go through the multiple preference options (which fortunately can be exported to a reloadable file).
The trial is not time-limited and is fully functioning. MacOS only. It's still under active development by Thorsten Lemke who originally released it in 1992!

The workaround I'm trying out at the moment is wrapping line art drawing in a pdf which can be set to passthrough in Publisher.
Open an line art (1 bit) file in Photo or Designer.
In document setup:
– Set Colour Format to Grey/8
– Set colour profile to Black & White
Export to pdf using:
– Downsample images: no
– Use document resolution
– Colour space: as document
– Colour profile: use document profile
Place pdf in Publisher document using Passthrough.
This seems to work as long as I don't have to make a pdf/x.
BTW: do not use Photo or Photo Persona to check colour separations: this wil give you the separations of the preview within the Publisher document, not of the actual placed pdf.
 

Hi RM f/g

The lack of using Carriage Return appears to be a regression over 1.10. I've passed this over to development, and mentioned about setting the focus on the field as well.

Thanks, one of the things I was hoping for.
It would be even nicer if we could read the measurments from the transform panel (as well).

Thanks, one of the things I was hoping for.
It would be even nicer if we could read the measurments from the transform panel (as well).

Thanks, one of the things I was hoping for.
It would be even nicer if we could read the measurments from the transform panel (as well).

Clever!
We can combine both lines in the Appearance Panel.

Clever!
We can combine both lines in the Appearance Panel.

Here’s a Publisher document with three sidenotes near the bottom of a text frame. The first note is a rather long one.
Notes 2 and 3 aren’t visible. Not on the page where the note references are, not on the next one.
When the third note moves to the next text frame (e.g. when inserting text before the  first note), notes 2 and 3 both appear at the top of that page.
I suspect the reports of Publisher crashing when converting footnotes to sidenotes are related to this. In a document with longer footnotes these notes were converted to endnotes without problem, trying to convert them to sidenotes resulted in Publisher crashing.
Publisher 2.0.3  / MacOS 12.6.2
 


TestSidenotes.afpub

Good catch!
I didn't think to look for the notes in the Layers panel. Without any changes to the test document, we can see that the second note is on the right page but when clicked its bounding box is shown below the frame instead of to the side. And the third note is on the second page and when clicked its bounding box is below the right frame instead of to the side.
The issue is if there is not space on the side for the sidenote due to the previous sidenote extending to the bottom of the frame, Publisher is failing to adjust the start position of the previous note and is instead positioning the new note below the frame or the frame on the next page.

Here’s a Publisher document with three sidenotes near the bottom of a text frame. The first note is a rather long one.
Notes 2 and 3 aren’t visible. Not on the page where the note references are, not on the next one.
When the third note moves to the next text frame (e.g. when inserting text before the  first note), notes 2 and 3 both appear at the top of that page.
I suspect the reports of Publisher crashing when converting footnotes to sidenotes are related to this. In a document with longer footnotes these notes were converted to endnotes without problem, trying to convert them to sidenotes resulted in Publisher crashing.
Publisher 2.0.3  / MacOS 12.6.2
 


TestSidenotes.afpub

I can confirm that in the last  1.10.4 version  the TOC styles are still completely bonkers. And that I have find the solution (probably)
Each time I update the TOC, the styles got bananas. And I'm using all the correct indications by Affinity.
I use the automatic TOC styles that Publisher generate on TOC creation. I modify the automatic TOC styles to my needs preserving their original name. I update the TOC and then all styles are being modified with what it seems random attributes.  It does not have consistency. If I quit the app, reopen and repeat the process, or even if I update after being working with the document, the results are completely different. I tried to find a logic to the changes in the styles. I noticed that in the TOC style panel, indicates that it is using "Table of content 1: Style name + some other style…"
So it seems Publisher is adding the last used styles to the TOC styles each time I update. That explains the lack of consistency on this random behavior. And although there is a button to reset/clean the format of the styles (The recyle icon just at the right of the used style info), it does not get rid of all the changes it added.
I tried the following. I made a random text frame, wrote something and then I put both paragraph and text styles to [No style]. That way this configuration becomes the default text configuration. Then I went to the TOC, updated it and VOILÁ, my TOC styles where there perfectly formatted as it should have been from start. Nothing was added to the TOC style table.
So, definitively this is a bug on which updating the TOC mixes TOC styles with the last styles used on the document.
I hope you all can reproduce this and make those TOCs work well. And that Affinity read this and check over it.
 

You could try to copy the current upholstering to a new layer. Soften it, desaturate it to grey and use that layer to blend with the new pattern to give it it's shadows/highlights.
Still you would have to ‘bend’ this pattern over the curves of the cushions.
All in all it might be less cumbersome just to buy another boat...

The transparancy tool works on placed images as well.
Just give it a try.

Save the .indd inDesign file as .idml.
You can open .idml files in Publisher and you'll see they have all the styles from the inDesign file.

Save the .indd inDesign file as .idml.
You can open .idml files in Publisher and you'll see they have all the styles from the inDesign file.

The default UOM is currently pixels, as you say, because that’s what images are measured in.
However, not everyone works at a pixel-level and that’s the issue here (if I have understood it correctly).
I think the gist of the request is basically this: Since the user can manually set the UOM after they open an image, and not everyone works at a pixel-level, it would be nice if users could get the software to (optionally) change the UOM for them automatically, as soon as they open an image, so they don’t need to do it manually each time they open an image.
While opening a template, or using a preset, and placing the image is only a few extra steps, they are extra steps that some people don’t want to do.