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

JGD

Members
  • Posts

    513
  • Joined

Contact Methods

  • Website URL
    https://orcid.org/0000-0001-9678-3692

Profile Information

  • Gender
    Male
  • Location
    Lisbon, Portugal
  • Interests
    Typography, type design, modular geometric type design, grid systems, information design

Recent Profile Visitors

3,611 profile views
  1. @Patrick Connor I am very happy to see positive feedback on my penultimate post, by the way. As for the other right above this one, where I mentioned writing papers and giving the industry as a whole a proper jolt, I really meant it. As a typography user, creator and educator, I am not too happy about the current lacking – nay, half-assed, if I may be so blunt – implementation of variable OTF fonts in software packages; sure, it… works, and we need it also in Affinity regardless of its current state, but we can and should do better as a collective. Very conveniently, as part of my PhD, I still have to publish a second paper until the end of next year, and even after that, we – sadly, or thankfully, I guess I'll figure out in due time if I can handle the pressure – in our research centre have to fill a certain biennial quota of publications, so… we might as well make truly useful ones. Patents seem to be highly valued over there as well, and my supervisor has some experience with those (you know, with his calligraphy app for the iPad and whatnot) and I wouldn't mind joining him in that club, so… if you're interested in taking the reins and really setting trends, hit me up. We're actually both part of a team of ten researchers, all working on this kind of stuff, but I'd say we're the ones more technologically-minded of the bunch, and it also bears reminding that Prof. Brandão has always been a strong advocate of Affinity and other tech underdogs (Glyphs.app, with whose developers we keep close contact and whose support we consistently get for our teaching endeavours, also comes to mind). If you want to check us and our work out, you can find us at https://typo.fa.ulisboa.pt/en/about/ .
  2. This one takes the cake… Even the completely discombobulated Microsoft, which has a great typography department but still fails to support something as basic as OpenType ligatures across the entirety of the Office Suite (hey, if I want ligatures in my Excel spreadsheets, I want them, g*dammit… 😂 Now, in all seriousness, it irks me to no end having to use legacy fi and fl Unicode characters in PowerPoint, which I sometimes use for presentations in typography events), seems to be progressing in the right direction… I will also add that if Serif isn't in contact with other developers, or at the very least with specialized academics and type designers, with developing standards in mind, they should. Variable typefaces are a veritable UX conundrum, and I completely feel the developers' pain in trying to support something as… anarchic as the variable OTF format, not just at the technical, behind-the-scenes level, but especially at the user-facing one. Yes, all those text-based parameters and sliders make OpenType features, with its predetermined names grounded in tradition, seem user-friendly by comparison, I know. If you want my €0,02? Type designers being, err, experts in vector design, perhaps a future variable OTF version/spec should let them add specialized glyphs as visual labels/aids for their custom variable axes' end-, mid- and even custom points, which would then be used automatically by graphic design software packages. Hey, maybe I will even write a paper on that… Any of you peepz in?
  3. Adobe seems to support them just fine. Of course, they are both the creators and main implementers of the PDF format, and creators, distributors and heavy promoters of variable OTF fonts, seeing how it's just a development of their old Multiple Master format (seriously, the other day I was playing around with a really old version of Illustrator, running on System 7.6 on top of Basilisk II, and I was absolutely shocked at just how similar the interface for manipulating Type I MM fonts was to their current implementation), so they obviously have their work cut out for them. Unless Adobe, Corel et al. have some sort of weird patents, it should be just a case of opening their files and reverse-engineer them. Voilá, presto! Anyway, and AFAIK from my own look into it way back when, Adobe's apps just take whatever interpolated values you picked and export the end result as bespoke, automatically-generated and embedded fonts for the relevant text strings (yes, a separate one for each combination of variables), so there's no need for converting stuff to curves, losing the ability to select text or ballooning file sizes, the works. Of course, when reimporting, you absolutely must have also an embedded Illustrator file stream, otherwise you're completely screwed. Perhaps you could look into making your own implementation of PDF files with embedded .afdesign or .SVG streams, or just metadata for the relevant text strings to save on file size, so that one could in theory reconstitute those multiple resulting fonts into their parent variable OTF fonts/styles? As others have said, variable OTF fonts are just not going away; not this time, and especially not with the might of Adobe TypeKit and Google Fonts behind them. Heck, even I wrote a paper on those; you can check it out in my ORCiD page in my bio if you want. And, as I've said before, my students are really using them in earnest (… as attested in said paper), which means that when they leave the Uni and enter the workforce, they'll either keep using Adobe CC, or switch to something else altogether, like Sketch. I know you don't like to hear this, and please don't shoot the messenger, but… I did warn Serif (a company called, of all names… SERIF!) years in advance of just how relevant and pervasive they would become. 🤷‍♂️ I cannot stress this enough, and to all the people rightly clamouring for RTL support: variable OTF font support should be included in a splashy v.2.x update (not a v.2.x.x one, but a full-blown point update, and maybe even a jump to v.2.5 for good measure), and RTL could very well wait for v.3… Allow me to explain: the RTL market is not even considering Affinity apps at the moment, at all, so they're not exactly invested in them, whereas a lot of designers, be they young and aspiring or established veterans, may have bought Affinity 1.x (let alone 2.x, because this thread and all related discussions date back to the v.1 days, if I may remind you all), with the expectation of it being a professional package somewhat approaching feature-parity with its peers (in their Latin-centric bubble, for sure, but it is undeniable that the vast majority of the design market in the West indeed doesn't need RTL; and full disclaimer: I'm a type designer with two finished but as of yet not commercially available fonts which support Arabic, so I fully understand what's at stake and feel RTL users' pain). And variable fonts being an external development, long in the making and over which Serif does not have much control, they are something third-party developers must adapt to and properly support, ASAP, and not the other way around. As I've said, the penalty can actually be people switching back to whatever software package they were using before, or to a different alternative to the proverbial 800lb gorilla in the middle of the room, just so they can stay up-to-date and competitive. The best way Serif can ensure people stay in the Affinity bandwagon for v.3 is to give them the bare essentials, and typography being the basis of design (think about it; other media and visual resources such as, say, photography or illustration can exist in standalone form, but not typography, or not to the same extent), yep, supporting the most popular formats available is as essential as being able to import and export in all popular vector and bitmap formats. Would you like being limited in what camera, or drawing tablet, or brush packs, or whatever you could buy for your creative endeavours because your supposedly very much up-to-date software package of choice refused to support them? Now extend the same exercise to something as basic as typefaces…
  4. I will say this: my MA students, future designers, ARE using variable fonts as we speak. I have been warning Serif developers all this time, and they won't listen. They have several high-value users and testers connected to the industry and academia at the highest level, following – nay, setting – the trends (guess what I'm about to do when I finish my PhD in… typography education? 🙄), and yet… here we are. Let's just ignore the 500lb pink gorilla in the middle of the room that is Adobe (they created the format, after all, and had already come up with Multiple Master fonts before it – I tried those on an ancient version of Ai running on a Basilisk II System 7 VM, and it's shockingly similar to the current implementation, down to the generic parameter sliders, so I'm guessing it just failed due to lack of support from type design applications, third party vector and photo editing and DTP apps, etc.), and look at one of Serif's actual competitors on the Mac, Sketch: https://www.sketch.com/blog/variable-fonts-improved-opentype-support-and-a-new-data-plugin-whats-new-in-sketch/ Sketch v.59, from 20-freaking-19, from four years ago, back when Affinity v.2 was just a blip on the radar (likely an internal Alpha, or a set of notes on a whiteboard, or something), supported variable fonts. Sure, Sketch is very much geared towards web and UX design, but there had been already such a request here in the forums the year before, as was already requested 2016 and heavily commented by yours truly the next year onwards! And I'm commenting here because a musician friend of mine (a musician who works in banking, not one of my design students, so you can see just how mainstream these can and will become), who uses a Mac, wants do do his own design work and variable fonts came up in conversation; I recommended him either Affinity or Sketch, but I'm guessing that if he enjoys playing with those, you won't get his patronage, and through no fault other than your own. 🤷‍♂️ Seven years, guys. Seven years. And at least six years of me warning you that it would eventually become a serious omission. There are now people, both here in the forums and out of them, literally skipping on the v.2 upgrade (or on Affinity altogether) because of this. This can't be a v.3 feature, it *has* to be added to v.2 at some point. No ifs, no buts.
  5. Great! In related news, I managed to iron out the latest kinks on that machine (apparently you shouldn't be cheap when it comes to buying small-size, SuperDrive, to full-size, hard drive/SSD SATA III adapters, as they have a tendency to trigger all sorts of R/W errors – that wasn't the issue behind my woes with Affinity, but it made me seriously rethink my strategy, and is now fortunately fixed for good), and have it updated to all the latest versions of macOS and my apps, including Affinity v.2.1.0 GM. What's more, it even runs great on a 2009 Unibody MacBook, unlike the latest versions of CC. There's a reason why I keep using those old Macs around and kind of expect Affinity to run on them, because I'm just spoiled; it boggles the mind that it actually runs so well on hardware of such vintage, but it is what it is. In any case, I know what I'm potentially getting myself into, and have budgeted for getting a new 13'' or maybe one of those upcoming 15'' MacBook Airs on a moment's notice, just in case. All in all, it's a win-win situation, as the longer I postpone that purchase, the better the machine I can get by then, and as I'm just writing a PhD thesis and not doing much design work these days, it's not like I really need a very powerful laptop at this point (and if I do, that's what the Mac Studio is here on my desk for). 🙃
  6. Fair enough. It's in no way comparable with Apple not supporting me booting my Mac or running my user account off of an external drive (especially the latter, something which their default install definitely allows even without reducing security settings). I guess I was still pretty mad about AppleCare giving me the finger over that (my Mac Studio borked itself around the same time after installing a measly point update, macOS 13.3.0, and I had to eschew the second option, which I preferred, in favour of the first one, which after some growing pains and tweaking in Onyx, is finally working for me)… We're good. But hey, APub does work now, so we should be extra good. It just goes to show just how resilient and compatible macOS still is, despite these weird new “holes” or “special needs” Apple keeps introducing in it regardless of ISA, because something something forced obsolescence greenwashing. In any case, I believe I should still send you bug reports and logs from this Mac and a now also unsupported 2015 MacBook Pro (especially that one, considering just how much more recent it is). You can read them, or ignore them, but… as they say, it's free data! Also, there seems to be a precedent of you looking at those despite obviously not supporting it officially, so… you know, precedents and stuff. Kind of like, hum, your entire legal system works. 🙄 I'm not demanding anything unreasonable, and would never consider your product broken or you as being negligent, and leave any bad reviews or whatever, over any of Affinity's apps borking themselves due to something obviously OCLP/Metal/SSE-related (there's a not-so-recent version of Photoshop, for instance, that is no longer compatible with the 2009 MacBook due to the lack of SSE4.2 extensions on its Penryn processor, for instance, and there's nothing anyone can do in the way of patching – not even Adobe, lest you start referring me to your EULA, like your boss did on the thread I'm linking to below, because I don't hack apps other than sometimes pasting custom icons on their information panel – to make it work, so that machine is defo on its way out). As a rule of thumb, I tend not to waste your time with anything very obviously hack-related and… as they say, “no lowballers, I know what I've got”, and what I've got is a geriatric machine (😂), and never made a secret of that here in the forums (see “precedents” above). It's just that I'm selling the 2017 5K iMac ASAP and, after that, if the mere fact that I'm using what you aptly call an “unsupported configuration” prevents me from asking you to at least look into bugs (if they're unfixable, or completely OCLP/Metal/SSE/whatchamacallit-related, yes, that is that and I don't expect you to bend over backwards to support my exotic configuration in particular, but it may be am obviously generic bug and I MAY be helping other users in reporting it), I guess I won't be able to help you much (with, say, stuff such as smaller glitches on an otherwise perfectly functioning computer – which my machine definitely wasn't the other day, and my bad, that one's on me because, as I said, I was completely on edge and mad beyond belief at Apple and anything Mac-related –, and it feels as if I'm being punished for being, you know, honest – or obvious Serif UI glitches – yes, these sorts of hacks do cause some general macOS UI glitches on occasion, but they are very easy to tell as such and are quickly fixed anyway –, especially considering the old MacBook's built-in display is non-Retina, and I no longer have any of those connected to a newer model such as my very much supported Mac Studio. Now, is there some passive-aggressiveness in my tone? Yes, there is. At least I'm open about it, and on why it is so. 🤷‍♂️ We have a bit of a history here in the forums (not with you personally, I believe, but when I say “we”, I mean “some Serif devs and me”, and “me and Serif as a company”, including binding contracts signed and all), and to quote you, “we've been down this road before”, except over much more serious stuff, such as a very sensible, not at all outrageous idea of mine being called… what was the word? Ah, yes, “stupid”. Once again, a non-snarky, noncommittal, boilerplate response would suffice, methinks. Or maybe an even nicer “we may look into it, but it's not a priority because this is an unsupported configuration, and if we find it's due to that, there won't be much we can do about that” (and you could even be lying and wait for the problem to fix itself, which it might still if it hadn't already by the time you answered 😂). Or, since the problem fixed itself, the even easier and more neutral radio silence. Do I, the communication design major (my qualifications specifically in communication and marketing stopped at the measly BFA level, mind you), seriously have to teach you corporate speak as well? I should start giving out company-wide workshops, sheesh! 🤦‍♂️
  7. Interestingly, the issue solved itself, so maybe it was indeed due to something wrong in my setup… Something was seriously amiss with the macOS 13.3.1 + OCLP 0.6.3 combo, as it was causing all sorts of weird glitches (such as macOS services and QuickLook not being able to access audio files – my alert sound, Sonumi, was being cut short, for instance –, icons and images not being properly rendered, etc., all issues reminiscent of broken SATA cables but, at the end of the day, software-related – and I did check they were, by accessing this Mac's internal SSDs through Target Disk Mode without any issues, other than KP'ing both an Intel iMac and my M1 Mac Studio when using a Thunderbolt 2 cable instead of my trusty FireWire 800 one connected to a string of dongles, which means I've found yet another software/firmware issue squarely on Apple devs' side). At first I reverted only the bootloader (not the post-install root patches) to OCLP 0.6.2's to some effect; most glitches were gone, but APub was still crashing on launch. But it seems the OCLP dev team got wind of these issues and released an updated build yesterday, 0.6.4, which fixed most issues, including APub's. Only Camo Studio seems to be acting up still, and crashing on launch as well, but this Mac has an integrated iSight/FaceTime camera which works fine, so it's not a big deal.
  8. Hi! I know my configuration isn't exactly supported by Apple, but seeing how the non-Beta and even the latest Betas of APub worked just fine on my MacBookPro9,2 (Mid 2012) running macOS Ventura 13.3 under OCLP, I was led to think that that would still be the case at least until v3 of the suite came along, so here goes: Affinity Publisher, plain and simply, doesn't work. It loads right up until the splash screen, and then crashes. In case you need some more logs than the crash log already uploaded, I'll be happy to provide them. Also, I will update to macOS 13.3.1 shortly, and check whether it works or not. I'm also aware that resetting its preferences might help, but if I could get away without resetting the entire thing, I'd much rather not do it. Affinity Publisher 2 Beta-2023-04-14-023106.ips
  9. Whoops, spoke too soon. It doesn't work on my MacBookPro9,2 (Mid 2012) running Ventura under OpenCore Legacy Patcher. It seems that it works for a split second, and then goes back to not working.
  10. Hi guys! I've recently had a big issue with my Mac Studio: when updating it from macOS 13.2.1 to 13.3 my user account, which was stored on an external drive, borked itself, and then I couldn't add e-mail accounts or get iCloud to work when recreating it. I had to change tack and install macOS on the external drive and boot from it instead, and am now in the process of manually restoring all my apps and their settings. Enter the Affinity suite… Importing my MAS-bought v1's ~/Library/Containers folders worked flawlessly, but I can't say the same for all my ~/Library/Application Support folders for both v2 public release versions (bought from Serif's store) and the beta versions. I've tried everything, and checked both this thread and the reference post it links to. I also noticed that I still had a naming discrepancy on Affinity Designer 2 Beta's Studio preset naming conventions (the files on my Time Machine backup still followed the “com.seriflabs.affinitydesigner2.Studio.Preset.[persona].[preset name].preset” convention, instead of the seemingly current “com.seriflabs.Studio.Preset.[persona].[preset name].preset” one, but Photo and Publisher don't exhibit this behaviour), but regardless of what I did (such as recreating new Studio presets with the same names and replacing them with my original, backed-up files, and in Affinity Designer Beta 2's case, by also renaming them to follow said current convention), NOTHING worked. I mean, are you guys using some hidden, undocumented internal database that I'm missing? What use is exposing these files to the end user, or document their locations here in the forum, if Affinity apps don't recognize them nor have a way of manually import them anyway? I honestly don't feel like recreating ELEVEN persona presets by hand across all three apps all over again (and I'm lucky to have kept my V1 presets, otherwise that wouldn't even be an option and I'd have to do it by memory and take twice as long). And yes, I'm sure using the Migration Assistant app would automagically copy some hidden files with some special sauce that I'm missing, but considering what happened to my entire setup, which makes me want to avoid said app like the plague and start anew (incidentally, a recommended course of action from time to time, to lose old cruft from vintage macOS versions tailored to entirely different ISAs and installed on machines with different peripherals and apps altogether), and the fact that Affinity apps are supposed to be professional products for professional settings (where backup policies may not always conform to whatever Apple deems to be the standard), I would expect a greater degree of resilience, transparency and portability when it comes to user setting files. On the other hand, I can easily and successfully import Workspace files in the extremely vintage and otherwise finicky Adobe CC apps just by restoring them to their proper places in the Finder. Just saying…
  11. Well, it seems my issue with Dark Reader has been solved (likely on your end?).
  12. I'm having this issue now on v.2.0.4 (release), but at least it's fixed in the latest Beta (the workaround I've found was to copy whatever object that had the gradient I want to edit, paste it into a new file in the Beta, edit the noise values there, and finally copy and paste the object back into the release version)… Well, it seems this is a frequent regression and that Serif devs should pay more attention to this particular feature. 😬
  13. Thank you for your swift feedback! If you find it, or open a new venue for that, that would be great. I don't recall us frequently having issues with the forum itself, but it may happen, so having it would. be nice. Also, while this bug/decision doesn't exactly stop me from using the Forums, for some users with special needs it may be more of an issue.
  14. That is all well and good, except… the suggestion made here (using Dark Reader) did work, and all of a sudden (and after years of working fine, mind you), stopped working. The fact that you offer a suite of apps that supports dark and light UI modes, and almost anything in between (-ish, but the range, while not including neutral grey as your competitors do, is indeed impressive), and don't offer the same courtesy in the user forums (when the platform you're using apparently supports it!) is beyond me and tells me two things: that a) you don't get why dark themes are an important for usability in the first place and/or b) your left hand doesn't know what the right hand is doing. At this point, in AD 2023 (even LOo caved in and finally offered a dark themed version of LibreOffice!), I consider this a bug on top of a bad decision overall, not a simple oversight, and our comments not as a “feature request”, but as a collective “bug report”. And this will be more meta yet: there are no threads for giving feedback on issues with Affinity's main website, its online store or the forum itself, so… where else are we supposed to report issues with these? Twitter? Facebook?
  15. I'm using a Mac Studio with an M1 Max processor (the base model) and 64 GB of RAM, and now running on Ventura 13.2.1. I haven't tested this on my old 13'' 2012 MacBook Pro (also running the latest version of macOS, thanks to OpenCore Legacy Patcher), but will be sure to check it out if I have the time. I've just managed to reproduce this crash with yet another icon template, but am now in the process of installing an update that just came out, so let's see if it fixes this bug. Considering how this bug was reported in December and a few updates, which seemingly didn't fix the bug, were out in the meantime, I'm not holding my breath, though… Edit: at first it seemed as if the bug was fixed, but upon trying to change the destination folder, boom, got the dreaded beachball again. Guys, seriously? This is a really troublesome bug, as batch exporting slices is a very important part of UI design workflows… Do you really need more than two months to fix this? Edit #2: the workaround posted by @Heinrichdsf and @Rriver now does seem to get the “Export Slices” button “unstuck” after successfully exporting at least one layer, but this is all too “voodoo-like” for my taste. Not every user will be savvy enough to try that sort of thing on their own or check the forums, and just assume the app is completely broken. Edit #3: after enrolling in the new Beta program, downloading the first v.2.1.0 beta .dmg and updating it through Sparkle to v.2.1.0.1709, the bug seems to be fixed. Further testing with other icon template files will be needed until I can confidently say I cannot reproduce it anymore but, so far, it's looking promising (as I indeed couldn't reproduce it, at least with one of the last few files that triggered it). Guess I may have spoken, well, not exactly too soon, but right as the dev team was getting around to fixing this. Good job!
×
×
  • 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.