fde101

Assuming this chart was a PDF file that you inserted, make sure that the original font that was used to create it is installed on the computer running Publisher. The changes that you are describing can happen with a font substitution, and Publisher does not currently support making use of fonts that are embedded into PDF files, so if you don't have it installed, Publisher substitutes a different font (all of the Affinity suite products currently have this limitation).

Apologies, I misread something and somehow associated some of this with discussion from a different thread. I was reacting to some of the suggestions that have come up that would have tried to make all swatches into global colors - THAT would be a problem. Yes, it would, assuming you actually meant the swatches panel.

I believe that is the opposite. That is to make the text ignore ALL objects that might otherwise ask it to be wrapped.

This is usually a preference that can be disabled as it takes up additional resources on the system to maintain all of the separate icon previews - also the generic document icons will sometimes show up for a short time until the previews are rendered. The current Affinity beta ones with the big squares are particularly large and obtrusive and I agree that they should be wrapped into proper document icons. Very nice... assuming we are stuck with the flat boring square application icons this is a great example of how the related document icons should be done.

This has been discussed already in other threads. The current layer structure is inherited from the other products (Affinity Photo and Affinity Designer) which use the same file format as Affinity Publisher so this is not likely to change (I certainly hope it does not as it is exactly what is needed in the other programs), and the current structure does work VERY well for what it is though it may not be what you are accustomed to from other layout software and is a solution for a different set of problems than the type of layer you are requesting. The Affinity team is aware of the need for what we have come to refer to as "global layers" in Publisher and they have indicated clearly that they do plan to implement such a feature but it is unclear to the rest of us if this will happen in 1.7 or not - it might come in a later update.

Adobe is not trying to maintain a consistent file format among multiple applications. The type of behavior you are pushing for in Publisher would be a nightmare for Photo and not really all that wonderful in Designer either, at least not for some use cases. Trying to maintain behavior like this would very likely be a source of confusion when shuttling files between the applications. I'm all for coming up with ideas to improve the products, but make sure you are considering questions such as: Will these actually be improvements for all three programs, not just Publisher? Will they be flexible enough to support any other programs that might be added to the suite later on? Will these changes impact compatibility with importing older files from Photo and Designer as they already exist?

Also make sure you didn't rename the retail version.

I would not expect it to do that, no... but then, neither will Affinity Publisher, at least not yet and possibly not ever.

That is one issue that would come up, yes. If you don't need the other types then don't use them. There is no rule saying that you must use every feature of the program on every project. I do agree that it would be nice to be able to directly copy swatches from one document to another (copy+paste). As to copying a layer from one document to another and having an associated global swatch follow it, while I like the idea in general, I can foresee a possible complication here in defining the behavior of this feature. If you have the same global color assigned to multiple objects in document A and you separately copy several of those objects from document A to document B, do they become as many copies of that global color in document B? How would Publisher know to match it up so that they were still sharing the same one in document B? Also, if both documents had a global color named "cool color" and they were two different colors, would you wind up with two global colors named "cool color", would the "cool color" in document B get replaced by the color from document A, or would the layer being pasted into document B be conformed to the color already assigned to "cool color" in document B? Those are all potentially valid behaviors and each of them could be advantageous over the other in different situations... it might be nice to come up with a reasonable way to incorporate more than one of them somehow without cluttering or over-complicating the interface. A preference might actually be sufficient... [X] When pasting layers with global colors from another document, copy the global color also If there is an existing global color with the same name in the destination document: (*) Conform the pasted layer to the existing color in the destination document ( ) Use the existing swatch if the color matches exactly, otherwise create a new swatch with a duplicate name ( ) Create a new swatch regardless, giving it a unique name ( ) Update the existing global color to use the color from the source document

Duplicate the existing document then remove what you don't need.

+100 to this.

I would not expect this in the initial release, but I would certainly hope this would come about at some point down the road.

There is no hierarchy here of any kind - you seem to be treating this as being more complicated than it actually is, and trying to implement suggestions like supporting global colors in application palettes or copying the swatches over to a different document along with an object would generally make things more confusing rather than less. There are only two types of color swatches: Global colors are linked together so they can be changed in one place. Non-global colors are copied to the objects they are used on rather than being linked. It is the difference between the assets panel and the symbols panel in Designer: When you drag in an asset you get a copy; when you drag in a symbol it is linked. Global colors act more like symbols while non-global colors act more like assets. Assigning colors from non-swatch sources (such as the color panel) works more like non-global swatches. Application and system palettes can only contain non-global colors, for reasons already outlined above. Document palettes can contain both types. The concept of renaming to "document color" ignores that non-global colors can also be included in document palettes.

If the software kept track of whether or not the user had renamed the color then the name could easily be one that was selected to match the color up until then, but you would still wind up with people renaming them to things like "19-4150 - sidebar text" after which they would get out of sync. Obviously that would still be possible with what I am suggesting, but there would be less reason for the redundant inclusion of the color in the name, so if people still did things like that they could only blame themselves for the confusion.

I don't much like the idea of having a global color automatically named to match the color itself. Instead I think the actual color (pantone number or RGB/CMYK/etc. value) should be listed next to the name, or underneath it, when displaying as a list, or in a tooltip for when the display format doesn't allow that. The reason is that global colors can be changed. If a different color is assigned to the global color, and that color name is used as the name of the global color, then you need to change the name to keep it in sync, but if someone renamed it to something more meaningful (ex. "sidebar text") then having the program automatically change the name of the global color would wipe out the more contextually meaningful name that was given to the color. Having it try to detect when the name should be changed is kind of dicey - if I picked pantone color 19-4150 for my sidebars and named the color as "19-4150 - sidebar text", then the auto-detection might not be smart enough to figure out how to update that... as different people could wind up using different formats ("sidebar text (19-4150)", "sidebar text: 19-4150", etc.). Keeping the actual color separate from the name but still making it visible would be the more ideal option.