thomaso

Alternatively, you can create all labels in one .afpub document, with each label representing a separate page. Then, use the "N-Up" printing option (in the "Document Layout" menu) or "Pages per Sheet" (in the "Layout" menu) and selectively define the pages you want to print under "Range/Pages."

"accept" ? – APub doesn't open but can place spreadsheet files (XLSX) from Microsoft Excel, Apple Numbers or LibreOffice (Calc). For APub's Data Merge the source types include text (plain/CSV/TSV), JSON and XLSX spreadsheet files (e.g. Microsoft Excel, Apple Numbers, LibreOffice). The text files could be an exported address book or contact lists. Your data records could also include image links (resource path names). It seems that there have been no changes regarding spreadsheet file type compatibility since APub v1.10. https://affinity.help/publisher2/English.lproj/index.html?page=pages/Introduction/keyFeatures.html?list&title=Features

You can change the text colour via the Find and Replace panel for the entire document without editing separate text styles individually: Without entering any text for "Find" choose the Format option via the cog icon, then set the font colour to the current colour definition (the one you want to replace), in the "Replace" option set the colour to CMYK 0-0-0-100. Back in the F&R panel press the "Find", then the "Replace All" button. -

It is a common misconception that magnifying 🔎 an object produces the same result as increasing its outline .

If it's fixed you should get the same two tiny colour previews displayed in the wheel with RGB/32 HDR. (However, apart from 8 vs 32 bit, there are several threads in the forum about panel value discrepancies and the assumption that the interface is not colour-managed.)

I agree, it feels quite buggy (– apart from the more comfortable conversion via export). The issue seems to be related to the missing feature to cut or copy one individual text frame from a text flow as a separate object without getting all text copied and the story beginning at the resulting frame. Workaround: Convert the flowing story backwards, convert its last frame first. Or, for V2 only: What if you select all text frames of the document + choose "convert to curves"? Does it convert the entire story? – At least it works in V1 with multiple linked and selected text frames (on the same page).

I am not sure if it's a better way but a different one with a multi-colour gradient applied as contour Outline FX -> Outside -> Contour -> Gradient (i.e. no need to blur separately). Unfortunately the colours don't blend properly (an Affinity issue also known from other situations) and it requires some fiddling to set the radius + reduce the banding (actually I didn't see a difference when each gradient colour got its Noise set to 100).

BTW, to provide text as curves in a PDF to the printer you don't need to create/save an additional .afpub document but can use the export option "Embed fonts: Text as Curves".

I don't think it's possible. – But the Cog Tool seems to be suitable for that shape: I assume to achieve "1000% perfect precision" for a shape, we would possibly have to calculate all angles and lengths mathematically correctly and then construct the shape as a composition of the simplest possible shapes (geometric addition, subtraction, etc.). Just in case: There are several threads in the forum about mathematical precision versus the generic Affinity Shape Tool objects. For example, an Affinity circle is not a "perfect" circle, FWIW.

https://affinity.help/publisher2/English.lproj/index.html?page=pages/Panels/

… or enter some line brakes + set the Justification -> Word Spacing to zero. (see right text frame + panel) As mentioned, what you are experiencing is not an “weirdness” but a consequence of the enormous length of words such as those that do not really exist. In my example the punctuation itself doesn't cause a line break (left, green) but a space character* does (left, orange). *displayed as Special Character with a blue centred dot

It's difficult to judge what's going on. Unfortunately, only a visual result is displayed but any indicator for the conditions/settings isn't, especially how you achieved reduced word spacing (aren't there any or were they reduced by a certain setting, e.g. via 'Justification' options in the paragraph attributes?). The width of the text frame is even cropped, so neither the right edge of the text frame nor eventually line break details are visible. However, if a continuous word runs across multiple lines, this can lead to unexpected results anyway, and the app creates unexpected line breaks. Affinity may interpret a punctuation as indicator for the end of a word which may cause a break before the next endless word. You can achieve a similar oddity if you type only one word and reduce the text frame width until character by character moves to the next line... even without typing any line/paragraph break or hyphenation. It appears useful if you post a screenshot of the entire Affinity window with some characters in this frame selected and including the Character + the Paragraph Panel with their relevant sections unfolded. It's also useful first to activate the option "Show Special Characters" (menu Text) if available in your Affinity app (which?)

To get clarification from Serif after all the vague speculation it may be helpful or necessary to file a bug report in the V2 bug forum.

I'm sure there are several useful ways to construct such an object. For example, your starting point with the "Square Star" shape may work, too. And rotating the object might also work or at least wouldn't harm if the object has a 1:1 aspect ratio with the individual edge segments of the polygon having identical length.

This solution would mean that a generic shape object (e.g. "Ellipse") converted in AD (or APh) to a "Shape Text" or "Shape Path Text" frame would preserve a fill colour of the generic shape object. Since this is the case in V1 in APub only but not in AD/APh, I wonder if this behaviour was changed in V2?