Jump to content
You must now use your email address to sign in [click for more info] ×

JGD

Members
  • Posts

    516
  • Joined

Everything posted by JGD

  1. Since I've already expanded a lot on the subject on my last post, I'll keep it short and to the point: Affinity apps almost completely disregard the macOS system-wide option “Full Keyboard Access: In windows and dialogues, press Tab to move keyboard focus between: All controls”, in the Keyboard prefpane. In fact, they don't even honour the alternative and default “Text boxes and lists only” on all places, which would include the very useful input fields on many different palettes. There are issues on important dialog boxes such as “New Document”, and the only palettes where fields are properly addressable via tabbing are, AFAIK, the Transform palette, and only partially so. Some allow for tabbing between one or two items, and all of them, regardless of the number of fields, drop the user into the “Tab to hide the Studio” behaviour, instead of cycling back to the first field like in Adobe CC. This behaviour is, for lack of a nicer term, undesirable and unintuitive, and I could also reproduce it in the Windows beta of Publisher; seeing how I can also reproduce it in the MAS versions of Photo and Designer, I'm willing to bet that it's also reproducible in the release-quality Windows versions of those as well. I also noticed input field and UI control ordering inconsistencies between the Mac and the Windows versions of Publisher. I am aware that fixing this would require an overhaul (or at least an internal review process) of six different codebases across two different OSes (though the fact that some palettes and dialogues are rather similar across apps, so there should at least be some economies of scale at work there), and introduce further overhead in your development process from now on (because it does indeed require a change in philosophy, as tabbing has up until now been added just as an afterthought and only in the places where we specifically asked for it, instead of everywhere, organically and by default, following a predictable scheme and behaviour), but this is yet another thing which I believe you also must do in order to be taken seriously by design professionals who actually use your apps for UI and UX work; you must lead by example, because many of your users will know a lot about that very subject. For the same reason, Adobe was the butt of all jokes for the better part of a decade on account of their lack of polish and consistency (there's even a Tumblr page called “Adobe Gripes” [formerly “Adobe UI Gripes”] dedicated to their misgivings: https://adobegripes.tumblr.com ), but even they got their act somewhat together as of late (there are still inconsistencies between different apps of their suite, but at least most of these nitty-gritty UX issues are pretty much solved by now). Seeing how you're still in the beginning of your expansion in the market, and only have 3 apps in two platforms to contend with, please take the opportunity to polish all of them before the arguably momentous 1.7 release, which will mark the completeness of the originally announced Affinity 1.x suite. All eyes will be, then and once more, on you, and some reviewers will possibly go through all those details (maybe even making brand-new reviews of the original first two apps), and call them all unpolished or unfinished. I know I would, because that's the way they feel, at least on this major point in particular.
  2. Well, let me put it this way: I know it is a bit hit or miss, but consider the following: 1. Apple does it right; 2. Adobe does it right; 3. It's something that when activated on macOS, makes it behave a little more like Windows (something that would please a user like @walt.farrell, for instance, and which makes the Mac so much better and quick to use for me); 4. Seeing how both Adobe *and* Serif offer cross-platform apps (in fact, Serif started out as a Windows-only shop), and that tabbing is a pretty natural behaviour in Windows, it stands to reason that Affinity should behave well with keyboards and tabbing in particular. Is my reasoning a bit of a stretch? You see, it's also not the first time I find weird tabbing behaviours in Affinity apps, the earlier one being, IIRC, a completely inconsistent tabbing order in the Transform palette, which made inputting values extremely cumbersome and unintuitive. Oh, news flash: I just checked, and I realised that it's still not completely fixed (at least the ordering on those four fields is now correct, I'll give them that). You see, when tabbing from the “link chain” constrain proportions button, you can't get to the next field, Rotate, and instead hide the Studio right away. This behaviour goes completely against this system-wide setting, too. You should be able to not only tab between all fields and buttons in each palette, but also to the palette separators and even between other palettes from the same group… Not even Adobe does that (when you select a field and start tabbing, you get stuck in an endless loop between the fields available in that panel, even with said system-wide “All controls” setting activated, but at least Tab doesn't hide the Workspace), but hey, there you have another golden opportunity to one-up them at something. Also, while I'm at it (and even though I will probably create a new thread, or just bump one which I started on the same subject and which has been lying around dead somewhere in the forums for 2 or 3 years now, I still feel this other bug is completely relevant to the topic), I should add that the Separated mode still doesn't work properly; I'd love to be able to use it in Affinity Photo (in fact, I still use it in Photoshop), but Serif never got around to fix it and allow for docking the toolbar and toolbox, and/or at least prevent windows from going full-screen at all, zooming or even being dragged behind them, something which Adobe, Macromedia, FontLab, Microsoft, etc. etc. etc. got right more than 30 years ago (if that happens, you either have to toggle full-screen from the menu, or switch to a different app just to be able to access the window chrome)… Serif isn't adhering to the best practices from even the Macintosh 128K era! It's in these little things that their former Windows-centric background really shows, but please, oh please, if you're answering user requests (and said Separated mode was probably born out of one of those), at least polish them to… I won't even say perfection, but just basic usability. Actually take the time to learn how the Mac's original “floating window + toolbars + palettes” UX concept works, *and especially the zoom button*, and get the details right (if you have to fire up a bootleg Snow Leopard VM and install FreeHand 12, or Office 2001:mac, or FontLab 5, so be it… Oh, wait, never mind all that hassle; you just have to fire up Photoshop CC 2019, turn off the very prominent “Application Frame” on the Window menu, dock your stuff and you're all set, boom!, with a fully functional Separated mode for comparison's sake and reverse-engineering… and do try the zoom button while you're at it, please! Because having it duplicate a sort of “maximize” function is just useless, we might as well just use the regular full-window or fullscreen mode!), because some people, and some apps/workflows, really do benefit from that model (especially Affinity Photo, for obvious reasons; in fact, we'd be better off if Serif just killed Separated mode in the rest of the suite and concentrated just on getting Photo right). The same goes for keyboard support, I guess, and here I speak as a former PC user who actually values the competition's effort in keeping the software as close between platforms as possible… IMveryHO, your (@Old Bruce's) way to go about OS-level features and Beta testing is completely lenient and backwards… I know I border on the obsessive and sometimes even on the aggressive with my nitpicking, but surely we should expect developers, especially self-proclaimed user-friendly ones and to whom we already gave our hard-earned money (maybe it's not your case, but it's certainly mine), to adhere as strictly as possible to Apple's HIG, am I right? Why make excuses for something which shouldn't be that hard to code correctly? This is not a full-blown new tool, or something that messes with the graphics engine and dependencies or whatever, and it's not some obscure accessibility setting either; it's actually just plain adhering to a top-level OS-wide setting which affects a default input method that makes a Mac or a PC, well… a Mac or a PC. In fact, I'd go even further and say that this is the kind of thing that should also be available on the iPad versions of Affinity apps or the upcoming Photoshop for iOS… I don't even know if you can tab between interface elements on iPad apps, but since there are first-party Smart Connector keyboards and built-in first-party and third-party Bluetooth keyboard support, complete with support for some system-wide keyboard shortcuts (yes, with a Command key, just like on a real Mac), you definitely should. Face it: keyboards may be archaic as hell, but they aren't going anywhere any time soon. Now, some final considerations on the reasons which may be behind these issues… I'd venture a guess and say that it all comes down to the usage of custom interface elements, and a desire to keep the interface as close as possible on both the Mac and Windows sides of things (which, as you'll soon realise, it's not a fully achieved goal by default on Publisher, either; I have yet to test it on release-quality software, but I'll be sure to run a trial of Photo and Designer on a fresh VM just to check it out), and the usage of not entirely native/first-party frameworks as they were conceived (I'm talking about Interface Builder and default Aqua interface widgets, specifically, and its equivalente Metro counterparts in Windows). Interestingly, when tabbing on the “New Document” dialog on the Windows version, you can't even get to said button, you also get to a phantom field which triggers nothing when pressing space (in a different ordering… but maybe it corresponds to said button, only it doesn't work?), and you can indeed get to the lower fields, too, but never to said middle separators, either… In addition, the ordering on those lower fields is also different, and it makes less sense than on the Mac version; whereas on the Mac, you get from the two Width/Height fields to the “Portrait” checkbox and, only then, to the DPI field with drop-down button, on Windows you get straight from the Width/Height fields to said DPI field and, only then, to the “Portrait” checkbox. You see, consistency across platforms is also key (pun unintended), especially considering how Apple doesn't produce certain devices like the Surface Pro, or easily upgradeable desktop computers, and some creatives may indeed end up working with a mix of both iMacs and Surfaces, MacBooks and PC towers, etc. etc. Those users already have to deal with the nightmare of different shortcut triggers by default, so let's at least spare them the indignity of those inconsistencies, minute as they may seem…
  3. Hi guys, I know I'm probably in the minority here, but as a former longtime Windows PC user, all my Macs get the "tab between all elements” treatment (using the Ctrl+F7 shortcut), and I'm the master nitpicker when it comes to finding inconsistencies in the tabbing implementation because I happen to use the Tab key *a lot* (that's also what having two big screens and losing your mouse cursor a lot on a daily basis, even with El Capitan's “shake cursor to enlarge” function, does to you). This time, I realised two things: 1. When tabbing between fields and interface elements in the “New Document” window, I can never get to the four separators on the bottom half; 2. The little “Presets” button, with the four horizontal lines and the down arrow and to the right-hand side of the “Page Preset” drop-down menu, is never visually highlighted, though it is indeed selectable; also, when pressing the spacebar, the corresponding menu will not open adjacent to said button but underneath wherever the mouse cursor is; furthermore, this behaviour is reproducible in all Beta Affinity apps. So, yep, that's about it. If I can reproduce any of these behaviours elsewhere in Publisher, I'll let you know.
  4. Count me among those who also think this is a must-have in a pro-level application. GREP styles saved my proverbial derrière in more than one InDesign project already…
  5. Oh, by the way, kudos on the Preview mode. Is that new in the .145 beta? I was about to point out that it would be a nice to have, and just noticed it's there, yay! And… do you reckon you could do away with having to press the Control key and just be able to press W to toggle it, or is that a requirement because of the way Publisher is coded, an over-zealous adherence to the HIG or some other factor (like… not wanting to ape Adobe too much ^^ )? I know, I know, but… you know, muscle memory and not having to use my pinky so much… First-world problems!
  6. Hi @MEB, obrigado pelo update [thanks for the update], and you're welcome; I do my best with the little time I currently have. Not having ETA isn't the best of scenarios, but knowing you're taking our concerns and expectations seriously is way more important than that, and it's very good to know you are. As for those concerns and expectations… I was never suggesting that Publisher could ever replace InDesign for all, or even most of the use cases in its first commercial iteration. I only hoped that much like Designer, which I can use for almost everything except auto-tracing, 3D effects and projects which require gradients and transparencies with proper spot colour separation (yes, my exclusive use cases for good ol' Illy are now that much limited, and the only reason I don't use Designer for 90% of my work right now and use it instead mostly just for RGB stuff that requires gradients is the fact that, well, Publisher isn't officially out yet – or feature-“complete”, for that matter – and I want to switch to the entire suite at once, because of the obvious economies of scale). The thing is, as things stand, I can't use Publisher even for the most basic of projects without feeling I'm fighting against it and, in a sense, “losing” money because of wasted time. None of my usual projects are especially complex, by the way… It just so happens that some have dozens of pages, others are smaller but require multiple pages per spread, and pretty much all of them require object linking. And I'm not some über-elite designer doing exotic stuff, just leaflets and booklets for events, not unlike the ones I did at the company I worked for previously. Let me tell you, it's all very mundane stuff, really. Pardon my cheekiness (especially any old-time Serif customers reading this), but it seems that… PagePlus could be used for way more serious stuff but was bought mostly by people who just wanted to typeset their local church newsletter (maybe because of marketing, maybe because of the way the program was laid out, maybe a bit of both; I can't really tell because I never used it, but I did give it a look on your old website before I wrote you that prescient long-ass letter after Adobe threw their CC-only strategy at us, and it seemed to be a bit of both), whereas Publisher is being marketed as being suitable for more serious stuff (come on, man, read your own marketing materials when it comes to Affinity as a whole and Photo and Designer in particular; it is being aimed at pros) but is only good… for typesetting the local church newsletter. And it will still be hard to use and not exactly educate users in DTP's best practices, because of the reasons I've stated. Maybe part of your audience (and even a number big enough to recoup development costs) doesn't know any better and will lap it up, but you won't get as many [happy, satisfied] switchers from InDesign as you've got earlier from Photoshop and InDesign, that much I'm certain of. And that might in fact tarnish your reputation to a certain extent, especially among pros (which, for a change, have been taking you seriously; just compare the kind of coverage you've been getting to that of Pixelmator, Sketch, etc.). You know, as they say, never overpromise and underdeliver, and even if you don't do so on an official and ostensive manner, the very existence of Photo and Designer with the “Serif” label on them is, in a way, a form of “overpromising”. Publisher isn't exactly being marketed as “Publisher Elements” either, now, is it? In fact… Now that you've shown your hand, and haven't yet revealed any novel feature which Adobe might copy (good on you, really; the last thing we want is for them to rip you off, like they did with the corner tool), you would do better to keep this as a public beta for as long as you need until those three basics (global layers, proper masters and linked objects) are implemented (sure, multiple and/or differently sized pages per spread could certainly wait a bit longer, I guess; after all, InDesign didn't have those for years, either). We're not asking for anything very advanced, just the absolute basics. Please listen to your professional users, as we do have your best interests at heart (if anything, because it will also benefit us in the long run). And yes, that takes into account the fact that we had to wait much longer that we initially thought for the public beta to come out, but at least now we know why, and we know at what point in development it stands (as a matter of fact, I believe it should still be in internal alpha/beta, instead of being rushed to the PB stage)… If you try to charge (even if it's an extremely affordable price, yes) for a manifestly incomplete/unusable product, I'm afraid pros and reviewers alike will pile on you, no matter what you state in your forums or press releases, because Publisher will always be compared to your previous successes. In a weird twist of fate, Serif is now its worst enemy, more than Adobe itself. But yes, @tariq is absolutely right, transparency is key, and we can't fault you for not being transparent enough right now. Delaying the release but having an ongoing public beta will keep all your users entertained and content, and buy you more time (and heck, this wouldn't be the Duke Nukem Forever of creative software, now, would it? We know you have sound internal goals and management, and a fine team…). In fact, I'm sure most wouldn't mind to see some delays in Photo and Designer development (hey, where are our customer betas!? Just kidding… ) if that meant that Publisher came out “right”. My/our €0,02…
  7. I am now a bit more at ease by reading this, as it seems to at least address some of the similar concerns I voiced on a different thread. While I'm not in the least bit happy about the current situation, at least this is confirmation that addressing it is indeed on the pipeline, and that it is already technically possible. MEB, can we please get an ETA or some stronger commitment on this feature (in its final, usable form, at least, and it shouldn't be too different from how it works in InDesign or Quark; and allow me to elaborate: there should be an intermediate state where you could “unlink” objects in order for them to accept content placement, – and as for content flow, it should indeed be automatic with no “unlinking” shenanigans –, but they should still be “linked” in the sense that they would reflect changes done in the corresponding master pages)? It's just that I won't be buying Publisher nor recommend it until it is implemented it – it's unusable and an outright joke without it –, and I'd rather know your timeframe than having to check the forums every other week. [Edit: I have just tested what you said, and two things became self-evident: one, I can't seem to find a way to unlink said objects, and two, your master pages are “master pages in name only”. The objects contained therein are indeed… symbols, of sorts? I can't click on them directly with the selection tool, but if I select them via the Layers panel, I can indeed edit their contents, and all the changes will be automatically reflected in the master page view, even without deliberately selecting and editing it via the master page section in the Pages panel. This is crazy! I'm sure you either want to accommodate Designer users, or just haven't gotten around to fixing this yet, but… it makes no sense to a DTP (Quark/InDesign) user. Master pages are supposed to be these “sacred”-like entities, which you set up once and are actually hard to edit on a whim. You really have to commit when doing so and know what you're doing, as they can completely change the look and structure of your document with the slightest of edits… You know, much like styles. I see why you'd use your existing Designer framework (even from a file compatibility standpoint), but master pages really look like just a tech demo/visual proof of concept at this point. While on that subject, a third thing becomes self-evident, which is that you've philosophically painted yourselves up into a corner with your approach of defining artboards as layers, and layers as dependent upon artboards, hence the very need of your internal talk about “Global layers” (guess what, in Adobe apps, and apps by most other developers, all layers are, indeed, “global”) because your users are clamouring for a different – and more standard – approach. Your so-called “layers” are anything but, they behave more like artboard/page and object folders (whose visibility you can toggle, sure), and you have to recreate them for each and every page, much like your so-called “master pages”. While that would still fly with Designer users (and it's very debatable, still), it won't fly with DTP users in a multi-page document-centric application environment like that of Publisher et al.. Global layers, while supposedly being too “left brain” for your audience (or so you think), are an absolute necessity for long, complex projects that require some level of abstraction, and you should also port them into Designer while you're at it, even if you have to introduce further complexity and two different object management models (“layer-dependent + page/artboard-independent”, and vice-versa) into what's an otherwise quaint little vector illustration program (UX designers, on the other hand, would love that, and it was precisely on such a project that I missed global layers the most – in Designer, yes, and it was paid work, not just spec work for my portfolio or beta testing for your benefit).] By the way, I don't know if you read my reasoning on the other thread, but I strongly believe that it really should be a v. 1.7.x (if not v. 1.7.0 RC/GM) feature and that Publisher will not be taken seriously by professionals – as I've just said, as far as we're concerned, it isn't by me or my colleagues, at least – unless it's there, and soon; Serif would be doing itself more harm than good by rushing Publisher out of the door without basic master page functionality, I'm afraid. In fact, I feel so strongly about this that I'll take it up a notch and do a little comparison: that would be akin to releasing Photo without support for layers or filters. You see, this isn't some nitpicky, obscure typography thing like Drop caps or some of those bloated InDesign features which you can compensate for with workarounds; you're basically expecting your users to not use master pages for *any* editable field (and DTP is all about… filling up hundreds of fields), which is nuts and makes working with Publisher harder and less efficient than working with even Microsoft Word (and that's really saying something, as Word is a cumbersome old dog of an application). It defeats the whole “create once, reuse often” purpose of master pages altogether. I'm very, very sorry for my tough stance on your collective work, which is hard and has been great so far… I'm mostly sad and frustrated, almost as if the wait for the first Publisher beta was still going on as we speak and this was just some cruel tease. I really, really wanted to get rid of InDesign and I just can't, and from the general tone of your post I don't feel I will with v. 1.7.0 either.
  8. +1. Essential for things as basic as the leaflets mentioned and book covers as well.
  9. Yeah, well spotted, and it does make sense. Well, if anything, Serif would also get it right and more intuitive as opposed to Adobe. I never understood the latter's reasoning behind putting baseline grids, a mostly document-level setting, mixed in with the app-level settings. Shouldn't that be the kind of thing that would go along with margins and master text frames?
  10. My understanding of what alpha and beta stages are seems to be a bit different; I was of the conviction that those stages pertained more to the overall stability of the software – and did indeed correspond to points on a timescale to product launch, obviously –, and that features could indeed be added or removed (more likely removed, but Serif does have a history of adding stuff, too) until release. But yes, I do agree that this is an alpha-level app (per your definition) with beta-level stability (per my definition). Which is sad, because for all the wait, us pros were certainly expecting bigger and better and now feel a little deceived and disappointed, alas. As for them publishing their research: nope, I fully stand by the Serif devs on that one, as I've been following the development of Affinity since its very inception (in fact, I predicted/guessed it in a letter I sent them a full year before they announced the suite) and I can still appreciate why they might be mum on that. Adobe does have a history of stealing features from Serif rather quickly, as the corner tool appearing on Illustrator shortly after being released in Designer should attest. Hence me putting such a strong emphasis on the ETA, and not on the specifics of the implementation; I don't care about the details, as long as it works and it arrives in a sensible timeframe which justifies resuming my testing. If you want to partake in a fully open development process, by all means go to the Scribus forums, or something. Besides, Serif is already way more open than Adobe, so I believe the tester doth protest too much on that regard. On that subject, though, and considering how all three apps are going against a 300lb established gorilla and have a lot of catching up to do, I think it would be nice to see Serif use a trac-like version timeline/graph with all the publicly announced and expectable features; that way, we wouldn't have to be pestering them about ETAs or progress anymore. Unless, of course, they wanted to still be able to reprioritise stuff on the fly and still avoid raising expectations only to fail them right afterwards, a degree of strategic opacity which I can also appreciate… The constant delays in the Publisher beta launch were already bad enough, so imagine if they did promise a more complete feature set than the one they ultimately delivered (though we did assume, and rightfully so, that these features I mentioned would be there, because the only ones they explicitly said weren't coming were very advanced InDesign/Adobe features that would take years to replicate regardless of how far along the overall development of Publisher was). As for their supposed “arrogance”, please do point us towards the relevant post. I'm keeping an eye open for that but, for now, I don't share that sentiment, though I do feel they sometimes suffer, to some extent, from hubris (and understandably so, seeing how successful they got with the first two apps). But that's what we, the pro forum-goers, are here for, to anchor – pun unintended, but funny in retrospect – them back to reality. Again, if we did a comparison with Adobe (and their insufferable engineers who sometimes argue with their users even in the face of overwhelming evidence, like in that infamous thread on gradients on an Illustrator user forum), the Serif team would, once again, come out on top. Still, these oversights and misguided priorities may add up over time, so what do I know…
  11. Actually, now that I read that review and got around to take a small break and test master page item usage/content editing/overriding (or its lack thereof; I really didn't think it would be missing and I just assumed it would be there, as it's so, so basic), I am aghast at how seriously behind Publisher is functionality-wise. Master page items ARE NOT used for decoration only, they serve very serious workflow and time-saving purposes for content insertion as well. I teach students how to use creative software, and a recurrent theme is telling them how to use as many of those “do once, reuse often” automation features as they can (in my case, it's side-bearing and kerning-pair grouping, as well as component usage – it's a kind of “typographic symbol/asset” of sorts, which you can fully parameterise – and basic scripting with classes for contextual alternates in the acclaimed type design application Glyphs). I would never, ever recommend Publisher to them if it didn't adhere to this basic standard of operation at launch, of which even Designer seems to be a great example, with its symbols, assets, etc.. I concur with the reviewer's assessment; this may end up hurting Serif more than helping. This isn't even the “nice to have for complex projects” kind of feature like the ones I've mentioned before here in the forums (to save you some time, I mean having multiple-page spreads), let alone an advanced professional-level feature which no one really expected because the Serif team had already shot it down (think Multiline Composer), this is actually the kind of “I'd rather use the car-crash-interface-Scribus, install InDesign CS5 – or Page Plus, if that's your cup of tea, as I don't believe you can't override master page items on PP – on a VM, pay the Adobe CC tax or sell a kidney to buy a license from Quark if I can't do this on Publisher” kind of feature. So I will ask the Serif devs very bluntly: what is the ETA for this very, VERY basic feature, without which Serif shouldn't even be allowed to called Publisher a DTP application as many people would see it as, more than incomplete, actually broken/useless? 1.7 GM? Or 2.0 GM? I should also restate the same question re inline/anchored images and vector objects as well, while I'm at it… Is it a 2.0 affair, or can we expect it sooner? Sorry, mac_heibu, while I do concur that calling it “alpha” may be an “insult”, in the sense that Publisher is indeed way more stable than alpha-quality software, calling it “proof-of-concept” would be, as of now, entirely fitting, as it's a functional stage somewhere between alpha and beta (betas don't have to be feature-complete or even completely stable, but they have to be at least usable for basic stuff; for instance, Gmail was officially in beta for years on end and, guess what, you could always quickly and easily send e-mails – and then some – from the very beginning). It's an interesting piece of software, but in its current state it would be cumbersome (if not downright useless) for even the most basic of tasks (and yes, typesetting a 300+ page book of prose or poetry, without footnotes, is something I would call basic, as it's precisely the kind of easy DTP exercise we had to do at an undergraduate level). At some point, if using a word processor is easier and quicker than even using Publisher (and I had colleagues on my BFA that did indeed set entire, complex 40+ page documents in Word – and by complex I mean stuff with images and recurrent, master page-like decoration –, and I can assure you they looked good), its point of even existing is moot. To do DTP you can't just make do with multi-page Designer with cross-frame text flow, baseline grids and static masters tacked on; you need way more than that, and Publisher is currently failing to deliver on that basic set of needs (not of being an InDesign/Quark/Scribus clone per se, but at least a prosumer DTP app), period. After you properly set up your document, a DTP app should work for you, and not the other way around. Never, ever, in a million years, otherwise its cheap price will just be quickly offset by diminishing returns, as any economics 101 will tell you. I'd say 10 pages would be about the top limit over which that effect would kick in and hey, guess what, Designer can handle as many pages just as well so, again, Publisher's very reason to exist is rendered moot, and by another Serif app, no less. And to the Serif devs, I am very sorry, as you've been very kind to me in the past, a kindness which I haven't returned for personal reasons (as I said before, I'm finishing a beast of an MA thesis – on typography, no less) that have nothing to do with what I think of your work and mission, which I feel is mostly useful and positive, but… While I used Designer and Photo betas for professional work with glee (despite all your recommendations to the contrary; yeah, sometimes I like living on the edge), I wouldn't subject myself to actually test Publisher even in a speculative setting in its current state. Please do appreciate where I'm coming from: reengineering old InDesign projects into APub format could be useful in the future, but only if I had the guarantee that by 1.7 or 2.0 GM they – or the muscle memory acquired in the process – might actually be useable and useful, hence my insistence on getting an ETA from you (also, it's not like I'm asking about some super secret feature Adobe mustn't know about, lest they rip it off from you). I know it could be in my (eventual) best interests as well, but it would feel like a potentially pointless chore (and an unpaid one, at that… wait, even worse, I would be the one paying for it after the GM launch!), and not like a fun (and actually useful from a strategic standpoint) thing like the earlier betas did. Also, I know that you always make a point of warning users that files created with the betas are not guaranteed to work properly with the GM versions, but that's a gamble that at least has some chance of return; Publisher's value proposition, even from that standpoint, is pretty much null at this point. I am impressed and relieved to see that you are taking typography – my baby – seriously enough, but when it comes to the mundane nitty-gritty of DTP workflows, I really do believe you have your priorities all mixed up and that most serious users would be more forgiving of many other bells and whistles not being there in the beta (like… many features from Designer – including, yes, advanced typography controls –, which are already there by default anyway). Please fix this, and then let us know in the forums or via e-mail newsletter when you do, so I can resume testing in earnest… My honest advice is: I know the road to GM is hard (having worked on a personal project with a somewhat fluid deadline for four years myself, I can absolutely relate) and, at some point, you will have to freeze the feature set (ditto for that), but please, oh PLEASE, do not ship this thing with either of those features missing, as you'll lose a few important pro testers/potential DTP clients in the process (me included; and I specified “DTP”, as Designer and Photo are, indeed, “good enough”), even if temporarily (though it won't make you look good in the eyes of the pro crowd even if you do get around to adding them in a later 1.x or 2.x release, that's for sure…). And don't think for a second this is a slippery slope and that, after these features were implemented, I'd start harping on about a myriad others (like literary/academic/technical-related ones, such as multiline composer, indexes, footnotes, the works; those should come eventually, but I'm obviously not holding my breath). No, these features would elevate Publisher into “good enough” status and put it at least roughly on par with its brethren, even if it stayed a bit behind the other incumbents in the DTP space… It would still be the inexpensive option, but the value proposition would be there and work its magic, as usual. As a matter of fact, I could quickly redo 90% of my professional freelance work (as opposed to some of what I did – and all of what my colleague did, as she was responsible for a medical magazine – at the medical event management business I worked for, namely long-ass conference programmes and books of abstracts) in a practical and sensible fashion (as in, in an easily editable/expandable/reusable form) if only – and only if – you added those two features. As long as they are not there, I won't be spending my money on Publisher or recommending others to do so, sorry; that's where I draw the line, and it's a sensible one at that, as the kinds of projects I worked on seem to match pretty well with your target demographic (people who do more artsy/marketing/advertising work and less literary/academic/technical – in essence, “boring” – work) and with those most of my colleagues worked on, too; I don't know what kind of market research you did but, unfortunately, I do believe reality will get the better of you and once the disgruntled InDesign user reviews start pouring in you will regret that decision (if you do indeed go the opposite route of focusing on fluff over workflow, that is). On that subject, I should also add that I have been heavily pushing Publisher (and Affinity in general) on social media and IRL (and while I don't have a metric crap ton of followers/acquaintances, I am a bit of an influencer on my niche, on account of having been a – still somewhat locally famous – computer room monitor and being a teacher), so my personal credibility would also be on the line, so to speak… In a sense, not recommending Publisher in its potentially incomplete 1.7 incarnation may hurt your wallet a bit in the short term, but it will also spare you some needless (and, I reckon, somewhat unfair, because I do think you have your heart in the right place) humiliation. Peace, and godspeed!
  12. Wim, you can't make assumptions of that kind re baselines. InDesign allows for frame-level custom baseline grids for a very good reason: It's good practice to set captions and margin notes in a different style than the running text, and since said style is usually in a smaller body, it follows that the baseline grid should be in a smaller leading as well; good practice also dictates that you should use some kind of cross-alignment scheme, usually with a sensible ratio (like 3/4, 4/5, etc.)… If it wasn't for that, you'd have to use a minimum denominator, which, in turn, would mean that you'd have a stupidly small leading and have a confusing excess of baseline grid lines, thus defeating its purpose. I should know that as I sometimes use that technique in simpler projects with a 1/2 ratio, and it already gets very confusing as it is.
  13. Exactly! Those grey lines are there just to show where the page will, ideally, be cut after binding. But it never works out that way… If you look at, say, a couple banknotes, which are as precise a printed object as they get, not even those are all entirely the same (there's a reason why the background design – or their lack thereof – extends over to the edges in a simplified way, so they can be cut to measure from large sheets and still allow for the tiniest bit of misalignment). As you might guess, our regular printing jobs are not very mission-critical by comparison, and one or two mm. of deviation are actually fairly standard especially after the booklets are bound, as the edges of the inner spreads extend outwards a bit more than the outward ones (that's why most bleeds are at least 3-5 mm in width).
  14. Oh, sure, I can appreciate how that could become very chaotic and misguided, and quite fast. But perhaps allowing them to rank a pre-compiled list of features and suggest others in the forum like we already do (and the Serif devs would ultimately be the arbiters of which made the cut) in order of importance would give the devs a bit of insight on at least which would make the app more competitive, ASAP. Of course, dependencies would have to be taken into account and would always dictate the order by which they were tackled in the end, but that doesn't change the fact that, all things being equal, tool A, being more popular than tool B, could also get priority treatment. Quite the contrary! I wanted to prevent InDesign from doing that and adding page after page near the end of the document (until said limit is reached and I keep getting those stupid pop-up messages warning me of just that). IIRC, I believe I once came up with an ersatz solution; I broke the link on the last page of the main section of my document, and linked it instead to a dummy text box outside of the master (which would just show the overflow [+] sign, instead of, you know, actually flowing to a new page). There's probably a proper, more elegant way to turn that off, but my jury rig achieved the desired result anyway. In any case, don't worry too much about that. This is a Serif forum, after all, and we're all itching to ditch InDesign rather than keep dealing with its quirks.
  15. Well, just because something is hard to do, doesn't mean you shouldn't do it… Especially if it's something you must do in order to be able to be taken seriously by your target audience. AFAIK, Affinity is supposed to be geared to the professional print market, and though we do not expect all the same bells and whistles from CC (many of which are, let's face it, bloatware at best), basic features pertaining to the actual physical layout of our print jobs should be a given (hence the insistence by the tester community on the need for bleed previews; however, in the grand scheme of things, these features are actually way more important for more complex projects). I mean, page and spread management in ID is sometimes unintuitive (especially that stupid habit it has of automatically adding more and more pages – until that magical… what's it, 10-page limit? is reached, and that's something that would also be cool to see being addressed in Publisher, too – whenever the content overflows; maybe there's a way around that, but if there is I still haven't found it), but it gets the job done. It's actually not the most unintuitive of Adobe's apps when it comes to page/artboard management, unlike Ai (oh, how I loathe that stupid Artboard panel and miss FreeHand's page navigator/editor… Artboard management in AD is a bit better than in Ai, but still not as intuitive as in FH, and it has quite a few issues of its own – namely object ownership and out-of-bounds visibility –, as I pointed out in the Designer forum some time ago), and it doesn't look that hard to replicate, either. The whole “can you give as an ETA” thing is not meant a diss on the Serif devs or anything. I am, of course, fully expecting them to add that functionally eventually (even if it has to be postponed to an also paid 2.0 version), but having an ETA, especially on a feature which is not exactly novel (and, hence, won't really tip off Adobe's or Quark's devs in any meaningful way) but is, at the same time, essential, is of material significance for their customers, as it may affect their future buying decisions. If I were using InDesign CC and intending on switching to Publisher, and realised this or that feature would be completely missing for months, I would start looking for a CS6 copy+license on eBay ASAP so I could set up a dedicated virtual machine in the mean time (even considering the initial investment, it might be worth it in the long run, if anything to be able to convert old files into .PDF so as to import them into Publisher even well after the subscription expired).
  16. Not very likely, as that will probably be a strictly iPhone-focused event, but it would be cool, yep. Maybe on next year's WWDC, to receive yet another award?
  17. serge, I thought I should warn you about this: sharing your Mac serial number on the web for everyone else to see can be a bit of a security liability…
  18. Interesting… Pardon my ignorance, but… How exactly does one go about changing an individual page's size? I looked for it and I couldn't find it anywhere. :\ [Edit] Nevermind, I found it. You just have to edit the spread properties… In any case, those two features make much more sense in conjunction, as I just explained. Besides that use case I've mentioned, when doing two fold, three-flap flyers that have one of the flaps folded under the cover flap (as opposed to being folded in a Z shape) you have to subtract 1-2 mm off of that inner flap so that it fits. Just having the option to change spread sizes may allow you to do a book cover, in the same document as the rest of the book, which includes the spine, back cover and inner flaps as a single page, but it's still a PITA because it forces you to make a specific layout all by hand, and fine tune it according to the print shop specifications (just like I had to do waaaaaaaay back in 2010, in InDesign CS4, with the only added – but negligible – advantage of being able to keep it in the same document… I mean, you wouldn't expect Publisher to be four or five versions behind CC 2018 in basic stuff like that, let alone eight full years, now, would you?). Also, I just found that the weirdest thing happens when customising a spread to have a different page size: I had a portrait A4 document, with a cover page and two full spreads; I customized the first full spread to be landscape A3 sized; then I proceeded to delete one of the A3 pages to see what happened and, guess what, I still had a landscape A3 spread and the last A4 page was gone. I am very curious to see how Publisher would behave if those pages had a Master applied to it and had content in them. This may make sense in some use cases and makes print documents more foolproof (in general, you shouldn't be able to have differently sized facing pages), but it feels woefully unintuitive. Oh, by the way, now that I think about it, it would be awesome if Publisher actually had a “print project” persona/tool of sorts (maybe a grouping tool in the pages panel?) for books, that let you define how many sheets/booklets you had (perhaps even with a paper colour/texture preview), how they were folded, and in which order they were stitched/bound. That way, you could “freeze” a physical layout, so that it was physically possible to produce and that your content would fit it and not the other way around. That would be great both for newbies and professionals alike, especially in the DIY camp, and would ensure that every project would always be made up of multiples of 4, 6 or 8 pages. That would definitely not be a priority, but it would be a “nice-to-have”, which would give them a leg up over Adobe. I am a pro and, while I don't exactly need such a feature, I would love it.
  19. 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.
  20. 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 ).
  21. 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).
  22. 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…]
  23. 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?
  24. 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:
  25. 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.
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.