sfriedberg

I routinely set up numbered and bulleted paragraphs so the left edge of the text is all aligned vertically, so that effect is easy to achieve. I'm not sure what you mean by "get the diamond centered". Are you only showing us the right half of the page in that screenshot? If I understand what you want, use a tab stop instead of a space after the bullet(s). Adjust the tab stop, first line indent (outdent in this case) and paragraph indent to align the text in the first and subsequent lines. The order in which you set the first line indent and paragraph indent matters, but if you do it in the wrong order, just do it again in the other order. If you want the whole thing (bullets and all) to start halfway across the page, I'd strongly recommend using a text frame to confine the half-page bulleted paragraphs. If you're using Publisher you can even make that text frame flow inline with the rest of the text for more-automated layout, although it will not automatically break across page boundaries. If you can get everything to work except the desired justification mode and if you are using Publisher, in a pinch you can use multiple text frames to control the layout precisely. The story/flow text goes in one frame without bullets using the left edge of the frame to govern the left-side text alignment. No bullets, no indents or special margins in the story/flow text paragraph style. The bullets are made into tiny text frames (or symbols) and pinned to float with the story/flow paragraphs. In the pinning panel, align vertically to inside top of line, and horizontally to inside left of frame. I repeat this is an "in a pinch" sort of solution. I've done it a couple of different ways in the attached document. On the first page, I did it the hard way. On the second page, I did it with a bulleted paragraph style using a tab that matches the paragraph indent. If you don't want normal story/flow text to the left of the block of bulleted paragraphs that is very easy to achieve. Either set the text wrap style on their frame (to get nothing to the left) or add another to include more special paragraphs. test.afpub

No, we aren't sure without looking at your file. But I speculate that your transform origin was not pixel-aligned, so when you rotated your nice clean pixel-aligned rectangle it was offset by a half-pixel in both X and Y leaving the result with anti-aliased edges. You can do the following experiment. With the Transform panel, select the transform origin in the middle the square of nine points. Try rotating one of your nice clean pixel-aligned rectangles (with Transform). Then try the alternate experiment of selecting a transform origin at any one of the corners of the square of nine points and rotating another nice clean pixel-aligned rectangle (with Transform). I expect the first experiement will give you blurry results, while the second experiment will give you clean results. But you can report back with what you actually get. I speculate that in Photo the transform origin for right-click rotations is set to the middle of the object. Designer lets you persistently set the transform origin for an object anywhere you like, including the corners, so in Designer you could do your right-click rotates and get clean results. Photo apparently does not have the Point Transform tool, so you may have to use the Transform panel and pick a corner. Or, try rectangles with even width and length, as the middle would then be pixel-aligned. Although your example with the two-pixel wide red lines suggests it's not as simple as getting the width right. [Added in edit] Actually, Photo has the same basic functionality but presented with a completely different UI than Designer. With the Move tool selected (in Photo), the content toolbar at the top offers an Enable Transform Origin mode. In that mode, you can drag the object's origin cross hairs. Right-click Transform > Rotate Right/Left does not respect the new origin, but dragging the object's lollipop handle (and snapping to nice angles by holding Shift) does. I have to say that if I were doing fussy layout with lots of lines and positioning, I'd be inclined to do it in Designer, not Photo. But if you only have the one app, run what you got...

I am not suggesting that Publisher add this feature, but it would be nice to view the spreads with the foldouts folded in, and also with them folded out as in Hangman's sample layout. It's easy enough to show both sides of the foldouts, but they'd naturally fall in different spreads. For example, the very first spread would have not only the 1st right-hand page but also the visible-when-folded-in face of the foldout on the 2nd left-hand page. It would be nice when viewing the second spread to be able to switch between folded-in (foldout overlaps left-hand page and one face of foldout is visible) and folded-out (foldout is next to left-hand page and the other face of foldout is visible).

Ahah! Thank you. That makes perfect sense, together with your original description. Signature of 3 folios, each with two foldouts.

Interesting, I had v1 fired up to work on an older project so that's what I looked at. The additional fields are new in v2. The balanced option in v2 is very useful, can't believe I'd forgotten it.

For dashed lines, there is an interaction between the width of the stroke and the pattern of the stroke, both of which you can control. To make the dashes narrower, reduce the stroke width. This will also make the dashes shorter. To restore the length of the dashes, edit the pattern. This appears at the bottom of the Stroke panel when you select the dashed style. There are four fields. The first is how long to make a dash, the second is how long to make the space between dashes. If you use the 3rd and 4th fields, you can define dash-dot patterns with alternating pieces of different lengths (and spacings).

@Wolfgang T., I have some tangential questions concerning the tricky bookbinding. The spreads show how the book would appear as read. I'm interested in how you will be arranging folios (physical sheets) and signatures (groups of folios sewn as one unit) from the spreads. Can you make a quick pencil sketch of the top/bottom view of the text block for Hangman's sample layout of spreads? Are you doing any imposition (combining multiple physical (cut) sheets on one larger (uncut) physical sheet)? Are you doing any tipping (adhering two physical sheets, such as a foldout with narrow folded lip to a main signature sheet, or two one-side-printed folios back-to-back)? Are you doing any guarding (sewing in a "stub" sheet, to which a folio or signature is secured by sewing or glue)? Thanks in advance!

FWIW, most graphics apps have confusing or misleading UIs with regard to color management. While I do not expect a UI to provide a built-in tutorial on a complex and highly technical subject, I do expect to be able to find all the applicable profiles, learn exactly what they are applied to, and all the applicable color space conversions, and learn exactly when they are applied. A lot (all too often the vast majority) of that information is not easily found. And there are far too many over-simplifications (for the benefit of the non-technical user, no doubt) and confusions of terms (such as color mode and color space). None of that excuses the Affinity suite. I wish they would do a better job on this. Anybody doing pre-press work needs to know what they're sending to the printer, without having to do a dozen experiments to discover the undocumented (or very badly documented) behavior of the app. The CorelDRAW color management UI is among the better ones. You can clearly see (and set) the document, the printer and the monitor profiles, and the color engine to use, and what profiles to assign to sources or devices without one. No surprises, which is my main complaint about how color management is handled. Too many surprises! Some CD release prior to CD X6 (2013, the oldest release I have installed) had a nice graphic display for the transform flow among scanner, document, printer and monitor but they seem to have removed that. Regrettable, as that was an instantly interpretable UI feature.

@ClaxonBerlin I spent some time playing with the Contour tool, but it only replicates the functionality of stroking a curve. The contour tools in CorelDRAW have some additional features, but even CD's contour is restricted to "stroking" an open curve. It might be a good feature enhancement request to ask for a CAD-like true offset curve capability with self-intersection trimming turned off. One side at a time, or both sides symmetrically. I can't think of a more direct way to do this in Designer other than the trick with shape builder you've already demonstrated. Maybe someone else will have another trick.

I suspect you've already got it, but since you asked explicitly a couple of posts ago, I will answer. The "offset curve" we've been referring to is the internal mathematical representation of the "side" of the stroke. And we've tried to be quite explicit that the "sides" of the stroke may require a different number (almost always more) of segments than the basic curve for the stroke. So, you can create a one segment curve in Designer and give it a non-zero width stroke, internally Designer will create other curves to describe the sides of the stroke. You can't directly manipulate those additional curves; they will never have nodes to pull in the UI. But internally, they certainly do have nodes and segments, defined mathematically from the basic curve for the stroke, the stroke width, and whatever treatment of caps, miters, arrow or other line ends is styled for the stroke. BTW, when you Layer > Expand Stroke in Designer, the basic curve for the stroke is replaced by the side/cap/arrow curves that Designer uses internally for rendering the original stroke. If you do that to a stroke with an arrow head, you can see that the arrow head is drawn separately. If you do it to a curve whose stroke overlaps itself, you can see the trimming of self-intersections (of the rendered fat stroke, not necessarily of the basic curve for the stroke). Regarding "any indication that any part of them is removed internally". Well, let's put it this way. They clearly, obviously, visibly are not rendered in their entirety. Self-intersections are detected, overlapping sections are trimmed, and the selection of pixels to be painted as part of the stroke is based on those trimmed sides. Redundantly filling in sections of the stroke which overlap (painting pixels multiple times) would barely be acceptable as an introductory student programming exercise. No commercial software does that; they all figure out what the cleaned-up version of the stroke looks like before rasterizing it (painting its pixels on the screen). Minor exceptions like drawing arrow heads or other line ends separately from the capped&mitered stroke are routine.

R C-R, ClaxonBerlin is being quite clear and you've either missed his point or are being unnecessarily pedantic. CB clearly understands the difference between the stroke itself and the offset curves created mathematically from the stroke. Internally (Affinity, Adobe, whoever, makes absolutely no difference), the offset curves consist of a number of segments which generally do not match the segments of the base stroke. They cannot. The offset curve of a Bezier curve is (in general) not a Bezier curve, so the offset curves have to approximate the true offset curve as a series of Bezier segments. While there may be some internal optimizations, rendering a stroke with width is essentially the same as generating a pair of offset curves and applying the appropriate caps. Minor tweaks for miters at sharp corners. So, a sufficiently fat stroke is going to have the left and right sides of the rendered area defined by sequences of Bezier curves, even if the base stroke is a single curve segment. The base curve for the stroke, the left side and the right side may all have different numbers of Bezier segments. Fortunately for all of us, the math for this is all managed internally to the app. Where CB may or may not be correct, depending on mathematical internals of the Affinity suite, is assuming that the full offset curves are generated and then trimmed at self-intersections. It's possible to do some optimizations so that offset segments known to be fully inside the contour are not actually generated.

I endorse this request. It's not at all unusual to have both footnotes and endnotes, or to have a general bibliography and also a set of cited references (both of which would be usually treated as endnotes). The basic concept of the request (allow multiple independent streams) also applies to things like indexes. It's not that unusual to have an index of dramatis personae together with an index of terms, or to have an index of mathematical notation separate from an index of terms. When Affinity introduced *notes, I would have preferred that the generated stream be directed to a sequence of text frames of the user's chosing. This would have allowed greater flexibility at the cost of requiring the user to deal with "note on same page as annotated text" issues. If/when multiple note streams or multiple index streams are introduced, allowing the user to direct each stream to a user-selected text frame sequence becomes even more important, because there simply aren't such standardized use cases to pre-program in the multiple streams case.

Yes, yes, yes. Applying all character properties (font, size and color) through named text styles should be routine for even the most trivial Publisher document. Users of Designer may not be familiar with that practice. But this is the right way to do it. If you have a "ransom letter" with every snippet of text cut from a different source, then setting things up with distinct text styles is perhaps impractical. Find/Replace does give you a fallback to changing to pure-black without changing the other character properties.

I have a few Table Styles defined, and most of the time, when I apply a table style to a newly created table before entering text, when I manually type in text it gets the styling appropriate for that particular range of cells. Cut-and-paste usually does not respect the table styling. Unfortunately, sometimes it does not (or does) work unexpectedly. I've never figured out the reason(s) why.

Layout (Publisher) of heavy math/tech articles with embedded floating graphics (Designer) instead of separate display blocks. I don't use Photo much. On occasion, I have to go back to CorelDRAW or one of my 3D apps for something Designer can't do.