eluengo

This topic is frequently repetitive, and not only with spanish hyphenaqtion (that is for me significantly severe, since is my language), also with german (my second language), and, surely, with other languages. A problem that *should* be corrected. No excuses. And german word-partition rules are complex, but spanish rules are simple (really not so simple as in english) and both german and spanish rules are publicly available <http://www.reglasdeortografia.com/divisionpalabras.html> or <http://hispanoteca.eu/gramáticas/Gramática española/División de palabras final renglón.htm> or <https://jacarandase.es/division-de-palabras-a-final-de-linea/>. That the aff.apps use *external* resources for hyphenation can be a good idea, but only if those resources work correctly. (hyph_es_ES.dic, hyph_ES.dic does not work really correct) Emilio

Is an interface concept error, more than a bug (and probably related to how MS Windows does)... is inconsistent that a window that has a group of OK-Cancel buttons has also any of the window buttons/semaphore (red, yellow or green) active or ever existent. Correct would be, either with semaphore buttons (eventually + confirmation of secureness of action) or without semaphore and OK-Cancel buttons group, bottom-right (also eventually + confirmation of secureness of action). And Cmd-W should only affect the topmost window and only if the semaphore exists or is active. Comparing with old user interface rules, modern Mac rules/habits are so flexible that sometimes designers get confused (if not mad) and permit some inconsistencies. Also sometimes designers are forced to this attitude because of compatibility necessary in multiplatform app designs. It's only an opinion 🖖

Similar problem in spanish ES-es hyphenation. It's an old-known problem in the (otherwise good) AFF apps. But, the real problem is that hyphenation rules are not so complex, really!... For instance <http://www.reglasdeortografia.com/divisionpalabras.html> or <http://hispanoteca.eu/gramáticas/Gramática española/División de palabras final renglón.htm> or <https://jacarandase.es/division-de-palabras-a-final-de-linea/> 🖖

This strange behaviour of TOCs is a permanent/constant one. For me the solution is either … — prepare the book with all its text styles and as last thing create the TOC, or — when/if the mess occurs when refreshing the TOC: modify the TOC text styles I hope future versions have this problem with TOC/formatting/textStyles definitively solved. (Because the app is otherwise delightful to use) Emilio

The size of icons and explicative interface texts are small, but with big screens with a lot of pixels and pixel density, or far from eyes positioned screens are a lot smaller, really tiny. Solutions could be... refining screen style, redesigning some icons and interface details and functionality, panels rethinking. I know this is difficult.... but for a version 2.x ..... Emilio

The size of the Index definition Dialog is really small. Not only the box size, but also the fields size (the popup ones) Also the dialog design could be a bit more explicative I send a screen dump Thanx Emilio

👌👍 Interesting Is an obvious characteristic, and very interesting Thanx walt.farrell Emilio

(AffPublisher) I was trying to put a link in every TOC line (a very common option in a file to be a book on PDF) When I do it, works!, but the Preflight control shows an error saying the TOC needs to be rebuilt. After rebuilding the TOC.... all the links disappear ... and so on... It's not a good thing, really... Emilio

this characteristic [fillable PDF.forms] would be.... great, fantastic, gorgeous, awesome [... as Steve said....] (no need to go into Adobe' hell, o trying to use free PDFescape web)

I had same problem. I located those problematic glyphs through the "preflight" panel, double-clicking the line that marks the error. Maybe this help u !? Emilio

Hi My brand new M1 Mac has ALSO the slow-launching problem with the 3 apps.... only it's no so severe: instead of more than 40 icon bounces, now is only 18 to 20 bounces. But it continues to happen every time I reset or start the Mac. It is probably more due to Big Sur problems, since this behavihor started when updating to OS 11.01 or 11.1 .... Emilio

+1 Useful and interesting feature, will be welcome when implemented I use https://www.pdfescape.com but is limited and error-prone

In my case, the slow-launch problem occurs only after upgrading macOS to 11.1, and only in one of my Macs, unfortunately in the most used and most powerful. It occurs with 1.8.x and with the new 1.9. Neither with older macOSes, nor with less powerful Macs this awsome problem happens. I'm now thinking the problem could be the system configuration, not only the app.configuration. I wait for my new MacM1 to see if there also occurs, and also have time and a new Mac to erase completely my slow-launching-Mac, and reinstalling all to see if this can be te problem (the jump from 11.0 to 11.1 macOS version was full of problems, even with lost information in iCloud!) Is an annoying problem, but is really not a severe one, since it only happens the first launch on an app after reset/restart, or after a long inactivity period. Apparently AFFINITY is aware of the problem, it will have a solution, even when after a long time.

Version 1.9 (not beta) has the same slow-launch problem: all the apps: Photo, Designer, Publisher (from both Affinity Store, and from the Apple Store) 🤷🏻‍♂️

Very curious.... In my MBPro with i7 and a lot of RAM and disk the SLOW apps launch occurs, but NOT in an old MBAir with only a i3 and half RAM and half disk.... why is it so????