sfriedberg

Do not use a dictionary as an authority on proper names. That's not a purpose of dictionaries. Consider Smith and Smythe. It is not an error for someone to be named John Smythe in America. It is not an error for someone to be named Vaclav Havel in America, but you will not find either "Vaclav" or "Havel" in an English dictionary, American or Commonwealth. It is not an error for some place in New York to be named Centre Street, Canandaigua, Skaneateles, Owasco, Otisco, Oswego or any other such thing, and you won't find those in American dictionaries either. Do not use a dictionary as an authority for proper names. For places, use a gazeteer. For people, there is no single authoritative list (in most countries), but there are public records considered authoritative for individuals. Neither of those is a dictionary. If you apply a dictionary in a word processing application, it will mechanically flag everything that isn't included in the dictionary. That's how a dictionary handles proper names: inapplicably. It is up to a human being to understand, from context, that the red squiggly underline is not relevant because the dictionary has been misused, because the word processing application does not understand the concept of proper name. This is all stuff that used to be taught in high school, if not grade school. The facts that computer applications are not as sophisticated as bored 12-year old humans, and blindly pushing everything through a single mechanical filter is not a correct solution to every problem, seem to have been overlooked somewhere.

Yes, there are few things more frustrating than to do a web search for a solution to a problem, only to find the thread/discussion ends with "Never mind, I solved my problem."

This is true, but ... 1) I've never worked on a significant project that didn't involve about 10% of pages affected by edits after initial layout, and 2) "You do it right the first time" becomes an excuse for application incompetence at things as basic as reflowing text. (viz Scribus!)

If we ever get the ability to concatenate separately laid out sections into a composite document ("book assembly"), this sort of problem will (have to be) solved. In each separate section document, it will be clear which master page goes with which content, and that's not going to "slip" when sections are assembled into a larger document. (Let me rephrase: if it does slip, it's an epic and massive failure.)

While "pinning" master pages to arbitrary points in the text flow doesn't seem like a great idea to me, being able to pin a master page at the start or end of a section does, as sections are divided on page boundaries. So if section/chapter N expands, the chapter heading master page for section/chapter N+1 stays with the first page of that section, not someplace near the end of the previous section.

I suspect it would be easiest to start with a photo of a solid color garment. You say you already know how to do color replacement, so presumably you can mask the replacement area and capture the shading (illumination and shadow) details of the solid color area to reproduce on the replacement color. You can replace a solid color with a pattern fill in essentially the same way. However, there is one big difference, which cannot be automated. Consider a pattern of stripes, which run vertically on the garment. Simply replacing the original solid color with a pattern fill is not going to orient the stripes properly on each part of the garment. Besides seams on the actual garment, there is the rotation and perspective transformation inherent in the photograph, and also things like folds, wrinkles, and drape in the original garment as photographed. In principle, you could segment your photograph to identify mesh transformations on various patches which would map from your pattern fill to properly scaled, oriented, and projected replacements. You'd do that once, and then you'd be set to replace the original image with any number of different pattern fills. But I don't believe the Affinity suite has sufficiently powerful mesh transformation tools to do that job, and it certainly doesn't have any tools for automating the creation of such transformations.

This is by no means one of those "absolutely essential must-fix immediately sine-non-qua, how could you be so stupid!?" issues that the forums seem full of these days, but I would like to report a persistent irritation with Affinity Publisher. Suppose I have a Body paragraph followed by a Heading1 paragraph. The formatting for the Heading1 paragraph text style is quite different than the Body paragraph text style, different font and font size, etc., etc. While I am editing the Body paragraph, I inadvertently remove the paragraph mark between the Body and Heading1 paragraphs. The content for Heading1 is now concatenated with the content for Body, but the character formatting based solely on the properties of the Heading1 paragraph text style is preserved. Now I notice what I have done, perhaps after another couple of keystrokes, so I plant the cursor between what should be two paragraphs and hit return. It now appears that I have restored the original situation, but I have not. I now have two Body paragraphs, one of which has character formatting overrides so it looks like a Heading1 paragraph. If there is a defect here, it is in transferring the paragraph style properties of the Heading1 content as character formatting overrides within a Body paragraph. Returning to the original scenario, I would much prefer that when the paragraph mark between a Body and a Heading1 paragraph is removed, merging the two paragraphs into a single Body paragraph, that the content formerly in the Heading1 paragraph is reformatted as Body content. Because it now is Body content! This would make it clear that I need to not only separate the two inadvertently merged paragraphs, but also restore the correct paragraph text style for the 2nd one. If there are also character formatting overrides to the paragraph style formatting before the merger of the two paragraphs, I do not object if those overrides remain. My peeve is about the transformation of pre-merger paragraph style properties into character formatting overrides. No doubt this was thought by someone to be "helpful to the user", but it is just about my largest day-to-day annoyance during text entry and edits. And just to be painfully and abundantly clear, there is nothing special about "Body" and "Heading1" in this example, except that they are two distinct paragraph styles with notably different formatting.

Echoing NNN, there are definitely times when I would like to base one style on another with the subordinate style's font size a proportion of the base style's. In other words, the base style might have font size 16 points, and the subordinate style might have font size change 75% instead of 12 points. That way, if I change the font size on the base style, the subordinate style will auto-adjust. Right now, if I have a sub-hierarchy of 20 styles and I want to change the overall font size, I have to manually change every style that overrides its inherited font size. If I could specify font size overrides as proportions, I'd only need to change the style at the top of the sub-hierarchy. In another thread, I gave an example where I have a collection of 18 character styles to handle subscripts, superscripts, sub-superscripts (etc.) in several different fonts (math, body, etc). So this is not a completely theoretical problem! However, I think this should be a feature of the paragraph and character styles system, not a document preference!

You don't need hierarchical sections to get running heads to follow multilevel headers (basically what would appear in TOC entries). Lest you think I am opposed in any way, no. We really do need the ability to assemble books from parts laid out in separate documents, and sections certainly seem central to that. And we really do need the running heads. I'd judge that Publisher's weakness in fields and references is more of an obstacle to running heads than the absence of hierarchical sections, though. In Ventura Publisher, there were various fields for (multilevel) header contents that appeared on a page, and that's what we used for running heads.

There has been a small bit of discussion in other threads about concatenating multiple external texts into a single series of linked text frames, and conversely, splitting one internal text flow into two or more unrelated series of linked text frames. Managing how external text files map to and from internal text flows can be quite complicated. One user might want the content of the external files to follow the internal arrangement automagically, while others might insist that Publisher never alter any linked external file.

There are a variety of use cases and work flows, and I'd like to highlight three in particular. 1) The simplest case is when the external text flow is just key strokes (code points). For a long time, this was how publishers wanted to receive manuscripts from authors, and is still very common for magazines to ingest article content. The author might insert some typographic notes inline, but the import process takes no notice of them. The layout person would be entirely responsible for applying any styles called for by such notes. 2) The more capable case is when the external text flow is marked up. In particular, spans of non-default paragraph and character styles are explicitly tagged. This is appropriate for repeated export/external-edit/importcycles. It is also appropriate for ingesting content from a CMS or similar database. It is also appropriate for drag-and-drop or copy-and-paste from other work processing applications such as Microsoft Word. There are two variations I'd like to mention. The first and quite limited variation requires the text flow tags to exactly correspond with styles already defined in Publisher. The second allows the use of something analogous to an XLST stylesheet (does not need the full complexity, just tag transformation!) to transform between external tags and internal styles on import/export. Ideally, tags which are not known to the existing import stylesheet would prompt an interactive dialog with the user, similar to the font substitution dialog, where the missing transformations could be added (including the addition of new internal styles). Even better, there should be support for multiple import/export stylesheets, so that content exchanged with different authors or CMSs can be managed conveniently. 3) If and when Publisher acquires a plug-in architecture, external text flows must include content intended for interpretation by plug-ins. I.e., if it is possible to use a LaTeX or MathML plugin to write math expressions in a Publisher text flow, then the input text for the plugin must be preserved on export, and external text tagged for the plugin must be passed to the plugin on import.

@Sclong137 Whatever your machine is, it's got some kind of graphics hardware even if it's not a separate plugin card. If you are working at modern screen resolutions, we can assume you've got something better than VGA hardware. Unless Affinity Photo is offloading layer compositing to the graphics hardware, even the most minimal modern graphics hardware is not going to be the bottleneck. So, "No, you probably don't need a separate graphics card, and you certainly don't need a fancy graphics card with hundreds of shader units and Gigabytes of on-card dynamic RAM." Affinity have not made clear exactly which features are enhanced by "Hardware Acceleration" and "HA support" is complicated by the need for specific OS support (for API features) and video card driver support (for actual functionality). So I cannot be absolutely certain of my answer. But since you did not get a direct, explicit answer from Affinity, you can try mine.

I am of mixed opinion, but lean toward "this is useful for people doing commercial work". The big question is what priority does Serif place on professional, commercial layout? These days, signature imposition is probably best dealt with by a dedicated app that takes a PDF of single impression pages. However, there are several cases where the page design is influenced by the spread, and those situations should really be accommodated by Affinity Publisher/Designer. One recurring example requested here on the forums is book cover design, where a three-panel spread with non-equal panel widths is appropriate. Less often requested, but closely related, is book dust jacket design, where a five-panel spread, typically with three panel widths, is called for. Certainly, books are not a novelty item of limited general utility, so this particular case should get some attention. Packaging (box) design is another common and important commercial activity. I suspect, though, that this is best handled by getting a developed (flattened) template from the box maker, and using that template as a guide in Affinity Designer, especially as the canvas can be rotated to bring text under development properly oriented on the designer's screen. I'm not sure that the concept of publishing "spread" really works that well for 3D items like boxes or other polyhedra.

That is very surprising. And encouraging.

I'd like to contrast the Affinity user community with the (McNeel Associates) Rhinoceros user community. (Rhino is a highly functional 3D CAD program where a new commercial license costs about US$1000.) Rhino has a fully open development process, with preview releases through the lengthy development process between major releases. Rhino generally does not issue formal minor releases, and only the major releases are supported. During the development process there is a lot of discussion of desired features, experimental features come and go, feedback and bug reporting, and so forth. That is common with the Affinity experience. What you do not get in the Rhino forums is people wailing about how their particular wishlist feature is absolutely essential, that McNeel Associates must be stupid for not doing things exactly the way they want and in exactly the order desired, bitching and moaning about how "We been waiting years, decades, centuries, millenia for this. Why can't you give it to me right now?!?!" You also do not get people flaming about how "this software is an overpriced pile of shit", despite Rhino customers paying 10X what Affinity customers pay for a license. You also do not get people screaming their heads off because a feature tentatively proposed for year+quarter didn't make it (due to unexpected difficulty or insufficient resources) and you especially do not get people bitching because some feature they didn't want got delivered earlier than some feature they did want. I'd just like to point at a recent Affinity forum thread title "Is Affinity Designer even developed anymore?" This is just such a petty, petulant, short-sighted, peevish jab at Serif. And all too typical of too many forum members.

@michacassolaEarly in the life of the Affinity suite, Serif did provide some information about their intentions and roadmap. However, the user community was so abusive about 1) the relative ordering of features, and 2) any failure to deliver a feature at some tentatively proposed date, that they have deliberately ceased to provide any roadmap information. You now get an announcement of features when they are released, not earlier. I can't see Serif changing their minds until substantially all of the user community grows up, which means never.

While I won't claim the Affinity help files and online manual are great, some of those questions are answered there. First of all, that list of "Apply ..." options has nothing at all to do with editing a style. They have to do with applying the style, as currently defined, to your content. The names of the options are, well, unfortunate. I recommend you read the help page titled "Using text styles", because if I tell you what they mean, you will disbelieve. "Update 'Body Text' " is going to modify (edit) the style to match the currently selected content.

They could still put a border around the asset space, which is what was requested in the original post of this thread. And they could be somewhat more expansive about "mode colors", for example, using checkerboard to indicate transparent areas instead of the mode default background color.

+5 The Assets panel has the same issue, with much worse consequences because assets themselves can be nearly invisible (obviously, this depends on the specific assets!), unlike the picture frame icons.

I'm with Old Bruce. Define the styles using Text Styles, where both character and paragraph styles (as well as groups, which need not concern us now) can be defined. Apply ad-hoc overrides to particular spans of text using the Paragraph and Character panels. If there's a particular ad-hoc override you are using a lot, define a Text Style for it.

@GeorgiiYou can convert text to curves, also "shapes" (like rectangles and stars) to curves. And, speaking as a (part-time machinist), nobody is turning letters on a lathe. Possibly on a milling machine. Definitely on a plotter, vinyl cutter, or CNC router.

1.10.0.1109 (Beta) fixes this problem for me.

This does fix the inline pinned object problem for me.

Oh, good. I had pointed out similar/same issues with pinned content at the top of the page in the original 1098 announcement thread and was getting ready to start a new thread on the topic, since I hadn't spotted an acknowledgement. Glad it's known!

Do you have any adjustments active? That looks somewhat like a local contrast enhancement, or a sharpening operation (perhaps unsharp mask) gone large.