Jump to content

JGD

Members
  • Content count

    334
  • Joined

  • Last visited

Everything posted by JGD

  1. Yes, those are all valid questions. And then there are users like me, who would be [more] actively participating in the Beta if they only had the time. It's extremely frustrating, as an old-timer beta tester, to not even be able to really put the apps through their paces, but such is life (and I am certainly representative of the people who will buy this thing – and I will, anyway, regardless of how incomplete it is; I am treating Affinity a bit like if it was a Kickstarter project – because a) I already bought the other two, b) I've been using ID professionally for almost 10 years now and c) I don't intend on leaving the DTP market any time soon). As for feature dependencies… Sure, we don't know exactly which are dependent on which, but we can take some informed guesses. Seeing how Affinity Publisher is based on the same codebase as Affinity Designer, the internal support for variable page sizes (which should be just a different, more specialized implementation of artboards, after all) must be there already in some form, as should be the option of having more than two pages per spread. It should be just a matter of exposing it via the UI, adding a spine indicator and getting the pages to snap nicely to one another (and that's yet another area in which Serif could one-up Adobe; I've always hated how when you change some page's size, the adjacent ones don't snap neatly to it automatically, forcing you to break your spreads apart and rejoin them…), and while I can appreciate that it might take a while to implement, it should be an absolute priority for a self-proclaimed “professional” DTP app. Otherwise, when it comes specifically to page management, it behaves just like a glorified text editor, am I right? And the same goes for in-line, anchored objects… No self-respecting designer would start more complex projects in Publisher if that meant they would take even more work to do than even editing a Word document. That would defeat the whole purpose of using a dedicated DTP app, and would make the amateurs/prosumers default to Word/Pages and the professionals default to InDesign/Quark. That's why this thread is so important, and why I'm guessing at least this feature in particular will arrive in time of the 1.7.0 GM release.
  2. It seems this has been discussed at least in a different post already. Is it just me, or these requests should be compiled into a wishlist and voted on by the forum goers in order of importance/priority? By the way, I second the motion. I used this way too much in the past to be able to forego it (can you believe that for a while I didn't know it was possible and I moved objects in InDesign by hand? Aha, fun times… but no, I'm not going back to that ).
  3. Steven, you should change the thread name (if you still can) to include these two features in a more visible fashion, or at least add them as keywords; I was about to post something similar and I had to scour the forum and take a leap of faith just to find your thread. To all the Serif devs out there in the forum, pay attention as they are absolutely essential. I used both of them for the same client, every year. Without them I just couldn't use Publisher for those projects, I'm afraid. By the way, while you're at it, please come up with a better name than “Allow document pages to shuffle”; that has got to be the stupidest, most unintuitive name in the entire history of DTP software. By the way, I must say I don't really like the default, continuous page view instead of the more sensible and intuitive spreads-aligned-along-the-spine view; the default should be the latter, and if you think about it, it's also the only view in which that option would be usable (otherwise, you would have to add centre/spine lines to each and every separate spread, don't you think? That would make it look a bit cluttered, if you ask me). In fact, if you got rid of the continuous option altogether, I don't think many people would shed a tear (it would probably be useful only for vertical spreads, I'm guessing, and perhaps you could even have a horizontal mode for the pages panel, or just allow it to stretch infinitely along the horizontal axis). While I'm at it, the maximum page thumbnail size is still a bit too small for my taste (I'm using a 27'' iMac, plus an external screen where I have all my panels, so space is definitely not an issue), and perhaps you could have a continuous size/zoom slider instead of discrete thumbnail sizes? I will also add to them another big one, which is directly related to the first: variable page sizes. I used to use this one a lot for book covers, for a different client (and even once at the company I worked at, now that I think of it), as they allowed me not only to do the cover flaps as separate pages (which would also allow for, say, easily exporting just the book cover to send to the author, to upload it to a website or social media, or whatever), but also to customize the book spine width as per the specifications the print works sent me usually very late in the production cycle (I was working on a collection, and the spines would all look the same but their widths would obviously vary unpredictably from one volume to the next). I will finish my post with the inevitable question, because these three features are really that important: do you guys have any ETA on them? Can we expect them by the 1.7.0 GM MAS/Serif Store release? Or will they come out further down the line? Because there's really no way around them (and no, using Designer for some of those projects instead is not an option, as it starts getting reaaaaally sloooooow when you get into ersatz DTP territory; also, forcing people who may want to do an entire, more complex book to buy Designer just to be able to do the cover – especially if the artwork is done by someone else – or to have to deal with separate files – a cumbersome workflow that used to be the norm until a few years ago, when Adobe fixed it by adding that feature to InDesign – isn't very nice, either).
  4. Hi all! I am writing you not as the usually nitpicky and potential Affinity-fanboy-who-lives-off-of-Publisher (I do currently live off of InDesign, so it would be only a matter of time, but things just may take a bit of a turn in my career path soon-ish), but as a prospective full-blown professional type designer and current type design teacher with some serious grievances to air; as you may guess, I recommend Affinity apps for most graphic design related tasks, and even though I vehemently tell all my students to familiarize themselves with type design packages (namely Glyphs.app, FontLab, RoboFont, etc.) and start drawing inside them right away, they are all more familiarised with all-purpose vector drawing packages when they begin studying type design, so, for those who may wish to go that route, I also make a point of explaining to them how to properly size their curves/paths in points, in order to correctly import them into Glyphs.app further on. Now, this usually works fine when using Adobe Illustrator, but when doing so with curves/paths drawn in Affinity Designer, some less-than-optimal results occur, as you can see from the enclosed screenshots. The result will always be the same (on both apps, mind you), either if I paste the curves/paths directly or if I export them into .EPS and import them into Glyphs (actually, Glyphs won't even let me try the latter – and gives me the enclosed error message, whereas .EPS content generated from Illustrator, whether pasted directly from the clipboard or dragged into Glyphs, will work just fine). If I export it from Affinity Designer into .SVG I will be able to import it into Glyphs.app without any missing nodes, but the scale will be way off, thus making the whole process needlessly complicated. I happen to be acquainted with Mr. Rainer Erich Scheichelbauer, from the Austrian type design studio Schriftlabor and the Glyphs.app development team, and I can put you guys in contact with him in order to work on fixing this issue. As for the recently released FontLab VI, I don't own it so I can't get into the compatibility with it for the moment in any authoritative fashion whatsoever. I did give their very feature-complete and stable public beta a go, however, and it seemed the interoperability was even more broken, so maybe you should chime in with Mr. Adam Twardoch from FontLab Inc. on that issue as well (though I'm guessing that FontLab's even more advanced curve/path drawing tools and its focus on über-pros – their app is expensive as hell, after all –, combined with their still less-than-elegant usage of – ugh – Qt, may mean that they don't care much about those interoperability niceties and would rather force their users to always draw inside of FontLab from the get-go). As it stands, Affinity Designer in standalone form (I have yet to test InkScape as a bridging app, but… I'd rather not, as it's even more cumbersome than AI) is completely unfit for type design purposes with Glyphs.app and, as such, I can't recommend it to my students at all, which is a pity because the price bracket and the target audience of both packages seem to be very similar. Do you have any insight as to what may be going wrong here (a non-standard/reverse-engineered or even standard and well-documented .EPS and .SVG implementation, just a bit gone wrong, perhaps?) and could you provide us with a tentative ETA for its resolution? Now, for some explanation on what each of these screenshots mean… Here we have the original outlines, all nice and dandy, without duplicate nodes or anything: And here we have the result of copying said outlines and pasting them directly to Glyphs.app and, as you can see, the scale is indeed correct but we're missing one node: Now, if we try to export a file into .EPS using Affinity and import it into Glyphs.app, we get this error message: Surely we'll get better results if we try using Adobe Illustrator, right? By opening the .EPS file in AI and saving it back, also in .EPS format but with a different name, and importing it into Glyphs, here's what we get, and indeed the results are better, as we get the correct scaling and all the nodes (plus some extraneous ones on the same place where Affinity Designer defined the first/main/closing nodes to be): For the sake of it, let's try saving both .EPS files, in their respective apps, into .SVG format instead and import them back into Glyphs.app… The result on the right was from the file generated in Affinity Designer, and the one on the left from the file generated in AI and, as you can see, AD got the scale way off but finally all the right nodes, whereas AI gave us the same result: Interestingly, if we copy the paths from the .SVG file generated in AI from the .EPS file exported in Affinity Designer and paste them directly from AI into Glyphs.app, we get the best results yet: So, all things considered, it seems the best course of action is to export the artwork in Affinity Designer into .EPS format (and not directly into .SVG, because, as I've just found out and pointed out in the thread title, Affinity Designer seems to mess up with the scaling factor when exporting into .SVG), then opening it on Adobe Illustrator, then saving it into .SVG format and, only then, directly copying it and pasting it into Glyphs.app. It's an effective but extremely convoluted process, which forces you to use AI anyway and kind of defeats the whole purpose of switching to Affinity Designer… :\ For your reference and… forensics, I guess, I am also enclosing the files used in the course of this test: p (generated with Illustrator from the EPS generated with Affinity).svg p (generated with Illustrator from the EPS generated with Affinity).eps p (generated with Affinity).svg p (generated with Affinity).eps test.glyphs
  5. Ahh, you see, this is where I believe Apple, Google and Microsoft may play a hand… All three offer the main operating systems (and, hence, the APIs) currently in use today, all three have decent typography departments (though I still have some doubts about Google Fonts and Google's commitment to typography and type design… Actually, I have serious doubts about their commitment to anything, as besides being positively evil sometimes – unlike their stupid and telling motto professes –, they are the masters of vapourware and killing off popular products at their prime – *cough* Google [RSS] Reader *cough* – just because they can't extract enough money from them), and at least two of them (Microsoft and Apple) partnered in the past to create an interoperable format (TrueType) which basically finished off what Bitstream started (by reverse-engineering the very Type 1 format you've mentioned) and definitely robbed Adobe out of its monopoly on decent, easy-to-use digital typefaces (Kinross, R. – 2004 – Modern typography: an essay on critical history, pp. 170-2). If these three heavyweights end up throwing their support behind a decent format (would that be OT 1.8, then?), and if you get proper variable font support on the new 800lb gorilla in town (iOS App Store+Mobile Safari), well… it may very well turn out differently than QuickDraw GX (a nice format on a niche OS) and Multiple Masters (a nice, but utterly proprietary format). One can hope! [Yep, I know it's been over a year since the last reply in this thread, but I've been reading a lot about this subject recently for my MA research… Back then I didn't know precisely how things went “back in the day”, but now I get it: Adobe has been trying in earnest to advance digital typography since its inception, yes, but always in an extremely closed and self-serving fashion. Some things never change, I guess…]
  6. Hi guys. Maybe this has been mentioned before elsewhere, but I find the Tab shortcut behaviour on the Transform panel to be complete nonsense. The field selection order shouldn't be an absurd from left to right, top to bottom (i.e. X position > Width > Y Position > Height), but instead a more logical from top to bottom, left to right (i.e. X position > Y position > Width > Height). The way it is, it feels a bit broken whenever you feel the need to manually input values. And it should't take you more than changing a line or two of code to fix it, so… maybe you could do that for the next release? Thanks! Edit #1: Even though the “constrain proportions” link-thingy button is, indeed, selectable via tab (and, very logically so if I may add, after all the others), I just noticed that the Rotate and Skew fields aren't. Also, having the “Tab to hide the Studio” shortcut activated instead of cycling from the last field back to the first one doesn't make much sense and isn't very friendly, IMHO. Edit #2: I've just noticed another thing: In fact, the Rotate and Skew fields are indeed selectable via Tab. And you can tab from the Skew field to… the X position field?? This means that even though those two fields are visually on the bottom part of the panel, if we consider the whole “Tab to hide the Studio” thing, they seem to be coded as if they were on top. Which actually makes it a bug/error/oversight on your part, oopsy-daisy. But the best solution would be to not only change the ordering and getting rid of that cycle-breaking behaviour; that way, it wouldn't really make any difference. Edit #3: It gets even weirder still. If you press Shift-Tab instead of Tab, you can infinitely cycle backwards (as it should be, anyway) through the panel fields… So, did you actually hard-code that break when tabbing regularly on purpose?
  7. I'm writing here as well to bump this thread. I really, really do not like this behaviour, as it feels more like a bug/baseless limitation based on a wrong choice by the Serif team than any of the other quirks in Affinity apps. Check this post for details:
  8. Hi! I just wanted to chime in… Even if you don't change a thing on the way AD treats artboards and layers, this feature (being able to toggle “Clip to Canvas” in multiple-artboard documents) absolutely must become available at some point in the future. Even if things may look a bit messy in certain documents, because of artboard positioning, that should be our choice to make. This modal logic that determines that a document can be in either single- or multiple-artboard “mode” (and it's an invisible mode, at that, not like your well-thought-out personas), with different tools available depending on which “mode” you're in, adds unnecessary complexity and makes the app feel a bit broken. And I'm not using the word “broken” liberally here; having access to objects that extend past the artboard edges, even if temporarily, is of paramount importance; how else are you supposed to be able to easily select (and drag) objects that may have only a smidge inside the artboard? But wait: it gets worse. I was playing around and reading the forums here, and I found out a few things about AD that left me utterly dismayed. I understand that you can still make objects visible, even with the “Clip to Canvas” option grayed-out, by dragging them outside of the artboard they're in in the Layers panel, but then they won't export because the corresponding slices will be empty… even though it doesn't seem like it visually; when looking at the working area, the artboard/slice will seem to have content, but only after exporting the files or by looking at the layers panel thumbnails will the user realise they are, in fact, empty. In my book, this is a big UX no-no. It feels as if AD is working against you, in a quite frankly illogical fashion. Yes, I know it makes sense from a database/file structure standpoint, but from a visual standpoint it's a mess. So… artboards are these transparent, diaphanous entities that allow objects to show through, but unless you manually specify on a panel which ones belong to them, they won't show up when exporting. Are we working with a modern and supposedly WYSIWYG vector app with full PDF and pre-press support, or with AutoCAD ca. 1992? Also… is there any replacement for artboards in AD, as in a proper slice tool that actually slices things in half but still shows up on the Draw persona? Because it seems you can't really slice an object between two adjacent artboards, as it can only “exist” on/belong to either one of them. That turns “Slices” into a bit of a misnomer when applied to artboards… I hadn't done any complex, multi-artboard documents in AD before, but now that I started trying that out I realised just how limited AD is and… to be honest, I feel a bit cheated. Ai's implementation, all with two different panels, may feel cumbersome (I mean, all of Ai *is* cumbersome, the whole thing), but AD's implementation seems dumbed-down and broken by design. Lumping artboards with objects doesn't really make much sense if you think about it, and having your objects jumping around in your Layers panel without direct user intervention in said panel (that isn't creating, deleting or locking objects) is a big, BIG UX no-no in my book as well. If I'm working on a complex multi-layer document (like, say, a map or a diagram), already spent quite a bit of time grouping objects into different layers, and need to use artboards/slices for some reason, that will completely screw up my workflow… I can either fight against AD by duplicating all my layers, moving them to the new artboard, etc. etc., or just cave in, fire up Ai and get it done in ten seconds flat (basically the time it takes to press Shift+O, select an artboard size and place it where I want it) and, even accounting for its excruciatingly slow opening time, I will still get it done faster (and in a cleaner fashion, without having to expand the file size and complicate it further with all the duplicates) than in AD. I understand that you wanted to make artboards into “mini-AD documents” inside of a bigger AD document, but shouldn't users be given some kind of choice on how to use that feature? I honestly don't know how you can fix this and make AD more flexible without having to completely rework certain technical and UX assumptions (which might also break other people's workflows and documents). But, IMHO, I think you've screwed up royally with the multiple artboard implementation, as it feels extremely counter-intuitive and, frankly, useless for a sizeable proportion of your current and/or potential userbase. Please add a different type of artboard-like “thing” that doesn't mingle with (and screw up) layers, if you will, because these artboards, as they stand now, are utterly broken. Freehand (and even – *GASP* – Ai) got it somewhat right, so there's no reason AD shouldn't as well. Even though I have strongly complained on occasion about the lack of certain features in AD (I still think the Option+drag duplication behaviour feels wrong, and I still miss the option to have an object snap to its nodes on the “ghost” of its original position when dragging) or AP, I never thought I would ever write this on such strong terms: I believe you've out-Adobe'ed Adobe on the unintuitiveness department on this one. Come to think of it, you were probably thinking illustrators and web designers would appreciate your approach, because it is indeed orderly and saves on panels, but I think it is too much left-brainy for either group, and especially for print designers and students (that may need to do certain imposition jobs by hand and absolutely need proper slice support for those). It really forces you to respect an excessively rigid hierarchy on the layers panel that both adds unnecessary extra steps and may not even make much sense from a functional standpoint. Philosophically speaking, this reminds me of when Apple decided to remove the ability to have windows spanning different screens because of the revamped Mission Control. The difference being that they more than made up for losing that ability, because that multi-desktop system now feels tighter and more intuitive than ever. I mean, should you even be able to have part of a window overlapping a full-screen app? And how could they reconcile multiple virtual desktops with multiple screens? They did the right thing, IMHO, because they had to contend with two levels of 2D complexity, one virtual and one physical, that conflicted with each other. On the other hand, having that kind of behaviour (i.e. objects that can't show up/exist on two different pages and be exported on both of them at the same time) on a WYSIWYG vector drawing app, which presents us with a single, rigid virtual 2D plane made of multiple content layers, makes absolutely no sense whatsoever. And considering different sections of that plane as different layers makes even less sense; if anything, if you really wanted to have them on the Layers panel and simplify the UI, they should all co-exist in a single special “Artboards” layer. Now THAT would make more sense. Your approach, sadly, turns something that should feel like an emulation of a physical working canvas into a… I don't know, a “Microsoft Windows 3.1's File Manager”-like thing, with boxes inside of other boxes? I'm really sorry for sounding so harsh, but… yep. I do feel cheated. I can't really use nor recommend AD as unreservedly as I thought I could. And I'm also sorry I hadn't noticed these limitations during the beta process, because I would've strongly made the case for a better implementation like the one I've just suggested. Anyway, if you want, I can send you some old multiple-artboard projects I did both on Freehand and Ai that would be nigh on impossible to make on AD (without getting seriously frustrated with your app, at least), with some context on all the workflow (including printing, trimming and mounting). If you are serious about print, you absolutely must try to fix this in some way. Even if you make slices accessible and visible in the Draw persona to make up for it (and yes, a user may wish to be able to work while seeing its slices, especially for planning around, you know, actual physical seams on the printed matter, without having to resort to extra guidelines and other fluff), I still feel that the route you've taken needlessly complicates using AD for daily, multi-artboard work. It is so weird and cumbersome that I actually considered using white rectangles and slices as faux-artboards to work around ADs implementation, really, but… oh, wait; slices can only be exported into raster files, not PDFs, so… yeah, you definitely have to fix this.
  9. Hi guys, Any thoughts on MPEG/Apple’s brand-spanking-new High Efficiency Image Format support? Affinity seems to be a logical choice for people who want to stay current on the latest and greatest standards, all with its fresh codebase and support for macOS-specific technologies… And let’s not forget about PC and iPad folks as well. Having Affinity support that format on all major platforms would greatly boost its adoption rate. What do you say?
  10. Thanks for the reference, Mike! I probably won't be reading those threads thoroughly, but I'll be sure to start at least looking at them regularly (and I'll read them in earnest probably as soon as I turn in my thesis in April, ha! ). Yes, I totally get the “herding cats” thing. And the whole being tight-lipped stuff, yep. Serif is, too, with their own tools, and it can only keep them safe for that long (just look at how Adobe has been blatantly ripping them off lately… Even the rounded corners functionality – but hey, at least I HATE those in Ai with a passion, as I can no longer select nodes on small zoom factors without accidentally selecting the corner-rounding handles instead more often than I'm willing to accept…). But surely you must agree that these guys could develop some of this stuff as proof-of-concept, to give their own clients some head-start on the type design process, with incomplete or semi-proprietary implementations on platforms like Adobe TypeKit, and we could, on our side, have at least the OS and non-Adobe design app guys (which aren't really competing on the type design tools arena) having a look at what's already available on most type design apps and standardising it afterwards and ASAP, no? And when I say “standardising”, I *really* mean standardising, not proprietary, OS-specific stuff like the AAT format (and I have much more faith in Microsoft, Apple and Google engineers sitting at a table to discuss typography than any of the other type design software guys, of course…). As for the GUI implementation being consistent or not, I mean… who gives a damn, really? Sad as it may be, I know I don't. I say, let them come up with solutions, and may the best become the standard. The money is really on getting variable fonts to *work* consistently across different apps and OSes, and I'd say that at least the rest of the OT features are a bit of a success in that regard… amirite? I'm not holding my breath either, but I'd be super sad if the guys at Serif, after all the accolades they've got recently, let themselves be left in the dust on this tiny (but hugely important) revolution. If anything, they should be at its forefront, even considering the commendable history Adobe has on typography… Actually, I'm wondering whether Serif shouldn't be teaming with some indie font developers to distribute their fonts permanently bundled with Affinity apps, and not just the temporary offerings they've made. Those would be a good differentiator, add more value to the apps and allow them to include samples typeset with said fonts, to safely showcase Affinity's (hopefully ever-improving) type tools across OSes. The only condition would be that those fonts would have to support the entire character set for the current localisations (except perhaps for Japanese, which would probably mean exceptionally higher bundling costs because of the thousands upon thousands of kanji it would have to include – fellow users from Japan: sorry! ) and a few OpenType features, to make them usable to most users and better than most of the free fonts you can find around the web. I'm not saying they'd have to include a metric ton of fonts like Adobe does, but throwing in a few cool ones just to get novice users started would be nice, yes. And having at least one variable font in the mix, if and when said features are implemented, would also be a no-brainer.
  11. You know what, Mike, I completely understand where you're coming from. I do some type design myself (mostly modular geometric fonts, but I make a point of making complete character sets including advanced OpenType features like discretionary ligatures and contextual alternates) and I'm now starting to give type design workshops to college students, first to my MA colleagues and, come next month, commercial ones to MA and BA students on the other school from my joint-MA programme… And it seems to be a wildly complex issue with many ramifications. We must get it right ASAP, lest we develop fonts into yet some new dead-ends (the old multiple-master fonts come to mind), or into potentially proprietary and/or undocumented formats (can you say “.PDF”? To this day, even though the format spec has been freely available since '93, there are still some compatibility issues; once again said spot-colour gradient turned into CMYK issue comes to mind). I'm mostly focusing on Glyphs both on my personal projects (hey, it's super cheap, much like Affinity apps, and I'll soldier on using Macs for the foreseeable future) and on said workshops (though I did give the FontLab VI beta a good look, as it's the only decent cross-platform offering right now, but I've since figured they are similar enough that PC-using folks can just follow the workshop on FontLab VI provided I explain them the [small] naming convention differences between them) and am currently in direct contact with Rainer Erich Scheichelbauer (who I've met last month on our annual national [Portuguese] typography meeting), one of its lead developers (the other being Georg Seifert, which I don't know personally but could easily get in contact with if I so wished). As for Adam Twardoch, from FontLab, I unfortunately never had the chance to talk with him, though my teacher, who I'm collaborating with on said workshops, did, and he was mightily impressed with the way they finally got out of their recent, protracted rut (mostly thanks to the Glyphs team giving them a swift and well-deserved kick in the nuts, I'm guessing). And you know what? I'd be willing to bet that if these guys, along with Frederik Berlaen from RoboFont, could cooperate amongst them and with Serif, Corel, Pixelmator, Sketch et al. to standardise on *something* and send Adobe and their TypeKit nonsense (I mean, it's not that big of a nonsense, it's actually a decent – or even cool – idea, but since it's tied to that CC albatross and will probably end up becoming yet another near-monopoly, I and many designers *and type designers* – and I happen to have a foot in both camps – won't touch it with a 10-foot pole) a big F. U., they probably and gladly would. All it takes is *some* goodwill from one or a few of these design app developers to tell the others, “you know what, guys, we'd like a typography framework for variable fonts – if you ask me, it could work a bit like Glyphs internal variable component feature, and also like its multiple-master interpolation feature, in addition or to or in combination with the multiple axes you've mentioned – as cool as or even cooler than Adobe's, can you come up with one for us? And make it open and well-documented, while you're at it”… That's how I think it should be done, in a concerted effort to move the market as a whole forward. Heck, throw in the big heavyweights like Monotype while you're at it: they would have a blast competing against TypeKit and pushing their FontExplorer X Pro font manager and integrated font shop… And I'd love to see Serif, the new guys in town going against the 800lb gorilla (hey, they remind me a lot of the Glyphs team going against FontLab, now that I think of it), be the ones to kickstart the whole thing. One can dream… but guys, seriously, please surprise us. I for one, am more than willing to do my part and bridge that gap.
  12. Just a teensy little bump to this thread… I'm guessing implementing the underlying frameworks needed for this format must be easier said than done, but it's something all kinds of users (be they designers/illustrators doing posters with loads of decoration who may wish to use some wild font like this: https://twitter.com/typotheque/status/933797656966717446 , or typesetters working on long, complex documents in the upcoming Publisher who may wish to have a finer control over their text styles) will have a use for, and… we mustn't forget this is a font file format we're talking about. Serif devs pride themselves in the wide, industry-standard format support offered by Affinity apps (and I'd venture to say the advent of variable fonts is a tiny revolution in the making and they will become an industry-standard sooner rather than later), and this should come way ahead than other tools in your list of priorities. People can always get around the lack of a certain tool by, say, using an older version of a CS app for a specific workflow (personally, performing image tracing in CS5 and exporting them to Designer, or re-doing spot colour gradients before exporting stuff to press come to mind), or by devising some other convoluted workflow inside Affinity apps alone, but not being able to use a format outright can be a deal-breaker for many people. Thus, not supporting these may equate to handing down potential clients/users to Adobe on a platter, I'm afraid. Then again, I'm extremely biased as I'm a Typography MFA student. But I'd still say typography and all things related rank (or at least they should rank) *extremely* high on most designers' priorities. On photographers' and illustrators', not so much, and we all know there's this weird oxymoronic dichotomy between Affinity Designer and Adobe Illustrator, wherein the former seems to be more geared towards illustrators (the strong emphasis you put on illustration in your choice of sample files is living proof of that – seriously, you only feature five files, “Edit '16”, “Artboards”, “Prison of Arts”, “Forma Playing Cards” and “Orbit”, which include typed text at all, and it's not much for that matter and on the last one, which is probably the one which features the most text, and on at least the other two before that which weren't set in Helvetica/Arial, it's all converted into outlines –, and perhaps you've even entered a feedback loop where you can't really get neat demos of graphic examples with text anymore because users aren't just submitting them or, worse even, creating them at all in the first place… or is that all on you and your curation? If so, if you do really have a choice, I feel it's a bit misguided to feature illustrations disproportionately, IMHO, and I'd be more than happy to submit some examples of my own, even if they have to be converted to curves, or even design some examples from scratch with web- [and OS-] safe fonts) and the latter more geared towards designers (even though they do the same with their splash screens, their type tools are now, much to my chagrin, second to none) and even wannabe technical draughtsmen (guilty as charged!), but c'mon guys, please honour your app's name a bit more.
  13. So this request is a follow-up to the one I made on this thread: Apparently, according to fellow forum user @toltec, this feature was already implemented, which is absolutely great. What is not so great, however, is its discoverability (or, in this case, its blatant [edit: partial] lack thereof). [edit: user @R C-R made me realise that the Status Bar already has a “cheat-sheet”/tooltip with said shortcuts, but I still feel that is not enough and that my suggestions are very sound, so please bear with me…] Please, for the sake of other users who may not frequent the forum or wish to spend hours perusing user manuals and tutorials (because this feature is, after all, something that pro users expect and may try for themselves [edit: even without, as was my case, paying any attention to the tips provided ], as it is a staple in brush tools not just in AP but also in other competing packages), make it [extra] visible and [even] more obvious. Basically, when pressing each modifier, please do make the appropriate tab (Matte | Foreground | Background | Feather) become temporarily highlighted/selected. This feature would, then, become easily discoverable to more seasoned users like myself, because as it stands, the UX feels “broken”. I mean, it will still feel that way to me even if I already know the feature is there, because visual feedback is just nice to have, as it shows that the app is working as it's supposed to. As it currently stands, you always display the same tab selection and, when pressing modifiers, you get a different, incongruous and non-explicit – even if completely desired – behaviour, which is indeed confusing, muscle-memory notwithstanding. It really is important for us to always have a “sense of place” when it comes to our tools. If I may offer another completely on-topic suggestion, I wonder if you could add some further visual feedback to the brush cursors themselves (and that would obviously be extensible to the Selection Brush tool), such as plus/minus signs floating outside of their outline (quite unlike their current behaviour in Ps – which centres them inside of said outline –, so as not to conflict with the cursor crosshair for those users who may have it configured to be visible)? I know that small as this suggestion may seem, it would add some visual clutter (I guess it could always be off by default and be selectable on the preferences dialog, just like the crosshair), but it I believe it would further enhance ease-of-use and differentiate AP from the competition. Thank you for your attention and keep up the good work!
  14. 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?
  15. Let me add my €0,02: expecting Serif to fully support all native .indd files is wishful thinking… But InDesign can currently export XML-based .idml format files (and used to export the equally XML-based .inx format files up until CS3), which should be easier to interpret or reverse-engineer by the Serif team. And since InDesign itself can open old files and most people who have a sizeable library of .indd files either have access to an older version of InDesign or can pay one month of an Adobe CC subscription without issue, converting all of your stuff from .indd/.inx/.idml to .afpub would be, in a best-case scenario, as easy as running a batch processing script. The only real issue I foresee with that kind of mass migration stems from Affinity Publisher's announced lack of a counterpart to Adobe Paragraph Composer on v.1.x; most of your converted .afpub documents won't look the same as the original (and they never would, even if and when Serif can come up with their own advanced typesetting subsystem) and will end up with a lot of overset text or other weird artifacts, I reckon… Personally, I do a lot of manual fine-tuning to tracking on a line-by-line basis to get rid of orphans and widows, so I'm dead sure most of mine would be (nay; will be, but I'm willing to live with that since I'll just be reusing layouts for new content) utterly screwed up after conversion.
  16. Ohh, I see… I had a suspicion I was doing something wrong. Thank you for pointing that out!
  17. (By the way, Apple seems to be lagging a bit behind itself with their own FCPX update, and it will take 10 years for most browsers to support those formats, so… do take your time. But I’d love to try them out on a proper DTP package sooner rather than later, if you know what I mean )
  18. Hi MEB, Cool! Weirdly, a search on the forums for “HEIF” didn’t produce any results… And I don’t lurk much on the iPad forums, seeing that I only own a 3G/Retina. Thanks for the heads up!
  19. Well, we'll have to agree on disagreeing. That would only make sense if the modifiers affected the action after the click, such as, say, the Alt-to-duplicate mid-drag operations on the Finder. In this particular scenario, pressing Alt does indeed switch to a different mode temporarily, and even though it sticks if you click and drag around for a brush selection, you absolutely must press Alt before clicking. Functionally, it works, yes, but the UX is *broken* because the UI does not fully reflect said changes as they are happening (and, no, as I said on another post, a tooltip is not enough to make it feel right *as you are using it*. Just because you, as a professional user, may get used to that, it doesn't make it any less broken). The right way would to give feedback be: press Alt, and the appropriate tab in each tool is highlighted; if you let go before clicking, it will revert to its default state, if you click and let go of Alt, it will still reflect their temporary state until you let go of the mouse/trackpad button, and if you don't let go of Alt, it will stay put until you do. Is this that hard to grasp and implement? It seems like a no-brainer, IMHO. Photoshop does this almost right (it isn't perfect because it only gives you the appropriate feedback after clicking, but at least it does eventually give you some UI feedback), while Affinity plainly doesn't even try to when using either the Brush Selection tool or the Refine Selection brush. This is one of those cases where Serif's attention to detail could very well allow them to, once again, one-up their competition.
  20. The title of the thread says it all: in AP, it would be nice if pressing Option toggled between one of the two additive selection brush modes (Matte or Foreground) and the subtractive mode (Background) in the Refine Selection dialog box. It's just that having to move the cursor or the pen back and forth just to change the selection mode gets rather tedious quickly and breaks the flow. Also, while on this subject, it would be nice if one could do further refinements without screwing up with other parts of the selection, but maybe it's just my workflow that isn't properly set up. Please bear with me, as I started transitioning to Affinity Photo in a production environment only very recently, and for now only when the tools I need are superior enough (the Refine Selection brush being one of them). IMHO, the greatest thing ever would be being able to just use the refine selection brush and the refine selection parameters independently of one another (or being able to undo them in separate steps in History), in order to achieve the most perfect selection possible. If only there was a way to use the brush without applying any effects, or certain effect slider values in said dialog box that produced zero changes and allowed me to refine the selection in many independent passes and apply said effects only when I was completely satisfied with it, I'd be a happy[ier] camper. That being said, the tool as it stands made one heck of a difference in a self-initiated emergency change, on a crazy-ass deadline (I could never have finished that in time using Ps, that's for sure), I made for a big project I just finished last month; I basically treated a landscape shot, which was used as the main theme on all media for an arts festival, in order to change the orange-y colour of the background clouds to a more neutral blue-gray independently of some trees in the foreground, because our country's forests had just started burning earlier that day – and have been burning almost continuously for a while now –, as leaving it untreated could mess with some people's sensitivities because it looked waaay too much like the photos and videos of said deadly fires circulating on the media. The only reason I didn't send this photo to you for your recent call for professional work done with AP was the fact that I do not own the rights to the original, and even though the author retroactively authorised the modifications I did to it after I explained him my reasoning behind them (I mean, given how serious the situation was, how could he not?), he didn't seem all too happy about the whole thing at first (especially considering that I did that on a rush, the night before sending that job to the print house, without consulting him first – I obviously negotiated it with our mutual client, which can ultimately propose and decide that kind of stuff at its sole discretion, but still), so I didn't even consider asking him for permission to share it with you. But anyway, I digress; Affinity Photo and my loyal Bamboo tablet saved the day and made doing this on a single all-nighter possible. Just to think that I could have saved some 10+ hours of work in a similar trees-vs-background selection task I did back in 2013, for the very same client, if only this app was available back then makes me value it even more because I now know how much more time I'll be able to save in the future… But I also know for a fact and from experience that I could save even more time if you implement that toggle shortcut.
  21. Well, I'm running the Mac version, and I just checked on that. My bad, it really does, and thanks for pointing that out! I guess I was just distracted, maybe because of all the pressure I was under while doing that job. However, I still stand by the suggestions I made on this and the other thread. Though the “cheat-sheet” is indeed there on the status bar, I still think that the selection mode separator should reflect which modifier is pressed. And some sort of iconography next to the brush cursor outline would be a nice plus, too.
  22. Well, what do you know, @toltec, you are absolutely right! Thank you for your feedback! But now comes the hard part for Serif devs, who are never exempt from my cutting criticism. The feature is there, sure, but the UX is just disastrous (and that's why I was a bit skeptical at first about your reply, sorry ). It is not in the least bit discoverable, as the toggle *is not visible* to the user. It just magically happens behind the scenes with zero visual feedback. If the team had implemented that small but crucial detail, I would have found out immediately that pressing Alt was doing what I expected and this whole post would be moot. So, I'll either change the title of this request accordingly or, if that isn't possible, create a new one. [Edit: I went for the latter option; you can follow the new topic here: Make Refine Selection modifier-activated toggles visible to the user ]
  23. Oh really…? Well, the last option seems to be just what I was looking for. Let me just check on it…
  24. I have to add something else: I know Affinity is being heavily sold towards UI designers and digital illustrators, so having digital screen presets makes sense, but it is also a print-geared app… It would be nice to also have print-sized presets (DIN A-series formats, US formats, offset formats – 50x70 cm, 70x100 cm –, etc…) and maybe have Affinity only show the appropriate formats depending on colour mode/document preset (as in “Print/Print (Press-Ready)” vs. “Photo/Web/Devices” and/or RGB vs. CMYK). If a user is working in a mixed media project demo for a client (such as a corporate identity that includes both printed stationery and UI mock-ups), switching between presets would be a minor inconvenience, but the net gain for most users when working in most projects (in which the print-bound and screen-bound artboards would probably be segregated anyway so as to allow the assignment of the proper colour modes and profiles for each use case) would be great.
  25. Hi guys! I just detected a general bug in Facebook Messenger, while opened in Safari, but in the process of trying to troubleshoot it I also found that Affinity Photo is also affected in other browsers. So here goes: When using Facebook Messenger under Safari 10.0.3 running on macOS Sierra 10.12.3, pasting content copied from Adobe Photoshop CC 2017, Affinity Photo 1.5, Preview or even the integrated screenshot engine (by using the Cmd+Ctrl+Shift+4 keyboard shortcut) into the input fields on either the Facebook Messenger page or the chat windows on the main page is impossible; the “Edit” menu will flash, as usual, but nothing happens. However, when performing the same task on Google Chrome 50.0.2924.87, also on macOS Sierra 10.12.3, it works for all the aforementioned applications/sources except for Affinity Photo, so I initially thought the issue might lie either with Facebook Messenger's website code or Safari's application code, and that Serif's software wasn't also supported in Chrome for being too recent or something. I also realised when using this very input field, under Safari, that I could paste content copied from all the aforementioned sources (including, yes, Affinity Photo), but not under Chrome, so I am now convinced that the issue lies specifically with Facebook Messenger's website code AND Chrome's application code. So I've found two different bugs/insufficiencies in one go. I obviously gave feedback both to Facebook and Apple before (and will do so to Google shortly), but I believe Serif developers should contact the Facebook and Google Chrome teams directly, as Messenger doesn't seem to play nice at all both Safari and Affinity Photo, and Chrome doesn't seem to be very compatible with Affinity Photo either.
×