-
Posts
129 -
Joined
-
Last visited
Profile Information
-
Gender
Male
-
Location
Spain
Recent Profile Visitors
1,747 profile views
-
I don't know if it's useful but I use this external edit in ApplePhotos (to AFP 2) sometimes, and instead of "saving" or "saving as" I simply close directly the app letting it to ask me if I save the changes, in this way I have never had a problem
- 49 replies
-
- macbook pro m1 ventura
- apple photos
-
(and 2 more)
Tagged with:
-
Affinit Designer Datei lässt sich nicht mehr öffnen
eluengo replied to BraNi's topic in V2 Bugs found on macOS
Ich weiss, es ist zu einfach, und du hast es sicher probiert, aber manchmal das Komputer aus- und einschalten funktioniert. Auch wenn du die Komputercachés wischst: Mac ausschalten, dann nochmal einschalten mit Hochbuchstabentaste gepresst (wenn in Intel Mac) oder in M1-2-3 Mac auschalten und wieder einschalten aber kontinuierlich Starttaste pressend, und nachher vom schwarzen Schirm aus: deiner Festplatte das System MIT der Hochbuchstabentaste gepresst starten. In beide Fälle: einige minuten mit dem Komputer spielen, dafür dass die Cachédateien gewischt werden, un immer danach wieder aus- und einschalten, un vielleicht funktioniert wenn das problem mit den using-Bit vom OS zu tun hat. Eine app kann alles das machen ohne so viele Arbeit: ONYX, ist gratis, und normlerweise funkzioniert prima. Hoffe nicht zu fehleraft auf Deutsch geschrieben zu haben -
deepblue reacted to a post in a topic: Slow on first launch returns
-
I think is's not really a problem of the 3 AFF apps, but since the actualization to the last Sonoma version (14.3) in my M1 Mac, the ultraslow first launch that we used to have before M1 has returned: frequently more than 30 seconds after dock-click lasts to appear the AFF window. Its probably an OS problem, but it's annoying. It happens only on the first launch after computer (re)start, next launches are near instantaneous, as we used to.
- 15 replies
-
- slow launch
- m1 mac
-
(and 1 more)
Tagged with:
-
No
-
I don't know if this a bug or a misbehaviour.... and is not especially annoying, but if it can be corrected...? Some flaps on the Studio Tools inspector doesn't open when clicked. They need that another flap in the same level is already open bug.mp4 to open adequately. In my case this occur with "Glyph Browser" and "Stroke" flaps. In previous AFPub versions the same happened to de "Find&Replace" flap. I include a video, if my explanation is not completely clear. (in the video the double-click that closes the flap cannot be correctly seen, but after double click the corresponding flap is deselected)
-
one-color print, white is not white, publisher 2.3.0
eluengo replied to Thomahawk's topic in V2 Bugs found on macOS
🤷♂️ I only wanted to give u a solution Life is tough -
one-color print, white is not white, publisher 2.3.0
eluengo replied to Thomahawk's topic in V2 Bugs found on macOS
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...?
- 2 replies
-
- slow launch
- m1 chip
-
(and 1 more)
Tagged with:
-
Old Bruce reacted to a post in a topic: Rasterise menuitem ellipsis
-
Westerwälder reacted to a post in a topic: Rasterise menuitem ellipsis
-
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
-
Problem with umlaut and automatic separation?
eluengo replied to farbarch's topic in V2 Bugs found on macOS
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....