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

David Cake

Members
 View Profile  See their activity

  • Posts

    18

  • Joined

  • Last visited

  1.    David Cake reacted to a post in a topic: Variable fonts support
  2.    David Cake reacted to a post in a topic: Why won't Serif listen to customer needs and create a Lightroom alternative for us?
  3.    Eric Designer 2023 reacted to a post in a topic: New features expected in Affinity Studio
  4.    PaoloT reacted to a post in a topic: New features expected in Affinity Studio
  5.    David Cake reacted to a post in a topic: Accessible PDF (tagged PDF) and (accessible) EPUB with Publisher?
  6. David Cake
    The lack of support for writing systems other than left to right is a major flaw in the Affinity suite. For many many potential users the lack of these features renders the apps unusable. For example it’s mandatory for many government agencies to provide texts in a variety of languages. This is not a new requirement. I’m literally kind of shocked Affinity created a text layout engine without considering this.
  7.    David Cake reacted to a post in a topic: Arabic language on iPad It’s not supported
  8. David Cake
    Bar and QR codes is the sort of thing I expect will be relatively easy to do as a plugin, or even script, once the scripting and plugin features are available. Calendars too.
  9.    David Cake reacted to a post in a topic: New features expected in Affinity Studio
  10. David Cake
    Internally, the way to develop a scripting API is to create a low level (most commonly C, as it is in this case) API, and then write bindings for that low level API for your scripting language. You can then release the low level API too if it is sufficiently robust and well documented. So yes, they are being developed together and makes a lot of sense - and hopefully the C API means it will be possible for other languages, both high level/scripting languages (I’d like to see Python), and other low level languages (I like the idea of a Rust crate).
  11.    David Cake reacted to a post in a topic: Scripting
  12.    Ruka reacted to a post in a topic: Accessible PDF (tagged PDF) and (accessible) EPUB with Publisher?
  13. David Cake
    Currently the lack of variable font support is a real problem, and becoming a bigger one. This sounds like it is worth investigating as a possible solution.
  14.    David Cake reacted to a post in a topic: PLEASE add support for Color SVG Fonts!!!
  15.    David Cake reacted to a post in a topic: Variable fonts support
  16.    David Cake reacted to a post in a topic: Add New Languages (from right to left) LIKE ARABIC... CAN GIVE YOU MORE SUCCESS!
  17.    David Cake reacted to a post in a topic: Publisher workflow proof of concept
  18. David Cake
    I don’t understand why you put so much effort into these arguments that for all practical discussion of the topic at hand seem deliberately obfuscatory. Yes, Rosetta and similar technologies exist. Yes, JIT compilation makes the distinction between interpretation and compilation less clear, especially when incorporated into language design (eg Julia), yes internal intermediate byte code format exists in some compiled languages, yes some virtual machines byte codes have been hardware implementations. But none of this is very relevant to discussion of why you would want either an interpreted scripting language or a compiled binary API as an extension language for a native application, and most is theoretical at best, positing whole technologies that would need to be created.
  19.    Frozen Death Knight reacted to a post in a topic: Scripting
  20.    Frozen Death Knight reacted to a post in a topic: Scripting
  21.    PSDfield reacted to a post in a topic: Accessible PDF (tagged PDF) and (accessible) EPUB with Publisher?
  22.    SallijaneG reacted to a post in a topic: Accessible PDF (tagged PDF) and (accessible) EPUB with Publisher?
  23.    R. C. Schletty reacted to a post in a topic: Accessible PDF (tagged PDF) and (accessible) EPUB with Publisher?
  24. David Cake
    I, sadly, can only add my voice to the chorus here. Essentially, not being able to produce tagged PDF makes Publisher simply not usable for a wide range of work - particularly, in many countries all government work. I’d be happy if it required you to do some work to get it to full PDF/UA compliance. But tagged PDF really needs to come from within the app. It would be great if Affinity gave us any indication at all of the state of these issues.
  25. David Cake
    Which do not actually go cross-platform, just cross architecture if the operating system uses both, which would be of essentially zero relevance here. You can consider that you have moved the goalposts sufficiently to consider yourself as having won by your own definition if you wish. But it’s irrelevant to current discussion. Yes, you can create binaries for multiple OSes if you use a cross-platform code base, but it’s not the same as running the same binary on multiple code bases, which is generally pretty trivial with an interpreted language - and certainly possible with bytecode compiled languages. Though in practice, it often compromises your product significantly (why Java apps are not popular). WASM may prove to be an interesting alternative, but isn’t quite there yet.
  26. David Cake
    Right. If you use a language that isn’t a traditional compiled language that compiles to executable code, but instead compiles to a byte code that requires a run time VM, you can do things a traditional compiled language can’t do. This is just word games with definitions.
  27.    chessboard reacted to a post in a topic: Scripting
  28.    deeds reacted to a post in a topic: Scripting
  29. David Cake
    Indeed. And there are a few things that traditional compiled languages can’t do, like relatively easily exchange the same code across platforms. And a lot of the hardware or OS is accessible from scripting languages via libraries anyway. And often you aren’t really getting much speed advantage from compilation when most of the actual computation is going to be taking place inside the host application anyway. And for everything else, there is the C API. C isn’t my favourite language either, but the C ABI is the lingua franca across interpreted languages, and if you have a C ABI it’s not that hard to whip up a FFI to call it from Rust or whatever else is your favourite.
  30. David Cake
    If there is a supported C API, that will be enough to create a plug-in that supports Python. If the JavaScript API is a direct wrapper around the C API, such a Python API would be able would be do anything the JavaScript one could. If necessary, I’ll write it myself. And open source it. Regardless of what language people prefer for personal taste, languages are used by different communities, for somewhat different reasons, and multiple options are better than less. I think the teams choices are sensible - an officially supported scripting language is necessary for this to be a feature that is of value to many customers, and JavaScript is probably the most popular choice - but the C API is the real magic here, and they know it. And it’s great that it we will have the option to make our own scripting options, because we might want to do some thing differently than the official JavaScript API.
  31. David Cake
    I'd really rather have good support for system wide font managers, than an Affinity suite only one.
  32. David Cake
    To what extent would scripting and automation support solve this issue? For example, if you could have a script that opened each photo, performed a bunch of operations in Photo, saved the changes, and did that for each photo in a batch of hundreds/thousands?
  33. David Cake
    CJK and RTL text support is such a glaring problem for Publisher as a corporate in an international environment, and of course a huge problem for many users. While it is obviously a big change that will require significant rewriting of their text and layout engine, I would really urge Serif to tackle that project and not just leave it as a glaring lump of technical debt at the heart of their apps. I really think it is significant enough that it should be on the radar for the v2 timeframe.
  34. David Cake
    Hidden text marks is a great idea for a feature to be supported in the API, when it finally arrives.
  35. David Cake
    It’s true that variable font support is more advanced in the web world, and that variable fonts are more compelling in web applications. But they are certainly where a lot of the interest in new font development is, and the Affinity suite certainly comes across as behind the times without it. There are some compelling creative effects you can do with them too. And often people try to create a unified look across web, PDF, and print. If you can’t use variable fonts you can’t do the web side as well. it’s a real issue for people doing eg a corporate branding, or developing resources that are available as web pages or downloadable resources. Frankly, lacking variable font support is a bit embarrassing for a 2022 app. And once they fix that (which should be near top of the list for features to add), color fonts are becoming important for some similar reasons.
×
×
  • 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.

 Accept Cookies  Reject Cookies