Dave Harris

There shouldn't be any difference between the SVG size of Art and Frame text. There's no way to convert between them, but if you copy and paste the text from Art to Frame you should find the SVG produced is identical. I'd be interested in any examples to the contrary, where the text is formatted the same. For the smallest size, you might want to play with the export options, especially under File > Export > More. I don't think Longer text spans ever gets switched on by any of the presets, but it can help with the size of text.

Show Typography is also in the main Text menu. It sounds like it got hidden in the text toolbar because your window was too narrow to fit it in.

We've discussed this in the office, and have decided to keep the click-to-create for Art text. In the next beta the behaviour should be more similar to 1.4.2. Together with the new behaviour of the text tools tunnelling into groups and under overlapping objects, this should make working with text easier (and working with non-text harder).

There was a bug in 1.5.0 beta 11 with creating Art text (by any means) over a pixel layer. That is fixed in beta 12. You can now create Art text with a precise text size by dragging, because the drag snaps to the default size. The default size is the same size that clicking would produce, and changes to the last size you set. For example, if you drag one piece of Art text to be 67.5pt, and then drag for a second one, it will snap to 67.5pt, so you can create several text objects at the same arbitrary size. You can also put an exact size in the text context toolbar, eg 64pt, and then drag and it will snap to 64pt. This currently happens even if snapping is turned off. The click-to-create idiom is evolving. The Art text tool is the only tool that does that, which is inconsistent and has also caused problems with people trying to get out of text entry mode by clicking and not being able to. So I have been trying to make it less eager to create on click. In 1.4.2 it only does that if there was no text selection; currently it only does it if there is no selection at all, which I felt was more predictable. Whether clicking will select non-text objects in 1.4.2 is quite erratic. Currently it always works if there is no text overlapping it, which does interfere with click-to-create. I am considering dropping the click-to-create idiom entirely, so all text is created by dragging, all the creation tools are consistent, and clicking with them always selects. I am hoping the drag-snaps-to-default-size thing described above will make that feasible.

Is this happening in 1.4.2? I believe this is fixed, or at least much improved, in the current beta. The fix will make its way to the Mac App Store in due course.

Hold down Alt as you click the button.

You can apply character styles to whole paragraphs by using Apply to Paragraphs from the Text Styles menu. If you check Show in both panels in the style editor, it will appear in the Paragraph studio panel and you can apply it to whole paragraphs from there, too. If you have, say, a figure numbers as captions below pictures, and you want the body text to include a reference to the figure, it may be convenient to use the same style for each. Or at least to have a character style (for the body text) that is based on the paragraph style (for the caption). It's some extra flexibility that is available. You don't have to use it if you don't want to.

There's actually not much difference between character styles and paragraph styles. Both can store all the attributes, and they can be based on each other. Likewise "Text styles", or group styles. The idea of group styles is that other styles be based on them, so they can be a common place to set attributes that the other styles use. Whether a style is "Group", "Paragraph" or "Character" mostly affects which toolbar lists they appear in, which studio panels they appear in, and what the default action is when you click on them in the Text Styles panel. You can apply paragraph styles to character text, and vice versa, if you want. The hope is that having a single, unified system will be more flexible, and less restrictive, than having two parallel separate sets of styles.

We changed text selection in a few ways, but it's intended to make it easier to select text. In what way is it harder?

Opening the same window is intentional, but the initial settings should be different. The "Paragraph Style" one should have Type set to Paragraph, Based on set to the paragraph style of the selected text, and all the attributes set to the text's changes from that style. The "Text Style" one should give a completely empty style, with Type set to group.

I doubt we'll even attempt editable text in PSD export until long after Publisher is released. It will take months to do, and that time would be taken from the Publisher budget, so Publisher would be delayed by (further) months. I'm sorry, but Publisher has been delayed enough already and we don't want it to be any later than it needs to be.

I don't think our export supports them in TIFF. You can make a feature request if it's something you need.

This change is about wrapping inside irregular text frames created via Layer > Convert to Text Frame.

Both PNG and GIF formats support 1-bit bitmaps. Our support for that in Export got broken, but will be fixed in the next beta.

But wouldn't Publisher be a better tool for producing those websites?

For Designer the link is in the first post of the first thread here: https://forum.affinity.serif.com/index.php?/forum/15-affinity-designer-on-mac-beta/. For Photo the link is in the first post of the first thread here: https://forum.affinity.serif.com/index.php?/forum/19-affinity-photo-on-mac-beta/. I'd rather not link directly to the file in case someone following the link misses the caveats in the forum posts.

Alevax, can you try using the current beta for exporting to PDF? You can download the beta from the beta section of this forum. It's free for customers. (Best not to save documents from the beta, though, as they won't load into the Mac App Store app.) The Mac App Store will be updated with the beta in due course.

Once text is selected, you can switch to the Text tool by pressing T or by clicking on its icon in the toolbar. Either of those should be less disruptive than bringing the text to the front. And once in the text tool with the text object selected, it should stay selected as long as you are working with it. The double-click shortcuts don't work well to switch tools in these overlapping cases, because the first click changes the selection to the upper object. This happens because we can't know it is the first click of a double-click without actually waiting for the second click, and waiting would make the UI less responsive. This isn't text specific; the same issue arises with double-click on shapes and curves too. That said, we have considered a text-specific solution, which is to make the Text tool always prefer to select text. It would be inconsistent for the Text tool to behave differently to all the other tools, but it might be worth it. Even this would only help if you were already using the Text tool.

What kind of use cases? Posters, brochures and the like are more Publisher's area than Designer's.

I'd suggest either using higher resolution when you flatten and/or export to PDF, or else don't flatten at all.

File > Save As can reduce the file size from either app. Our file format is optimised for speed, and sometimes appends changes to the end leaving unused space in the middle of the file. Using File > Save As gets rid of that no-longer needed space.

File > Export > PNG, or use the Export Persona. Unless I've misunderstood.

We already support Font Book's font categories, on the Character Tab and Edit Text Style panel. We don't have the category control on the text context toolbar for space reasons.

The menu option Layer > Convert to Text Path should also work. This puts the handles in default positions, which can be easier than positioning them by hand.

No. They must be relative to a font, but that's OK because in the text height control they can be relative to a font. I think using em for artboards would be equivalent to implementing user-defined units. It's not something we are currently planning to do.