JGD
-
Posts
513 -
Joined
Posts posted by JGD
-
-
I think there's a naming convention problem, and that this problem is foundational to the problem of understanding the differences between the two apps.
Affinity Designer should be named Affinity Illustrator...
wait for it....
Adobe Illustrator should be named Adobe Designer
________________
Adobe tacked on illustrative style functionality, and then spent a decade (or more) pursuing that because they weren't willing to make a Painter style competitor to Corel Painter, and thought their combatant with Corel Draw (Illustrator) could do both things well enough to counter.
And then they began figuring out how to control the media, and became a monopoly.
But that doesn't change the fact that Illustrator is the first app every designer reaches for to do vector design work. (with the exception of those that use alternatives from competitors).
Illustrator is a design app.
Affinity Designer is an illustration app, and not well suited to the iterative processes of design.
But it's called "Designer" and posited (by the media and many of the press releases and undertones of commentary from the makers) as an Illustrator rival.
It is possible to use AD for design, but it's a painful slog, very restrictive and not anywhere near Illustrator for this avenue of creativity. But Illustrator isn't any kind of benchmark, Illustrator has the worst workflow of any design app. Ask anyone that's used Freehand or CorelDraw, they'll give you a ream of reasons why Illustrator's workflow is horrid.
But AD is currently far more limiting and stunted for creative design processes.
So, yeah, I agree, Affinity is not Adobe.
But Adobe isn't much of a benchmark.
This. Thank you, deeds. You surmised most of my, err, little beefs with AD. *Iteration* is key!
As I said: because AD shows dragged objects as fully rendered instead of phantom shapes (you know, much like the old outline window dragging behaviour in Mac OS Classic/Windows 3.x vs. the full “show contents while dragging” behaviour of OS X/Windows 9x), it doesn't support self-snapping of objects. If I want to iteratively produce a regular texture by exponential duplication in AD, I will have a hard time snapping things together (you could argue that I should use something like symbols or pattern fills instead, but what if I wish to manipulate areas of it?).
And while AD's vector tools are, in many ways, more intuitive than Illustrator's, and snapping seems to be an area where Serif is investing a lot, it seems to be too spotty to be relied upon for rigorous, geometric drawing. I know that some killer features (central node – hopefully with snapping support? –, rotation with custom centre, etc.) are already in the official pipeline, but AD doesn't provide, by design (!!), some features that are essencial for a user to give it that extra rigour, like being able to easily drag a selection from a specific node and have it snap to another node (and not dragging it aimlessly around the target node, waiting for AD to guess where exactly you want to have it snapped and having it fail miserably at it).
I know I am beating a dead horse here, but transform handles should be hideable in some way when initiating draggind operations (and nodes could and should be selected as preferential snapping candidates, a la Smart Guides behaviour) or, alternatively, the node tool should select automatically all nodes on a previously selected object for more precise dragging, *just like in Illustrator*. And that wouldn't, in and of itself, make AD “too much like Illustrator” (hey, the vector drawing would still be far better, hands-down) while both making the designer's camp *very* happy and not being detrimental in the least bit to the illustrator's camp. Oh, and when can we expect snapping to curve intersections? That would be a godsend, IMHO…
deeds, you have pretty much nailed it. AD has, first and foremost, a bit of a naming problem (or maybe a problem of positioning, too, because there is, indeed, more of an overlap between AD and AP – namely the pixel brushes, which are, as you pointed out, more useful to illustrators than vector designers – than there is between Ps and Ai, and also because Affinity Publisher will attract even more people from the strict, hardcore vector design crowd, and those two factors will make AD's shortcomings become all the more evident), and Adobe Designer / Affinity Illustrator would, indeed, be more fitting monikers.
-
Hi all! What about these latest developments from BUILD'15?
Something tells me that if porting iOS apps to Windows becomes easier (and Serif, as far as we know, started development on Affinity products for iOS first, which is interesting), porting OS X apps will, too. I've read somewhere here in the forums that the underlying engine of Affinity was coded in a somewhat platform-agnostic form of C already (I don't recall which, but I do remember it wasn't Obj-C…), so porting the rest of the code (the UI part, I'm guessing) would be a breeze.
While I know that porting is not the best way to addressing multiple platforms (hey, I should know better as I used the infamous Corel Draw 11 for Mac for a while before ultimately switching to FreeHand; it was buggy as hell), Adobe's approach isn't the nicest, either. And, snobbery be damned, it would be the ultimate irony: Windows users using a port of a Mac app and actually *liking* it (because, y'know, performance… ;) And I believe the team at Serif would do a better job at adapting/redoing the UI for Windows than Adobe did back in the day when they still kind of attempted it – and failed miserably at it, as the multiple layers of cruft and stupid pseudo-native UI controls still found in CS6 attest to –, anyway).
-
I was aware of Arial's history, but I hadn't realised that's what Walter was refering to, so thanks for explaining. I think whatever font we pick as default is unlikely to be what a designer wants for her current project so having user-definable defaults is the only real solution. We picked Arial partly because it is available on more platforms because of its cheaper licencing.
Interesting and well-thought reasoning… But isn't Serif only supposed to look at other platforms only 12 months from now? ;)
The thing is, Helvetica has been, by default, available on OS X installations since its very inception… Then again, so is Arial, since it's considered a “web-safe” font and, thus, has to be available on OS X on account of its ubiquity. So I can see why choosing Arial isn't such a big deal, and well-justified… And, come to think of it, having the default be Arial will free you from the “AvantGarde/Myriad/Minion effect”, which are the tell-tale signs that a particular “designer” probably lacked training and just went with the default font (which can very well be and indeed sometimes is the best choice for a given project, thus triggering some false-positives) of the software package of his choice.
That, in itself and IMHO, is not a very good endorsement of neither Corel or Adobe… If Affinity uses Arial as the default, professional designers (and some rare non-designers, and I know a few) will be left thinking that a lesser “design” (and, really, I may come of as snobbish for using such wording but those are very easy to spot and should have no place in a society were many professional, properly-educated designers *are* starving or forced to migrate – I come from a country where that is, indeed, the norm) done in Affinity was done by someone without font (or even design) knowledge in either Affinity or any of the aforementioned software packages (or even, dare I say it, some random old version of Microsoft Publisher or even PowerPoint)… Well played, Serif, well played. That's some fine piece of extremely convoluted reverse-psychology “non-branding” (or “white-branding”?) you've got going on there. ^^
Well, random and snobbish considerations aside, if I may add and since you brought it up, could Serif look into some deals with font foundries and type designers? I'm guessing that one of the reasons Affinity products are so inexpensive is that, as far as I can tell, it doesn't come with any bundled fonts. I wouldn't say that CS5/5.5/6 was competitive (not the full, professional version, that is), but the fonts were a bit of a “consolation prize” after the price-gouging. On the other hand, you ended up paying for fonts which you might never use anyway…
So, can we expect someting (optional, of course) along the lines of TypeKit in the future? Or maybe discounted fonts bought as In App Purchases, which could become available system-wide? Who knows, maybe even a full-fledged font store like FontExplorer had? As long as its OpenType support is best-of-breed, as it looks to be shaping up to become very soon, I don't mind Affinity being fully BYOF (bring-your-own-fonts, I just coined the term), but it surely would be great to see Affinity supporting leading independent type designers and cutting deals that could make everyone win, without necessarily having to jack up the price tab of the apps themselves…
-
Is there any option in AD to convert fonts automatically to curves while importing a pdf file?
I have the problem theat I need to work in imported pdf files and very often the pdfs were created with fonts that I do not have installed => error message after import "fonts not found (...) .
I do not need to change the textes but I need to replace the text layers within the document. So converting all texts to curves would be very helpful for me.
Any idea? Thanks!
I find that to be an excellent suggestion; I did precisely the same suggestion on this post. I am not sure just how legal that would be, and at least MattP isn't, either.
On that subject, I'm still waiting for a more definitive answer and, in the lack of it, whether the guys at Serif could, by themselves or through a proxy (like me, for example) sort it out.
But I'll add my €0,02: all of the Affinity suite components should be able to place a .PDF as a linked file and still make use of the embedded glyph data, much like Illustrator, InDesign and Photoshop already do, even though it might not be editable. The fact that even the latest betas of Affinity Designer and Affinity Photo both ignore said embedded glyphs and use a fallback font instead makes me believe that either it's a bug or, more likely, a feature that has yet to be implemented.
Am I right in that assumption? Anyway, I will add it seperately to the feature requests if I don't find it there or on the roadmap, to make it more visible.
-
+1 for me as well! I have done a nifty project in Ai that used a trick combining this feature with a clipping mask in order to make a more controlled, spiralling colour blend (it was a monogram of two extra bold characters, and I wanted their fills to also blend at their junction, while following their general stroke direction)… It's a killer feature of Ai CS6, indeed.
And the great gradient support in Designer has left me salivating for more… ;) While I'm at it, it is *so good* that it was the only feature, for now, that I've used in a production environment (in my day job, no less). I had to do this project with a gradient background, assembled in Photoshop, and I actually made it in bitmap form, exported directly from Designer.
Seriously, it is *that* much better than Adobe's… I will rehash this year-old Photoshop.com forum topic on gradients, which I linked to earlier in these forums, as it goes to show just how out-of-touch (some would even say downright nasty and borderline autistic!) Adobe devs are with their most technically-minded users: http://feedback.photoshop.com/photoshop_family/topics/photoshops_gradient_editor_needs_an_overhaul
-
Hi JGD,
It's really not my area of expertise - I don't know for certain the legal side of things so would have to seek advice on that one, sorry...
Thanks,
Matt
Hi Matt,
Once again, thanks for the frankness. Do you have a typography guru over there who might get around to find more about .PDF font embedding and licensing issues?
I don't mind working as an ersatz type guru kind of guy and do that myself, but if you have one already, all the merrier (I do, after all, have to tend to my day job and clients already). I think this kind of thing could, say, be escalated to a Typophile thread, as those guys really know their stuff…
You know, if it's not illegal (I'm afraid it might be, but hoping that it isn't… Wishful thinking, I know), it could really become a differentiating and, I'd venture to say, killer feature. Adobe doesn't have anything even remotely similar, and our work sometimes lives and dies by typography, so there's that.
-
+1 from me as well… I work mostly in print and, more often than not, our projects have light backgrounds (you know, with them being related to healthcare, pharmaceuticals and all). So, having the interface match what I work with would be a plus.
Also, I have been using Illustrator and Photoshop with the dark theme, in order to get used to it for when I eventually switch to Affinity for good, but I really don't find it that easier on the eyes (I wouldn't say that I am strongly affected by it either, but the whole “lower contrast between contents and UI chrome” argument seems very sound so I'm running with it as well). In fact, I will try reverting it to see how I feel about that.
Anyway, as for the whole “this may slow down our development” stance, yes, I am aware it would, but with all of your magnificent tools you'd make lighter versions of the UI elements in a cinch. It'd really mean having only a second set of interface elements and the UI Gamma slider go all the way to light grey, plus some testing and coding (and then, economies of scale would kick in as I'm guessing said code would work equally well in all of the suite components). I am aware that's how
AdobeIllustrator manages it, but that is, indeed, the only sensible way. I am with all the others: stuff like multiple artboards and pasteboard editing must stay at the top of your priorities, but a customizable UI shouldn't be that far down the list either. It is, after all, something your users will have to interact with on a daily basis, and there's no running away from it as there's not really any sensible workaround (maybe short of inverting the interface colours on the Accessibility Pref pane? ^^ Well, actually, it doesn't look too shabby! ;) ).Also, I really don't agree with your assumption that since Apple now has some pro apps with darker chrome, that automagically makes it a good fit for the task at hand. Apple, as we all in this board may agree on, is not necessarily the single best authority on UI design (even though they were its pioneers, yes), as the whole skeumorphism trend (going back as far as QuickTime and Panther's brushed metal theme) and at times excessive use of transparency/translucency (see pre-Panther iterations of OS X and iOS 7) attests. Also: Helvetica. I'm yearning for the days when we had a decently hinted UI font (I know that Retina displays partially obviate the need for such hinting, but please bear with me… Besides, they are still launching updates to their old, Retina-less models, which, frankly, render Yosemite's UI in general and Helvetica Neue in particular in a not-so-great fashion), with proper, wide apertures (as for the impact of those on legibility, Retina or no Retina is a moot point), and hoping that Apple comes round and brings San Francisco from the Watch to iOS and OS X, STAT (not because it's the best-looking font around, but because it at least fits the bill function-wise). I was ecstatic when I saw they were replacing VAG Rounded with it on the new Retina MacBook keyboard already, even before shipping the watch, but seeing that they are still so fond of the progressively anorectic Myriad Pro, I'm not holding my breath… Can't you see just how all-over-the-place, typography-wise, Apple is? It's downright cringeworthy for a company that size and with such a reputation, and it's always been that way (even in the dawn of the DTP revolution, right on the Mac, Apple was using a crappy, optically condensed version of an already badly traced Adobe Garamond instead of a proper font commissioned to, oh, I don't know, a high-profile type designer like Matthew Carter… And don't even get me started on Motter Tektura. :P )
And while I'm at it, even Apple, the king of forcing-UI-decisions-down-our-collective-throats (even moreso than Microsoft…! Yes, do check this video out: you could actually upgrade from Windows 2 all the way to Windows XP, while retaining your color scheme… Crazy, am I right?), got around to that and added a dark mode *in addition to* (not in replacement of!) the light mode for the dock and system menu. So, even if they might be veering off into an overall darker theme, they still acknowledge that one size does not, indeed, fit all. As for Adobe (which, if I may remind you, is still your #1 competitor), well, they also pretty much nailed it. They might have started – or at least heavily contributed to – that trend as well, but at least they still give people a choice (on that regard, I find it telling – if a bit incoherent – that the InDesign team didn't even bother to make a dark theme on CS6… Maybe they were prioritizing bug fixes instead? Even so, it has been a lighter shade of grey than the rest of the Creative Suite for many years in a row, which is interesting).
-
Hi Smallreflection,
That's a nice request and one that's hopefully fairly simple to achieve - just cache the outlines of the text in the file until such time as you edit them...
I'll put it to our text guru when he gets back from his holidays and see what he thinks :)
Matt
Hi MattP,
Speaking of caches… What's the legality and feasability of fetching the glyph information embedded inside a .PDF exported by Illustrator or InDesign and using it to render all the corresponding text strings present in said file, even if the font isn't installed and activated in the system (at least until the user tries to edit it, not unlike smallreflection proposed for .afdesign files and .PDF readers already manage to do by design)?
Also, while I'm at it, do you reckon that those glyphs could be convertable to outlines? Or… would that veer off too much into the “downright illegal” camp?
I am posing both questions not because I might wish to pirate fonts (as I said before, I am enrolled on a typography-related master, so I am very much against that as a matter of principle; and, besides, even if I did want to do that, that would be the stupidest way of going about it, as not only the glyph sets are incredibly limited for all but the largest documents – say, multilingual or reference editions like encyclopedias –, you are also certain to lose the kerning tables and OpenType features in the process), but because of the odd logo I sometimes have to rebuild or extract in vector form at my day job. I am pretty sure that many colleagues around here can relate to that. :\
- ronnyb and smallreflection
-
2
-
Well, I'm not giving up the sexy live previews, CPU and fans be dammed, lol! Maybe if it's an issue like you say, it becomes a setting for low quality or ½ resolution brush previews or something like that, instead of just turning it off altogether... If I could only channel that excess heat into a thermo-electric converter to recharge my laptop's battery... C'mon Apple, let's start making zero-point, free-energy laptops already, lol!
Now, I wonder, who would've thought of that… http://evergreenterrace.com.au/wp-content/uploads/2012/06/Machine.gif
Sorry, couldn't resist lightening up the mood a bit. ^^
-
Hi JGD,
I'm sorry if you feel we're not making progress quickly enough... We're obviously typing as fast as we can - but we can't afford to just throw stuff into the application because it causes bugs - and then we end up with a program that is not a nice experience for anyone. We've clearly shown that we're taking translations seriously by introducing this Designer update with the first 4 languages in it and also Photo Beta is now showing our intentions to add support for your regionalised number separators. This could not be safely added to Designer before it was submitted - it would require at least another round of testing as the potential for it to go subtly wrong and completely annoy users is high, so was deliberately left out of the final build. That's just the way it is. But when the next Designer beta appears it will obviously be there, fully working, just like in Photo Beta.
Miguel (MEB) is part of the team and, yes, he's Portuguese so might even be able to help us with Portuguese translations - that's his decision as it's not his primary role in the company, so we'll leave that to him - but I don't know why you'd imagine you'd have to wait a long time before a Portuguese translation was made available? We haven't scheduled it yet, but if there is enough real demand for it then it requires very little coding effort now that we have the other languages working, so it's mainly about how quickly someone could type the translated strings and someone else could review them.
Thanks,
Matt
Hi Matt!
Thank you for your quick and frank response… Sorry, I sometimes forget just how finicky coding on large-scale projects like Affinity can be. I stand corrected… And you're right, I'm a bit of an impatient guy. But I do like the way the suite is heading and how it is shaping up to be a serious contender (and, yes, I will be buying both Photo and Publisher when they show up in the MAS).
Well, maybe was I underestimating your localization efforts… Sorry for that, too. I see you might be aiming higher than even Adobe, as pt-PT is, admittedly, niche at best (Adobe does offer a pt-BR localization, but that's kind of moot; pt-BR always rubs us the wrong way as the differences in vocabulary and grammar, *including* technical stuff, are way bigger than between en-GB and en-US, thus making us feel a bit like “second-class” users and, more often than not, opt for the english versions instead – word!). But hey, if you are considering it, consider us spoiled in anticipation, then! ;)
By the way, while I'm at it and since you mentioned that MEB may participate even if his role inside the company isn't specific to localization, well, I might as well reiterate: if you also need volunteers or paid consultants, sign me in (if I were paid, all the better, but mostly I just want to watch Adobe crash and burn, while securing a decent and peaceful future for me and many colleagues as, potentially, strictly freelance designers… The only reason I ask is because I'd have ethical qualms about robbing my freelance translator friends of a potentially well-paid job). I've been working with DTP software since the early '00s and, being enrolled in a typography-related major, I have unfettered access to academics in the field and all the best portuguese literature on technical nomenclature (titles like “The Dictionary of the Book” by Almedina editors or the [waaaay] out-of-print “Graphic Speller” by renowned printer Vilela, just to name two).
Also, I personally know (nay, I am actually friends with, as I said) three freelance translators, one of them being an ex-girlfriend of mine (and a damn fine translator, if I may add; she attained her master's degree with flying colours, having scored a whopping 19/20 on her final dissertation and an overall 18/20 course grade), and another one of which works specifically in UI and documentation localization (but they are all eclectic enough to work on it regardless of their specialty). I am not sure if they are currently available, but, judging from the current job landscape here in Portugal, they very likely are, and I can definitely vouch for their competence. If and when you so wish, PM me and I can get you in touch with them.
Anyway, as always, keep up the great work!
P.S.: While we're on the topic of localization, how universal will the hyphenation support be? Do you, as purveyors of PagePlus (which, admiteddly, I barely got to know by anything other than name… I believe I launched a trial under a VM once or twice, but that was pretty much it), already have access to full hyphenation dictionary licenses? I am just asking because that will be an essential feature to have in Publisher – though I'm assuming that Publisher will not foist cumbersome shenanigans upon us like Quark did (like having to get a separate, “Passport” version… ha!) and be more like InDesign in that regard, am I right?
-
And please, could you insert a keyboard shortcut for the soft hyphen, "while you’re at it" ... ;)
And wow, I have just seen that we can now separate the decimal places by commas in Affinity Photo ... at least in some localisations ... I would love to see this feature in Designer as well ...
And well, this might seem somewhat inconsistent: but why not allow placing commas in the English localisation as well? I must confess, I have quite a lot of non-localised design apps on my Mac and I am somewhat accustomed to the English terminology ... so I have not made the switch to the German version of Affinity Designer yet ... but on the other hand, I would really like to have the option of typing commas here as well ... does that make sense? :unsure:
I mean, guys, *seriously*?
I am disappointed that Affinity still doesn't honour the users' regional settings… I could very well even have OS X set up to display all the interface in english (I have it in pt-PT, but that's besides the point anyway, as it will take ages – or maybe not even come to pass – until we get a pt-PT localization – and I'm fine with that… I've been living in english-UI land for 23 years now and have no issues with that fact), and still want it to recognize different decimal separators, as per my country standards (and also have it recognize international ones and convert them on the fly to the local ones, as I might wish to copy measurement info from foreign websites or documents – I'm hoping that the comma support is *added* to the period support and not an “either one or the other but not both” proposition).
I'm taking back the nice compliment I gave you on the Photo Beta forum right now, sorry… Can you still straighten this out before the final RC is submitted to the MAS?
Btw, @MEB and @ruimac, are you with me?… I know for a fact I'm not the only portuguese guy around here (and MEB is even, AFAICT, a spokesperson of sorts for your company), and I'd very much like to use my commas just like I was taught to at school. It's been, what, 24 years worth of muscle memory already? And I'm guessing you must have at least as much if not even more experience than I do (I find the latter more likely), so there's that.
[Edit and P.S.: Out of morbid curiosity, I did indeed try to change the UI language to see if I could try the decimal comma separator support but didn't get it to work in Designer with any of the localizations, nor did I find any preference whatsoever with which I might toggle it – not that I think, as I very clearly stated, that should even be a configurable preference but something universal and activated by default, but still. As for Photo, yes, I tried it in spanish and it worked just fine, as it should on *all* localizations and does in all Adobe apps already, so since you already have the necessary code in place, I'm hoping you can activate it in time for the final Designer update RC.]
-
Hi guys!
I've just found the most exciting article about haptic feedback on OS X apps… It seems Apple is experimenting with it already!
http://www.wired.com/2015/03/apples-haptic-tech-makes-way-tomorrows-touchable-uis/
Which reminds me of one of my favourite features of Freehand (though it was extremely annoying for everyone else nearby), which was sound feedback (namely for stuff such as snapping).
I wonder if Affinity could stand to benefit from these brand-spanking new trackpads that Apple is sure to be rolling across their whole Mac lineup very soon (the 13'' Retina MacBook Pros already have them, too, so it shouldn't take more than two or three revisions for them to trickle up and down the other product lines – maybe even including the external magic trackpad and mice?)… Maybe you could implement some sort of quieter form of feedback that leveraged those newfangled capabilities? That would be incredibly cool, IMHO.
As for the implementation of said features, I have no idea whether Apple is using private APIs but, even if they are, it stands to reason that those should be included in the next version of OS X and Xcode, am I right?
-
- Support for a localised decimal separator (ie. 10,6)
This! It's the little things, you know…Sorry, guys. Thanks but no thanks for *incomplete* and *useless* support for “localised decimal separator”… What good is that for me? I am certainly not switching my UI to spanish or french just to get that, right? This kind of stuff should *not* depend on the users' language settings and, while I'm at it, neither should it be affected by the regional format and measurement unit settings.
Not when Adobe pretty much nailed it already; Affinity products should, besides being able to perform on-the-fly conversions between formats (say, if I paste a value in inches or points into an input field, it does indeed convert the value to whichever unit I'm using by default), recognize something as simple (but not less niggling) as a comma… The fact that it supports the first sets up the expectation that the second should work, and the fact it doesn't, makes the app look amateurish. I mean, for the love of all that is holy and sacred, pop open some Adobe app and see how unit- and region-agnostic they are. And those guys are pretty much the kings of UI/UX inconsistency…
I seriously expected better from you before, and I very much hoped that you got it right the first time you got around to fixing it. The worse kind of disappointment is the one which comes after heightened expecations. And that, my dear friends, includes something, as I said, as tiny as a comma.
[Edit and P.S.: Out of morbid curiosity, I did indeed try to change the UI language to see if I could try the decimal comma separator support, and it *did* indeed work out-of-the-box with both commas *and* periods. I mean, that's the way it should work under all language settings, IMHO. There is 100% benefit and 0% disadvantage for users, much like on Adobe apps… So it seems you are on the right track and I am optimistic you can maybe fix this one in time for the final Designer update RC…]
-
This. It happens on my work setup too (an Early 2009 Mac Pro running 10.9.5)… I'll be sure to check it also on my iMac (a 27'' Late 2009 running 10.10.2) once I get home.
-
Hi guys!
First off: congratulations on finally getting this baby out! Even though I am not a photographer or illustrator and won't spend most of my time on Affinity Photo, I do have to do some photo editing every now and then and, for my use cases, it's probably the best tool available around. I've always found Photoshop convoluted anyway and, never having gotten around to fully master it, I'm not really all too bothered by the APhoto “learning curve” I've read about on the forums… But I digress.
Anyway, me being the nitpicker I am, I already have a little nit to pick, and that is window zooming behaviour, specifically in separated mode.
I should begin with a pre-rant rant, a repost of sorts, as an introduction: I don't really like Serif's approach to a free-floating, non-dockable separated mode UI (in other words, I mean I'd rather have a fully dockable, auto-stretching, edge-to-edge panels *and toolbars*) and much prefer Adobe's approach, which not only allows you to fit all UI chrome to the screen's edges, it also restricts zooming of your windows all the way to the edges of said *UI chrome* and not of the screen itself. Serif's approach seems clumsy at best, as windows zoom all the way to the scren edges and, thus, both the toolbars and panels end up getting in the way.
One of the few reasons that up until recently made me use the “separated mode” (a.k.a. classic, multi-window mode) in CS6 was being able to use Application Exposé to switch between open windows; nowadays, since I've quickly adhered to tabs (how could I not, with the number of files I must have open at any time now that I'm a proper professional?), I only use it for saving some precious vertical space (the sheer waste of space caused by that stupid, nearly useless and empty Adobe “Application Bar” is dumbfounding… As for Affinity, the top title bar also wastes some space but at least we can get around it by using fullscreen mode)… That is, except for Photoshop, where I live and die by the Classic Mac OS-like windowed approach and would never even consider using Adobe's windowed mode. I mean, it just *makes sense*, as image proportions and resolutions can be wildly variable, I sometimes have to process considerable numbers of mid- to small web/screen-ready images (and I'm sure I am not alone in that), and that also has the added benefit of allowing you to drag layers and effects between different windows/files…
As for Affinity Photo… Even though I don't really like the current “Separated mode” approach, as I said, I was willing to put up with its [current, I hope] limitations if that meant I would get the same functional benefits as in Photoshop (I haven't put APhoto through its paces yet, but I'm willing to bet that I will). There is one choice on your part, however, that I find inexcusable, which is the zoom button behaviour. Since the separated mode and full-sized windows (not to be confused with fullscreen windows) are, as I said, mutually incompatible (or, at best, clumsy), shouldn't the zoom button (under Mavericks and below; I obviously also mean the classic behaviour still achievable in Yosemite by option-clicking the fullscreen button) adhere to the lifelong Classic Mac OS/OS X/Adobe standard of zooming to fit content instead of zooming to fit the screen size? I know this “zoom/shrink-to-fit content vs. zoom-to-fit screen” debate is as old and tired as OS X and its more proeminent full-screen apps (like, say, Mail – which goes far back into the NeXTSTEP days –, iTunes and iPhoto), but please bear with me and my rational for this suggestion:
If I wanted to use the screen to the max for one particular project I could (and very likely would/will) just toggle the unified mode temporarily, plus the fullscreen mode if I *really* wanted to kick it up a notch… As it stands and as far as I could find it, there isn't a way to achieve that “zoom/shrink window to fit content” function, am I right? Ironically enough, you *can* zoom the content to fit the window size, so it stands to reason that, much happens already with content boxes in InDesign/QuarkXPress/Affinity Publisher (which I'm salivating for and will obviously feature such functionality), the opposite should be possible, too…
All in all, I believe the current trend towards unified-window approaches and, concurrently and helathily, allowing for its classic counterpart (hey, choice is good, even if I find the implementation lacking a bit of polish and flexibility as I said), could finally put that debate to rest, at least in document types that have well-defined content boundaries. This default behaviour would, of course, make absolutely no sense in Affinity Publisher layouts or in a future version of Affinity Designer featuring multiple pages/artboards (AFAIK, that is still in the pipeline, right?), but it would fit in perfectly with many Affinity Photo use cases, IMHO… If you don't think they are enough to warrant it as a default, non-customizable behaviour, well, you could at least make it a toggeable preference on the User Interface tab.
-
What does Rui have to say. This sounds like it's an area he knows well :ph34r:
Since we're even from the same city, I am curious to read his take as well. ;)
-
Thanks, Ben!
But while I do appreciate the acknowledgement to my feedback, what timeframe are we looking at?
You see, this is more than a localization issue alone; it's more a matter of conforming to Apple's HIG and each user's own OS X settings for measurement units (in fact, if I wish, I may just go to the International prefpane and switch the decimal separator to a period – independently of all the other settings, while I'm at it –, but then I'd have to retrain my muscle memory and it would otherwise look weird – visual memory being harder still to retrain –, and for what?)… I've never used Adobe CS on my native language (because, in fact, it was never avaliable in european portuguese, but only on brazillian portuguese… Which, while being the same language, has such big vocabulary and grammar differences that using any pt-BR localized version of technical software becomes more annoying than helpful – and yes, while I might come off as, or even actually be, a bit pedantic about it, the difference between pt-PT and pt-BR is *way* bigger than between en-GB and en-US, trust me on that one –, and there's always the added ease of looking for community support/tutorials angle which might even preclude me from adopting a pt-PT version – unless I could toggle it on the fly either on AD's preferences or on the International prefpane, neither of which options were ever offered by Adobe's apps) but, yet, it always somewhat conformed (in its own quirky, convoluted, inconsistent and sometimes buggy way) to the HIG.
So, is there any chance that this may be fixed (because, in my eyes, it is indeed a bug/ommission and not an admissible “feature”) earlier and/or work regardless of the localization we are using (if any)? I could easily envision AD being ported to pt-BR waaaay ahead of pt-PT (if the latter ever comes to pass, at all), and wouldn't be too happy having to deal with nags like this because of that (with something apparently “big” like working, reading, writing, speaking and even thinking in english, I can live just fine, as you might have guessed by now; it's just these little things that get me :P ). Also, I might as well add that linguistics ≠ mathematical conventions and localization ≠ international/unit settings, as you've already acknowledged by, obviously, allowing users to choose imperial or metric units regardless of which side of the pond they're on. Or is that a too far fetched assumption? ;)
-
Hi guys!
I just stumbled into a little nag… I'm still using CS6 at my job, but gradients in both Ai and Ps are so crappy that for gradient layers in Ps I've decided to resort to AD instead.
The thing is, when copying measurements from Ai's Transform palette to its AD counterpart, the values use a comma separator (maybe that's not the default, but it's what we use in Portugal and, thus, the default separator in the Regional settings preference pane), which AD unfortunately doesn't recognise.
So… having to manually change the separator from a comma to a period instead of having AD recognize pasted values regardless of the standard used is a little nag, which adds up over time for people who may not adhere strictly to the period standard. Also, having AD's palette ignore duplicate unit names (like “mm mm”) and, thus, making it extra fool proof, would be terrific, but maybe that would entail too much code? I mean, the fact we can perform operations directly on the input fields, much like in Ai and ID, is great enough already.
Also, on a related note: AD's Transform palette rounded the values to a single decimal value… or did it? Isn't AD supposed to be more precise than Ai, with all those humoungous mega-zoom percentages and whatnot?
- olafwelling, Mr. Doodlezz, frip and 3 others
-
6
-
There are plenty more secrets lurking... but you'll have to keep digging! :)
You make product develoment and public beta testing sound like a Valve ARG. ^^
On a more serious note: I'm liking what I'm seeing, especially the pace. Keep it up! ;)
-
[ Oh, goody, I just updated my Wacom drivers to the latest version (released in August), to no avail… God, I *hate* that company almost as much as Adobe, their support is utter crap… :angry: At least they didn't completely bork my tablet like they did last time I tried to update them, under Snow Leopard, before I finally convinced our boss to call the IT guy and update my workstation (I could've done it myself, but I had to have prior approval and don't intend to put that guy out of a job B) ). ]
-
Andy,
Thank you for your clarification on colour. I also thought it might have something to do with colour engines specifically, but I just wanted to be sure about that. :)
Just another heads-up: pinch-to-zoom doesn't work on my Bamboo Pen&Touch (model #CTH-670), which is something I may or may have not tested before (I'm guessing it never did, as it doesn't work in the latest stable release, either). It's predictably jittery in Ai, but at least it works (not that I use it much anyway, precisely on account of its flakyness, but, then again, *everything* except Spacebar-to-pan is jittery in Ai :rolleyes: )…Oops. I must be suffering from some driver incompatibilities/outdatedness; it's not working on Preview either (I'm running 10.9.5 at work, btw). As for it even working on Ai in the first place, I can't come up with a plausible explanation. :wacko:As for the brush and pressure support, it's all looking fine and dandy (I'm working on a Quad 2.26 MacPro4,1, so I'm having no lag issues here whatsoever), and Scroll-to-pan and Option+Scroll-to-zoom are smooth as butter, much like in the latest stable release, both using the Bamboo as a touchpad and the Magic Mouse.
Still on the subject of tablets: is there any way we can regulate the brush smoothing factor (Tolerances > Fidelity and Tolerances > Smoothness, in Ai parlance)?
-
Hi Andy,
adamtwar beat me to it; great work you have going there on OT support! :) That small usability hindrance on the sub-panel collapsibility isn't yet gone, though, but I'm guessing that should take a larger amount of coding than just string tweaking, so do take your time to get it right. ;)
As for yesterday's CMYK bug, it's partially gone (the bizarre discrepancy between both CMYK field sets on the colour palette, that is)… Colour me impressed! :D However, the slight discrepancies in the CMYK/RGB values between AD and Ai are still present; btw, I'm using the same CMYK and RGB profiles on all files I sent you yesterday, both on AD and Ai: U.S. Web Coated (SWOP) v2 and sRGB IEC61966-2.1, respectively. Am I doing something wrong, or is this behaviour by design?
-
Hi Dave,
Indeed, I didn't have time to ascertain whether those features were plain vanilla OT, AD-specific or a blend thereof, but something on the back of my head told me that the name change might be related to that… Good call, then!
As for your implementation of common ligatures, that does sound like a sensible approach. And even though OT is indeed an industry standard, it's nice to hear you're looking into AAT support as well. :)
Hmm, you say the ‘hist’ feature doesn't support final and medial forms, even though there are some cases (the medial/final s being the most outstanding) where it could apply? I guess that may be a shortcoming of the spec itself and, thus (and since I'm all for following specs and standards), my suggestion of escalating that to those who define it in the first place may not be that farfetched, then?
As for ‘fina’, I'm guessing that is probably specific to scripts that require it by default [i just checked; arabic and syriac do], so maybe mixing and matching unrelated features may not be the best way to go when designing a font (or an application, for that matter)… But if it is the *only* way to do it, alas, I guess I'll have to bundle an instruction manual with my fonts (as for your side of the equation, well, it was just a suggestion for an ultra specific and rare use case, so if you really can't implement that, no biggie). :P
Speaking of which: ‘calt’s of “long s_[space]”, “long s_[period]”, “long s_[comma]”, “long s_[hyphen]”, “long s_[em dash]”, “long s_[en dash]”, [etc.] pairs could also do the trick, I guess, but wouldn't that be a bit, pardon the pun, baroque? :lol: [Also: wouldn't that only work with explicitly input long s, U+017F *characters* instead of subbed glyphs, which should really be rendered as proper long ‘s’s regardless of their surroundings?] Anyway, I'll also take this particular issue to other pastures (namely, the Typophile and Glyphs.app forums), as it seems interesting enough to warrant some further investigation and discussion.
You asked me about fonts that might behave in a more desirable manner in other apps; unfortunately, I didn't have much time to scour my work computer's font library, since I was doing it in between jobs. I mostly tested Adobe's own “Pro” fonts, but I'll be sure to check out that behaviour on other 3d party fonts and apps, and also on a font family I'm developing which, fittingly, has a gothic variant featuring medieval glyphs aplenty (I believe I haven't implemented the ‘hist’ feature yet, but now that you made me aware of it, I'll most definitely look into that; thank you for mentioning it). So, maybe that font will come from yours truly. ;) Anyway, I'll let you know about my findings later on.
Well… As for the sub-panel collapsibility, my issue with it wasn't with finding out about it, but instead with reverting it. ;) That was the frustrating part, when I couldn't reveal one category after I accidentally (or was it deliberately, as a UI stress-test?) collapsed it, even though I was frantically clicking on its name tag and expecting it to work. So, even if you don't add a disclosure triangle, just having the whole sub-panel header rectangle be clickable would make the UX that much more friendly, IMHO.
I guess that pretty much sums it up for now… Good conversation we're having here; I'm really glad that you care about typography as much as your company's name implies. ;)
-
Hi Andy,
Great to hear that! And talk about a quick turnaround… ;)
Affinity Photo Public Beta (1.2.1.26106 RC1)
in [ARCHIVE] Photo beta on macOS threads
Posted
Hi guys! I've read a post by MEB about the RC1 coming out “next monday”… Is this the RC1? ;)