eluengo

🤷‍♂️ I only wanted to give u a solution Life is tough

Sure I think objects on a white backgrount should be cut out, silhouetted, before pasting. White is never white, it depends on what you paste and the sftw it uses into screen.

Since introduction M1 and latest version of AFFsuite the sluggish first start of any of the three apps was forgotten.... But NOW with either last 2.2.1 apps or last Sonoma 14.1 OS the snail-first-starts have returned ... like McArthur.... Something wrong? (M1 MacBookAir, 16GB RAM, 1TB SSD filled only 52%, OS fresh installed, AFF apps fresh from AFFStore). Should I try different render methods: Metal, OpenGL, hardware etc.... Not sure if recently some other users have reported the same issue...?

Sorry, NO, Walt, in standard interface guidelines ellipsis after a menuitem is *always* leading to an ampliation of information the app needs to execute the adequate command. In MacOS this has been so since 1984. There is no exception neither option. Otherwise, the absence of ellipsis should (originally) lead to the inmediate execution of the command. This second rule has been broken so frequently that today no one is surprised if after such a no-ellipsis-menuitem comes a info-extension dialog. Is another error, but so frequent that isn’t really of interest. But both are errors. A different thing is that a such minimal question needs to be corrected or is really not necessary, I think it’s not. BUT this interface discipline is law (like other rules), and good practice, in the Mac universe (this is not necessarily so in other OSs, could every interface method or interface manager have its own rules and directives). A good interface design and interface rules are the best way to quick and errorless work. Regards Emilio

Certainly, I said, is known from version 1.x.x. And I know the solution. But years have passed and it's not bad to remember such little things!

This is not really a bug. Appears as an interface error, perhaps. Both [Rasterise...] and [Rasterise&Trim...] menuitems under [Layer] menu have (as seen in the video I send) an ellipsis or three points after the text of the menuitem. Traditionally in MacOs this ellipsis/3points is reserved for menuitems that invoke an additional dialog to select or modify any behavior. But neither [Rasterise...] nor [Rasterise&Trim...] have this. Both actuate immediately. Could this be an interface design glitch? Emilio littlemovie.mov

This is a little error (not especially annoying) that comes from version 1, and continues in version 2. When using dialog for new or edit Text Style, under Paragraph>Tab Stops new tab markers can de defined. In doing that a new line creates in tab list, and in every marker a different option of "Tab stop leader character" can be chosen. To edit this leading character a little button with an ellipsis [...] should be pressed and a small popup dialog appears with the different tab options to be defined (see image 1). There is not possible neither change the leading character nor adding a character sequence (like point-space, to put less dot density in the tab leader). This perverse behavior doesn't happen when invoking the same (or similar) popup dialog directly in the Tab Stop definition in the Paragraph Inspector, where it's possible to type anything as tab stop leader char (see image 2). The straightaway solution is to not define tab stops in text style, then modify it in the inspector, and update the text style endly. So is not severe, but it would be welcome to correct it. Emilio

I think the same... in "Auffüllen" the problem is probably the "ff" signature, that is considered an unique character. You can make a try introducing a soft-hyphen between both "f".... but for automating it... I don't know. Hyphenation in languages-not-english (german, spanish, french, czech or polish, usw.) can be a complex thing....

but... this was not the way version 1.x.x showed the preview for exporting.... well, I've to live with it

Is there a way not to have the "checkerboard" background (transparent?) when exporting a document? having the document's background shown as it is in the edition window (more wysiwyg) Or should be so? Is a bit annoying....

Thanx Both advices were correct. I need to remember when opening older dox

Anyway, thank you! Reconstructing the doc in a new doc created with 204 all works correctly (I have this already done). For one only book is no problem.... but if I need to edit older files, this problem will be a nightmare. Emilio

Old documents prepared with AFPub 2.0.3 when opened in 2.0.4 have lost the capability to alter paragraph leading. When done ex novo in a 2.0.4 doc all goes OK. I send two clips to demonstrate the problem. And also an AFPub doc with this problem present. Need to be corrected? Emilio 203 doc open in 204.mov new 204 doc.mov 20230131 Presentacion Curso ECO.afpub

Oh no, my dear friends Is neither elegant nor adequate to go for extra-app solutions. AFPublisher is a so good piece of software that a extraneous solution is completely out of bounds. (very good piece of sw, despite some/lot of small/no-so-small problems... 🤷‍♂️) AFF should correct its own problems.

Hi There's another problem with interface when using big font size in preferences. I send a video... it explains problem by itself. 👍 captura 2023-01-07 a las 11.28.43.mov

Light interface… less rethinked ergonomically is better a light than a dark interface.... but the dark interfaces are trendy 🤷‍♂️

Answering to @rafa-cerezo in his question about Spanish hyphenation in AFPub v1 forum... "Hi, everyone. Does anyone know if this issue has been addressed in V2 of affinity publisher? Thank you." My answer, regarding version 2 was... "Sorry but the Spanish hyphenation continues to be DRASTICALLY CATASTROPHIC in version 2 Is really unusable, and leads to a complete control and correction of the complete text. Is really, again, ununderstandable because Spanish rules are clear, published, definite, with near no exceptions, and the amount of rules is small. My personal solution is hours after hours of manual correction if the text is long. I won't give examples because those have been given before, also because the errors are excessively evident, and because it appears to be a chronic disease in a good piece of software. So like a chronic patient, is better a good medical control than other drastic or imaginative solutions. Resuming: version 2 is exactly so error-prone in Spanish hyphenation than version 1. Regards. Emilio"

Sorry but the Spanish hyphenation continues to be DRASTICALLY CATASTROPHIC in version 2 Is really unusable, and leads to a complete control and correction of the complete text. Is really, again, ununderstandable because Spanish rules are clear, published, definite, with near no exceptions, and the amount of rules is small. My personal solution is hours after hours of manual correction if the text is long. I won't give examples because those have been given before, also because the errors are excessively evident, and because it appears to be a chronic disease in a good piece of software. So like a chronic patient, is better a good medical control than other drastic or imaginative solutions. Resuming: version 2 is exactly so error-prone in Spanish hyphenation than version 1. Regards. Emilio

Hi @loukash Thanx for your ideas. Solutions with kbd can be multiple. But the real problem is the way the interface behaves. The sliders are little in size, its increment mey be excessively potential (quick on beginning, slower with bigger sizes).... all the elements in the interface are small. Solutions come through, i.e., enhancing size of sliders, managing number in number fields lively with simple keys like arrows, etc… Also occurs with other commanding structures. With big screens or far screens, all presenting small sizes of interface elements to the eye of the user, the daily use of the apps need a lot of training. Possibly I’m too old to have a crisp seeing capability ( I’m near to 70 year old), but for young eyes this tiny elements pose a high strain to the eyes (possibly ergonomically inappropiate). We really don’t should tell Serif-Affinity to change it’s interface idea, ‘cause apps are as they are’, we only can adapt to what Affinity will offer. I like the suite of apps as a whole (idea, interface, price, outcomes, etc…), and try to adapt to them instead of fight against. Sorry for the excess of philosophy.

Know and use Karbiner Elements already This job can also be done into aff apps I could also change keyb.shortcuts to any Fn key, that are seldom used, is an interesting solution….

Yes yes I know But in not-english keyboards access to [, ], {, }, \, ´, > etc... is difficult, using multiple key modifiers Sure you can change the keyboard shortcuts, sure... but all, and every time the preferences reset (what it's not so infrequent...) So is no good solution But, no problem, is not a heavy problem, we can survive without it And I'm reasonably happy with the app suite (and a bit more happy when the iOS versions grow to matureness)

Not only it’s difficult to see it (in this slider and especially in other sliders such as the size of selection brush or other brush sizes in the tool bar), but also the sizes obtained when displacing the slider grow inappropiately quick from the left edge to the right, making difficult to obtain a precise brush size when a moderate size is wanted (i.e. less than 100pt), needing to key in the value into the number field (and precisely in brush sizes where the precise size number is less intuitive than optical/seeable brush size). But moreover, aesthetically the new sliders are more modern and delicate than older in v1

OK !! Isn’t a serious bug, and probably simple to correct.

.... and after rebooting the no-blink effect remains….

My OS is Ventura, full actualized. My Mac is a M1 And no, AFPub is the only app where it occurs 🤷‍♂️ And it is only a curious effect, is no annoying and otherwise the app does what is supposed to do (some quirks, but sure in minor updates will be corrected)