Bit Dissapointed

There's a small linguistic issue in the character panel. I suggest "Hide unsupported features" instead of "Hide irrelevant features". It's all about the semantics. If the intention is to remove features that cannot be used due to technical constraints, "Hide unsupported features" would be more accurate. However, if the purpose is to remove features that are not relevant to the user's current work, even though they are technically supported, then "Hide irrelevant features" is more appropriate. But that is not the case, eh?
"Hide irrelevant features" suggests that the program will conceal OpenType features that are not relevant to the current text or font. This implies a focus on the user's context, hiding features that, while technically supported, are not applicable or useful in the current situation. For instance, it might hide features specific to different languages or scripts that aren't relevant to the user's current task.
"Hide unsupported features", on the other hand, indicates that the program hides features that are not supported by the current font or the text processing software. This is a more technical approach, referring to the limitations of the software or font, rather than the relevance to the user's task.
In return, this option evidently appeared to be irrelevant for mention in the online help. 🫥

This comes from a different suggestion on the forum, but it got me thinking... would it be feasible to add in an additional Layer type that forces grid-alignment of contained pixels/content?

Or, an Artboard that can have this attribute enabled (something that can be enabled on Document Creation, allowing pixel-precise/bitmap precision). So, someone who works within will always have pixel-alignment... and that could be very useful for many creative purposes (as well as make us pixel precision nuts happier)... it could have Layer resample methods but perhaps other adjustments that allow for the expression of said output to be defined by the user. Having this alignment handled by a specific Layer and then adding unsharp masks and other Live filters could be a highly desired feature...

It alleviates so much of the work of making sure Layers are pixel grid-defined and that a user can also creatively control the final output once their designs reach the "flattened" stage. ie There shouldn't be much if any change specific as far as the Rasterized appearance once that file is output to a PNG, etc... just a thought.
 
Also, another feature to embed into this functionality is to take advantage of any data in Font files, etc, to add the clarity of typography by default... that gets around the need for a drop-down PS style that allowed for pixel-grid related filtering (Sharp, Smooth, Crisp, Windows LCD, etc...)

*This also gets around the complaints about blurry output because while the Layers/contents underneath still remain vector, the blurring/seams will be apparent at this stage, and thus fixable...

There's a small linguistic issue in the character panel. I suggest "Hide unsupported features" instead of "Hide irrelevant features". It's all about the semantics. If the intention is to remove features that cannot be used due to technical constraints, "Hide unsupported features" would be more accurate. However, if the purpose is to remove features that are not relevant to the user's current work, even though they are technically supported, then "Hide irrelevant features" is more appropriate. But that is not the case, eh?
"Hide irrelevant features" suggests that the program will conceal OpenType features that are not relevant to the current text or font. This implies a focus on the user's context, hiding features that, while technically supported, are not applicable or useful in the current situation. For instance, it might hide features specific to different languages or scripts that aren't relevant to the user's current task.
"Hide unsupported features", on the other hand, indicates that the program hides features that are not supported by the current font or the text processing software. This is a more technical approach, referring to the limitations of the software or font, rather than the relevance to the user's task.
In return, this option evidently appeared to be irrelevant for mention in the online help. 🫥

Just to explain for others, ID's index feature provides options to capitalize all level 1 topics, all topics, the selected topic, or the selected topic and its subtopics.
Doing something like that might be easier than creating a new formatting attribute that could be added to a text style.
I know I wrote in your other thread that it couldn't be done with Publisher 2.3 (https://forum.affinity.serif.com/index.php?/topic/197291-a-few-questions-about-formatting-an-index-in-publisher/#comment-1163617) but I thought of a workaround. There are so many features in Publisher that there's usually some way you can hack it to do what you want.
Create a character style with All Caps enabled Edit the Index Entry 1 paragraph style with Drop Caps enabled and with Height set to 1 line, Characters set to 1, and Style set to the all caps character style you just created A drop cap set to 1 line high and 1 character wide is just a regular character, and the all caps character style takes care of capitalizing it.
If you also wanted your level 2 headings capitalized then just repeat #2 for Index Entry 2.
Cheers
 

You are here:

While I am here:

Hehe, yes, maybe that should be my alias. But on the subject, I work with a company that supplies products to us. One of the leaders, who is an outstanding and esteemed leader, tells his teams: 'You are allowed to make mistakes, but you must not make the same mistake twice.' Of course, we are not talking about tiny errors here.
When companies consistently make the same mistakes against all trends, knowledge, and feedback, I see no reason to phrase myself as a subject before a king. For when things are going poorly, it's not up to me as a customer to motivate the company. It's the circumstances and shortcomings. And here, the many fanboys surrounding the mythical 'devs' as tribal chiefs and at the same time casting a smokescreen over those who genuinely need the product to improve, do not help.
If there's one thing that has benefited my career and professionalism, it is that I have listened and adjusted to the wishes and criticisms of customers and colleagues. I am used to criticism of any kind, and occasionally I have spent days understanding that the criticism or desires for change were justified. I simply had to view the problem from different angles, listen, and gather more facts.
I have long since grown beyond focusing on the form and more on the content, whether the feedback is good or bad. My impression of Serif is that they also handle honest discussions well. And that's how it should be, so I can express myself in a way that makes my joy or frustrations clearly visible. Notice that it's the users here in the forum who are thin-skinned, not Serif.
I also like Designer, but I'm tired and frustrated by the mistakes Serif keeps making against all known knowledge and feedback, year after year. Clearly, I'm not alone in this perception.
By the way, you are not described, either indirectly or directly, in the above. 🙂

I really like Affinity apps.
But whenever I use them I feel like I’m constantly being tricked / trapped by them. 

I work on a file then save or export and the location inexplicably defaults to the last location of save or export, not the location of the currently open file.
It’s a topic that’s been discussed at length here over the years. But I simply hate the current behaviour. It causes stress. It causes data issues. It causes embarrassment. It causes extra work. It’s entirely unnecessary. It’s terrible customer service  
All because someone at Affinity has a somewhat bizarre idea about how save dialogues should work that’s different from every other app. 
It’s just not good enough. Sort it out. I’m done with waiting patiently. 

Hehe, yes, maybe that should be my alias. But on the subject, I work with a company that supplies products to us. One of the leaders, who is an outstanding and esteemed leader, tells his teams: 'You are allowed to make mistakes, but you must not make the same mistake twice.' Of course, we are not talking about tiny errors here.
When companies consistently make the same mistakes against all trends, knowledge, and feedback, I see no reason to phrase myself as a subject before a king. For when things are going poorly, it's not up to me as a customer to motivate the company. It's the circumstances and shortcomings. And here, the many fanboys surrounding the mythical 'devs' as tribal chiefs and at the same time casting a smokescreen over those who genuinely need the product to improve, do not help.
If there's one thing that has benefited my career and professionalism, it is that I have listened and adjusted to the wishes and criticisms of customers and colleagues. I am used to criticism of any kind, and occasionally I have spent days understanding that the criticism or desires for change were justified. I simply had to view the problem from different angles, listen, and gather more facts.
I have long since grown beyond focusing on the form and more on the content, whether the feedback is good or bad. My impression of Serif is that they also handle honest discussions well. And that's how it should be, so I can express myself in a way that makes my joy or frustrations clearly visible. Notice that it's the users here in the forum who are thin-skinned, not Serif.
I also like Designer, but I'm tired and frustrated by the mistakes Serif keeps making against all known knowledge and feedback, year after year. Clearly, I'm not alone in this perception.
By the way, you are not described, either indirectly or directly, in the above. 🙂

I fully understand your frustration. I'm fortunate enough to have Photoshop in my toolset, so I don't encounter this image-pixel issue in Photo, which recurs over and over again. I remember it all too clearly.
However, I'm afraid that Serif has moved - and you who are affected by this totally opaque and almost uncommunicated difference - into really deep waters. The lack of automation and usability is a huge problem here. Automated conversion will probably be just as extreme. I think that Serif needs to embark on a really UX-driven rethinking of concept and user interface regarding image and pixel layers.
I remember - and occasionally discover in Designer - that many features require one thing or another to work - but don't communicate that when you try to perform an operation on it. The user interface is no help.
Apologists and fanboys defending this very theoretical construct are of no help either, nor is the need to learn the programs as if it were GIMP. It's incredible how people can so fervently defend a concept that has resulted in so many support requests here.
The most elementary mistakes are made right on the surface. I paste something into Affinity. The first term, image, doesn't suggest much. To transform it into pixels, I have to choose rasterize; now we're up to three terms the customer must fully understand how works in Affinity. Don't try to convince me that the small object type icon makes the customers significantly wiser. The very few visual hints are barely noticeable, while the textual is pure engineering jargon. "Convert to pixels" would be fine or "Render as Pixels".
This user interface and journey in Photo are not designed by genuine and professional UX designers. The architecture and user interface are cobbled together with elastic bands from the 80s.

You are here:

While I am here:

@loukash Yeah. One. Problem is that often I have need to bring into one composition say 20 different pictures. If I had to open 20 different pictures and then have to copy/paste 20 of them into one composition - its easier to place them and rasterize in mass. And the whole issue is - I dont want to be forced to additional, frankly unnecessary clicks for option I never need.
@Bit Arts - or should I say "Bit Harsh" 😉
I have Affinity from the very first day on PC. I really love using it and I have abandoned Photoshop for it didn't looked back. But this "image" thing is really driving me mad from the very beginning. And I understand that somebody, somewhere, somehow has use for that "image" thing. I honestly cant imagine single use for it in what I do. Not one. I will never need it it seems. All it does for me personally is annoying me. I dont want to take it away from those who find it useful but I would be so happy not having to put up with it. Option to choose. I even used to weirdness of "export" instead of "save as...". Although I still miss click at times  😆.
@Old Bruce I do appreciate help man, I know I could make shortcut. The whole thing is I would love to be able to avoid that completely useless for me "image".

I fully understand your frustration. I'm fortunate enough to have Photoshop in my toolset, so I don't encounter this image-pixel issue in Photo, which recurs over and over again. I remember it all too clearly.
However, I'm afraid that Serif has moved - and you who are affected by this totally opaque and almost uncommunicated difference - into really deep waters. The lack of automation and usability is a huge problem here. Automated conversion will probably be just as extreme. I think that Serif needs to embark on a really UX-driven rethinking of concept and user interface regarding image and pixel layers.
I remember - and occasionally discover in Designer - that many features require one thing or another to work - but don't communicate that when you try to perform an operation on it. The user interface is no help.
Apologists and fanboys defending this very theoretical construct are of no help either, nor is the need to learn the programs as if it were GIMP. It's incredible how people can so fervently defend a concept that has resulted in so many support requests here.
The most elementary mistakes are made right on the surface. I paste something into Affinity. The first term, image, doesn't suggest much. To transform it into pixels, I have to choose rasterize; now we're up to three terms the customer must fully understand how works in Affinity. Don't try to convince me that the small object type icon makes the customers significantly wiser. The very few visual hints are barely noticeable, while the textual is pure engineering jargon. "Convert to pixels" would be fine or "Render as Pixels".
This user interface and journey in Photo are not designed by genuine and professional UX designers. The architecture and user interface are cobbled together with elastic bands from the 80s.

I am rather fond of the theory that customers should not even make known their needs, so that Serif may remain blissfully unaware of the demand for a feature or a correction of a bug for their PRIORITISATION.
Oh, hold on... no, no, I do not like that theory. Not at all. 😡
But thousands of utterly trivial posts in this forum are, curiously enough, esteemed and meaningful? Well, that is also the manner in which matters are conducted in professional environments.
HALT! No, wait, that is not at all how things are done in professional environments. Not in the slightest.
So, yes, I am also a party interested in the fix of AF-1241.

Ok thanks for sending me those issues, this is already then reported and it is not new issue how can I see, so I don't understand how this could be seen by Affinity developers. They want we post issues on forum, but why then they don't fix this. This is a serious thing for me. 
I can only say that this is only issue with Affinity software and not related to monitor settings. And yes labels are also blurry. This is serious UI bug.
I am using latest Mac OS version Sonoma 14.2.1

Ah, it's not a new deficiency. It's an old deficiency. Then it is interesting if in the "by design" scenario, if we ask what considerations were behind not implementing it, we get in the answer "We didn't think about that".
Either that's the answer, or it's a small task with a time commitment that Serif will never subsequently prioritise. Probably a mixture. That's what we get with a small team and a cheap product - you run the risk of minor improvements ending up at the bottom of the backlog - if they make it to the backlog at all.
It's a pain in the arse when it's missing, because it really is easier and quicker to use than the click-click-click or value entry of the 90s.

Doth not 99% of those within these virtual halls agree that services and wares doth require coin? The lone percent receiveth ceaseless heed, as threads are oft refreshed by the ninety-nine who yet cannot sway that stubborn minority. The solitary percent, in turn, might well ponder, 'Is the labour, the leasing of business grounds, the electric glow, the water's flow, and materials within Nottingham, UK, of aught cost?' If yea, then their grievance holds merit. If nay, then...

I have been doing more testing and have discovered an environment that causes reproducible crashes. Tests were run in both 2.3.1 and 2.4 Beta with identical results. I tested with files created from long-standing templates of my own, current files not created from templates, and brand New files with Filler Text. The more recent tests were conducted after a reboot. My working environment is to have Publisher with a large number of open Panels displayed in my right-hand (physical) monitor, with the display and editing of my documents floated in my left-hand (physical) monitor.
Here are the results:
The right-click crash never occurred when documents were not floated to my left-hand monitor, but instead left inside the Publisher UI. The right-click crash usually, but not always occurred when the documents were floated in my left-hand monitor.

I have 14 years of experience alone working on projects where it has been a standing and absolute requirement that absolutely nothing is sent on to development or production or similar without being designed and approved by user experience designers. Before that, usability specialists were also involved, but now they are embedded in every project I'm involved in or interact with. This makes our product easy to use and results in very few returns. That alone is a lot of money and time saved.
I work with them, have lunch with them, evaluate with them, drink beer with them, discuss with them, witness their user tests, see their tools, methods and work processes. I stay close to them because I remember when they weren't there and the end products could not match the quality and usability we get today. Shivers. One thing I've noticed about them is that they are the most instinctively good listeners among my many colleagues and the least likely to isolate themselves in front of a screen under stress. Their task is to understand. Not to claim or assume.
And in addition to everything I've had to repeat in this forum too many times, they work just as methodically as the developers they work closely with. And I can reveal that all developers I've worked with have loved working with UXers because it gives them very clear recipes and architecture to work from, documentation, principles, style guides, consistency, order, processes, professionalism, and the product becomes easily maintainable just like with good coding principles. Everyone wins! And most importantly of all, these developers - and especially their leaders - say that through these specialists they gain knowledge about the customers' requirements for the product, knowledge about how it is used, in general a lot of knowledge they would otherwise not have. I would never hire anyone without that attitude. The company hasn't either. They do not want to be associated with poor quality and recruit directly to ensure that all employees understand that the company thrives on understanding.
The first beta of layer states gives me so many indications of what Serif lacks and what they're not doing in their work, that I can hardly believe it. Had it been a proof of concept, I would have been more at ease, but no.
Then you might ask yourself whether customers would object to the fact that the product developed according to the methods we work from is easier to use, more consistent, more accessible, contains fewer contrast errors and puzzles, and is intuitive to work with. Of course they don't.
The path to professionalism goes through professionalism.

Doth not 99% of those within these virtual halls agree that services and wares doth require coin? The lone percent receiveth ceaseless heed, as threads are oft refreshed by the ninety-nine who yet cannot sway that stubborn minority. The solitary percent, in turn, might well ponder, 'Is the labour, the leasing of business grounds, the electric glow, the water's flow, and materials within Nottingham, UK, of aught cost?' If yea, then their grievance holds merit. If nay, then...

Great - works on both Mac and and iPad without keyboard!

Please could we have the Colour Picker tool 'Apply to Selection' NOT be active by default the first time we use it with an Image Layer. I don't quite understand what this function is supposed to be for, but I'm finding that I'm often having to de-select it with Image Layers. When active, it causes some unexpected colour change results since when active on an image layer will immediately update the colour of the whole image.
It would be great if its status could be remembered but apparently it gets re-activated every time you add a new Image layer, and also seems to re-activate when switching between different images.

I'm sorry everyone for getting a little off topic. I'll try not to do that again. But I had to respond to the absurd accusation that what I wrote was not credible and that I was making a tirade without providing any facts.
Again
+1 for an option to turn on/off export peview in the export dialog. 

I agree that the discussion needs to get back on track, which is basically that the export dialogue is really badly designed in terms of architecture, performance and usability, so it would be welcome if customers could disable a bit of the problem, the preview, to start with. It must be within reach to implement.

I see I'm dealing with a fanboy.
Link to the article corrected. It was "Redesigned with you in mind: the all-new Affinity V2 UI" on Affinity Spotlight.
Blending of the background color of the text box with the panel itself↓

Inconsistent tab shapes when activ or hover. (Panel groups, panels - trapezoid shape vs rectangle shape)↓

Poor pixelated previews (Preset panel)↓

Different spacing beween value input and increase/decrease arrows.

@Pšenda I can do this all day long.

The entire interface of version 2.0 is a degradation from V1. A thorough redesign is no longer an option but a necessity. 
Incredibly poor contrast (shades of gray used to build panels, buttons, category backgrounds). Lack of consistency when it comes to the design of elements such as drop-down lists, text fields (size, padding, alignment, text line heights, appearance)  Different shapes of tabs in panel groups for active states, hovering states. Blending of the background color of the text box with the panel itself. Lack of consistency when it comes to the quality of icons (some look sharp, pixel aligned and pixel perfect others are blurry) Visual noise. (to much bad previews, icons) ... It would take a long time to list. It is simply unpleasant to work with such an interface.
When I read the following article on Affinity Spotlight it gave me a good laugh.
Specifically, I am referring to the beginning of the article which reads:
EDIT: link to article corrected.