JGD
-
Posts
513 -
Joined
Posts posted by JGD
-
-
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!
-
On 10/1/2018 at 11:58 AM, MEB said:
Hi JGD,
Thank you for your feedback and support. As said there's still quite some work to do here. We are aware the current feature set is limited for long documents and the way master pages work is still far from ideal and limited in its scope. Your considerations about global layers should also be addressed at some point. As with other things I can't give you an ETA for these or any other features, nor I know exactly how they will work at this point since I'm not aware of all these details (I'm also not the most suited person to do so). I don't think it's wise to expect Publisher to replace InDesign (or any other high-end publishing software) right after its first release. We are still building its foundations and some of that work will extend through the 1.x cycle of the app. We do understand master pages functionality is essential for any serious workflow. The only thing I can assure you is the development team is well aware of these limitations and hope to address them as development moves forward. It will take some time though.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…
-
On 9/13/2018 at 4:31 PM, MEB said:
Hi kubapet,
Welcome to Affinity Forums
This area is still being worked on. Currently objects coming from the masters placed in the spreads/pages cannot be unlinked from them. So currently the masters should be used to place objects that you want replicated equally on all spreads/pages to which that master is applied to. All objects specific to each page/spread should be created in that page/spread not on the master. There will be improvements here in future updates/versions.Note: there's actually a way to unlink them through the symbols panel - detach button - (which is the master functionality is based on) but its convoluted and not intended to be used as it is for this.
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.
-
+1. Essential for things as basic as the leaflets mentioned and book covers as well.
-
36 minutes ago, Wim Daniels said:
@JGD I think most of my assumptions remain valid. But indeed, we should add support for baseline on a text-frame:
- Baseline grid can also be managed from a text-frame perspective.
This still means the baseline grid manager-button on the top toolbar makes no sense. It should be a pane in Studio > Text Frame (and a global setting in the spread setup, keeping two levels for baseline grid management)
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?
- Wim Daniels and Old Bruce
-
2
-
1 hour ago, James Brokenshire said:
I think there is some confusion about what Alpha and Beta is:
- first there is user research to understand your users, what their user needs are, who they are, how they work, their context
- then based on this (and only after) you develop ideas for how you might meet these user needs .. these ideas become experiments to test ... that is what an alpha is .. an alpha is one of potentially many experiments to see of your ideas really do meet user needs in an efficient and pleasant manner as possible
- beta is where you have already established how you're going to meet user needs, and have the evidence that it works .. you then test .. test.. test.. for bugs, issues that didn't emerge earlier from use at scale, many more and different kinds of users and use cases ...
So right now it seems that Affinity are experimenting to see how they can meet user's needs for creating documents / books with over 100, maybe even 600, pages. Right now the alpha is proving that you can't.
Like someone said earlier - alpha and beta are not points on a timescale to product launch, nor are they a division of product features or user stories.
So - perhaps we're being really stupid and Affinity has an even better way of meeting the needs of users who need to produce documents with more than 10 pages ... in which case the calls for them to be open and publish their user research and user stories are well founded.
But they haven't, and they continue to censor / "approve" posts here. Which suggests they've gone further in the direction they should - closed secretive design by committee. They've already been a little arrogant here and told someone they "have over 25+ years of DTP experience and know what we're doing" to paraphrase.
Evidently not.
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…
-
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!
-
5 hours ago, Wim Daniels said:
I agree that the baseline button as it is implemented now, doesn't make much sense. A baseline grid is most likely a global document setting, so the baseline manager belongs in the document, spread, master-ages area. That's where I would like to manage my baseline grid.
Having my tools snap to the baseline grid is something I like to use in a flexible way. So to me it makes sense to have a button to switch it on or off in the top toolbar. But I can imagine that others prefer a switch to turn other snapping options on or off: guides, margins, spreads, objects... It would fill up the toolbar pretty soon. So better to keep the snapping option as the are now with the magnet button.
Simply remove the two baseline grid buttons because...
- baseline grid should be managed from a document perspective
- baseline should be define in paragraph styles
- snapping to the baseline grid belongs in the snapping options.
While we're discussing the baseline grid, why is displaying the baseline grid not an option in the view menu? We need to switch visibility from the baseline grid manager. That doesn't make sense when you want to change the view on you document.
Also when I want my baseline grid relative to the margins, I prefer it being displayed/active only inside the margins...
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.
-
12 minutes ago, serge said:
So my document should show like that (screenshot in publisher) with the grey lines being the bleed?:
and my pdf layout should be :
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).
-
16 minutes ago, walt.farrell said:
I never said it shouldn't be done. I said (somewhere upstream) something like "letting the users vote on which things should be done first generally can't work, as there are complications the users don't know about."
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.
16 minutes ago, walt.farrell said:Are you asking for a way to have overflow text automatically flow into additional text frames? If so, try shift-clicking on the "link" triangle on the lower-right edge of the text frame, near the eye icon.
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.
-
On 9/4/2018 at 1:41 AM, walt.farrell said:
And that sort of complication (assuming it's even intended to work) will have to factor into development plans for new features.
(In a discussion a day or two ago where I mentioned different size pages in the same Publisher document, and one of the requests was for 3 pages in a spread, 2 outer book covers and a spine, one of the Serif staff wondered what the test scripts would have to be like for that situation. I can only guess that I wouldn't want to be the one testing it But it brings back memories of one project I was designing at my former employer, where I had a nice design for a new function that the users of our product would like, and our testers vetoed the development of the item because they had no way to test it adequately.)
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).
-
5 hours ago, Edward said:
You never know they might be on stage next week!
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?
-
1 hour ago, serge said:
I just downloaded it and I noticed that it keeps crashing out.
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…
-
29 minutes ago, walt.farrell said:
And that (different page sizes within the document) is already possible in the Publisher beta. What is not possible at this time is having a spread which contains more than 2 pages or pages with different sizes. Standalone pages can have different sizes. I'm not sure if a spread can have a size different from other sites.
Maybe you're right, but I have no idea what's involved with the snapping that makes spreads
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. -
On 9/3/2018 at 3:43 PM, walt.farrell said:
In my experience, voting by forum users doesn't really work well, although it certainly may make the forum users feel good about being heard.
First, a technical issue: Some features must be implemented in a certain order, because they depend on each other (even if the users may not know that) or they impace (or are impacted by) other things being developed.
Next, a practical one: Some forum users are very vocal, but others are very quiet. Some would vote, and some wouldn't. Some probably don't even visit the forums at all. And you might have 10 very vocal users with a particular workflow who desperately want function A, but 100 quiet ones who have a greater need for B.
Finally, it's hard to be sure that the users participating in the beta are representative of all the users who might buy the product later.
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.
-
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
).
-
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).
-
On 12/5/2017 at 3:48 AM, MikeW said:
I have mixed feelings about OT 1.8 spec as regards variable fonts. It's been done before and flopped (twice if I recall). This time around it has wide support among browser developers. And that is all the difference in the world. But whether this translates to desktop application makers and designers is hard to tell yet. If applications add solid support, designers would likely utilize the feature. That is where both Multiple Masters fell apart and GTX as well. Designers just didn't make the transition and even if they clamored for it, application support was spotty at best. Adobe tried to stop gap the lack of support with ATM but making instances in it (and other type applications) was seen somewhere between a hassle and a novelty. I am uncertain whether "build it and they will come" applies.
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…]
-
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?
-
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: -
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.- CLC, DBerlin81, gabrielsiml and 3 others
-
6
-
Guys, the beta expired!
And seeing that as per your recommendation it should be used in preference to the current MAS build, which isn't available yet, that's a bit of a bummer…
-
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.
-
On 12/5/2017 at 2:15 AM, MikeW said:
The specs for variable fonts are not set in stone yet, in that there are still axis tags being registered or in some stage of discussion prior to becomming a registered axis. And for some/many tags, even what a default setting should be isn't written in concrete yet.
There is limited desktop application, primarily being Adobe and browsers. Adobe's implementationt is a showcase of X number of axis in a variable font. It would be good for support in Affinity products, but one needs to recognize that over the course of a year or two (or more), the number of axis is going to grow and if rational issues are found, specs (mainly tables in the font I suspect) and or defaults for an axis may change/grow as well.
I create fonts and work on other's fonts. I wanna redo some into variable fonts. It means I may be able to sell fonts that were "dead" to new sales growth. So of course I desire wide application support. But that support really isn't there and likely will take some time before there is a widespread support. But I wouldn't say for an immature application such as AD that such support is or should be placed ahead of fixing bugs, adding drawing features and improving overall usability.
Mike
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.
GREP find/replace
in Feedback for Affinity Publisher V1 on Desktop
Posted
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…