Mark Oehlschlager

I love the new Pattern Layers but I have a few requests: Please re-design the Pattern Layers in such a way that one can drag vector and pixel layer art into the Pattern Layers as scalable and re-positionable child layers. That would offer a quicker and more intuitive way to build patterns. Make it possible to export the finished pattern tile as a separate file/asset. Bring Pattern Layers to Designer. Thanks for your consideration.

Awesome. Thanks for fixing the crash upon launch problem from beta 219.

LOL. This thread took a wild tangent.

@thomaso Well, Designer and Photo deal with single page/canvass/artboard compositions, whereas Publisher is designed to deal with book forms of multiple, continuous facing pages. Presently, Publisher adopts the very same "Page/Artboard Layer" model that Designer and Photo use (i.e., a page-specific layer). But if Global Layers were introduced as an option from the Layers Panel within Publisher, how would Designer and Photo interpret them? I suppose that if one were using Studio Link in Publisher to just pop into Designer or Photo persona for a quick edit, it should be possible for those applications to understand and respect the Global Layers without converting them to "Page/Artboard Layers". If Serif were to introduce Global Layers across the entire suite, how would they behave in Designer and Photo? Would they automatically appear on all artboards in a multi-artboard Designer/Photo file? Also, I've asked this question above, but how would Global Layers in Publisher be handled in the Master Pages? It strikes me that there's a conflict in the way Publisher is currently designed. One could easily implement Global Layers for the document pages in the Layers Panel, but then they would exist outside of the Master Pages. Maybe that's acceptable? Also, how would all of this impact the ability for Publisher to import/export IDML files?

@Jeremy Bohn But, because of the integrated nature of the Affinity Suite and the common file type architecture, Publisher would need to understand and respect the conventional "Page Layers" or "Artboard Layers" from Photo and Designer, while Photo and Designer would need to understand and respect the new "Global Layers" from Publisher. That would be the design problem for the Serif developers. Adobe could afford to have different layer models for InDesign and Illustrator or Photoshop because those apps were never designed to share the same file type.

@sfriedberg One thing that worries me is that the shared file architecture of the entire Affinity Suite would make application-specific features like Global Layers in Publisher difficult to realize. Granted, I'm not an application developer. As a layman, I can imagine the Layers Panel offering the option of adding either a Page Layer or a Global Layer. (And Maybe that can be done without breaking things in Designer and in Photo.) But then would those Global Layers appear in all Master Pages by default?

This is an aspect of the Adobe model that can be restrictive. On occasion, I've wanted to add a page specific item to a document that didn't really conform to the Global Layer stack schema, and then one is forced to either add the item to an existing Global Layer, or to introduce a new Global Layer for that one, page-specific item. I think a case can be made for the existence of both "Page Layers" and "Global Layers" created and managed from within the Layers Panel.

Presently, one can add empty container layers (i.e., not object or text layers) from the Layers Panel, but these layers are properties of individual pages. Would it be possible (without mucking up the architecture of the Affinity Suite) to be able to add document-wide Global Layers from the Layers Panel? In this conception, Master Pages would offer repeatable but page-specific page composition schemas (not necessarily applied continuously or document-wide), Layers (as currently defined, and what might be called Page Layers) would offer Page-specific object containers, and Global Layers would offer document-wide containers for organizing types of content that need to be switched on/off globally (e.g., alternate texts in a multi-lingual document). Global Layers would always preserve their stacking order relative to each other, but otherwise, for each spread, the user could freely arrange the stacking order of applied Master Pages, Page Layers, and Global Layers. See screenshot illustration below.

@thomaso The chief use case for Global Layers is setting up multi-lingual documents, where each global layer carries the text of one language and the visibility of the language layers can be turned on or off. Can this even be achieved using master pages in Publisher? I don't think that one can toggle the visibility of master pages on/off globally with one click. As far as I can tell, Publisher would require one to set a publication in Language 01 (e.g., English), then duplicate the finished document and replace all the threaded Language 01 stories with Language 02 translations, and make final copy fitting adjustments.

Allow me to add an addendum to the list of feature requests: Sort out the inconsistent UX behaviors when selecting a swatch from any of the Pantone swatch libraries, and give the user control over to which user defined palette a Pantone swatch should be copied. Presently, this is what happens: When a user clicks on a swatch from a Pantone color swatch library for the first time – even when the user has created one or more named document color palettes (e.g., Primary Colors, Secondary Colors, Accent Colors) – the Affinity application will automatically generate a new document color palette titled "Document" and place a copy of the Pantone swatch there rather than ask the user where he/she would like to place the copy of the Pantone color swatch. Subsequently, when a user clicks on additional swatches from a Pantone color swatch library, a copy of that color swatch is not placed in any document color palette – neither the user defined document color palettes, nor the auto-generated document palette titled "Document". The Pantone color simply fills the color well above, requiring the user to then switch palettes and to use one of the "Add color to ..." buttons to add the color swatch to a palette. Give the user the ability to copy / move a color swatch from one palette to another. If I have two or more user defined palettes (e.g., Primary Colors, Secondary Colors, Accent Colors), I want a convenient way to right click on a color swatch in one palette and choose a command to move or copy that color swatch to another user defined palette. Presently, one has to do this in three to five steps: 1) select swatch in Palette 01 to fill color well; 2) switch color palette selection to Palette 02; 3) click one of the two "Add color to ..." buttons to add the color swatch to Palette 02; 4) switch the color palette selection back to Palette 01; 5) right-click on the original color swatch to delete it from Palette 01. Give the user the ability to duplicate and reclassify a user generated palette from one type to another (Document / Application / System). Presently, the only way to manage this is a multi-step process: 1) export the user defined Application Palette, "My Colors"; 2) import the exported "My Colors" color palette file as a Document Palette; 3) delete the original "My Colors" Application Palette. There is a ton of room for innovation and improvement with regard to color palette building, selection and management. I would encourage the development team to take this on as a project. Start thinking through the problem of creating and curating project color palettes as a designer or artist would. Make the tools and interface support a creative, intuitive and frictionless work experience. Thank you.

Bumping this because it's still relevant. And I would add the following: the UX behavior for any "new item" command (e.g., new swatch, new palette, new spare channel, etc.) should automatically present a naming dialogue box so that one can create and name the new item in one fluid motion. double clicking a color swatch to edit its properties should allow one the opportunity to change all properties (color model, color numbers, spot vs. process, overprint vs knockout) when a color swatch is defined as a spot color, and/or as an overprinted color, the symbolic swatch markings that indicate spot and overprint should display wherever in the interface that the swatch palette is presented (i.e., not just in the main swatch panel, but also in all of the contextual presentations of the swatch panel, like the tool bar and all of the adjustment and effects layers.

@Chris B I'm running Mac OS High Sierra 10.13.6, so the Windows beta won't work for me.

Quick report that the latest beta for Affinity Photo (1.9.1.219) crashes upon launch.

@walt.farrell Clearly an oversight on the Mac side. This is the hazard of trying to develop software for multiple OS platforms.

One of the supposed new features of Designer 1.9.0 is the ability to customize the color of the bleed guides. You're supposed to be able to see a color chip under the Bleed tab in the Document Setup dialog box, but I don't see such a color chip on the Bleed tab. Am I missing something, or is this a bug? I'm running on OS X High Sierra.