Jump to content

Jon W

Staff
 View Profile  See their activity

  • Posts

    136

  • Joined

  • Last visited

 Content Type 

Everything posted by Jon W

  1. Jon W
    Please rest assured that the Scripting feature is still very much in active development, and it will definitely be appearing in a future release. It is company policy not to share information about timelines for upcoming features/releases.
  2. Jon W
    Sorry @Affinityconfusesme, I'm afraid we can't give out any information about such things.
  3. Jon W
    You appear to be describing compilation with fast-math flags. When these are used, it is a deliberate decision to sacrifice accuracy for speed. A JavaScript (or any other language) interpreter compiled with these flags would not be fit for general purpose use. Er, what? I said that 64-bit doubles have sufficient precision to precisely represent integers up to 2^53, i.e. such doubles can be used for precise integer arithmetic up to this value. Again - this issue is not specific to JavaScript. There are indeed multiple implementations, but obviously we are only using one of them. If this (or any other) implementation's JIT compiler produced non-deterministic results, that would be a bug which would need fixing. However we have never observed this, nor any discrepancy between JavaScript and C++ arithmetic, and have no reason to suspect any such issues exist. If you have example code to produce such an issue, then please do let us know. Yes - Python (like many languages) does have some advantages. We considered these when making our choice of language, as we will for any languages we may support in the future. But making specious claims about hypothetical numerical precision problems won't change anything.
  4. Jon W
    I'm not sure what you're referring to, but I don't think it's Python's native float type, which according to this is a standard 64 bits (i.e. 53 bits of precision, ~15 significant figures).
  5. Jon W
    If they can't, it's nothing to do with what language they're written in. That won't make any difference. Floating point operations are handled by the CPU; the results will be identical whatever language you use.
  6. Jon W
    Sorry Peter, I'm afraid we can't comment on timescales for upcoming features.
  7. Jon W
    Just to (hopefully) draw a line under this scripting language debate: We chose JavaScript (ECMAScript) for reasons that I'm not going to go into here! JavaScript floating point precision is as good as any other scripting language we could have chosen. Although its native number type is floating point, integers up to 2^53 are represented precisely; if you need more then there's BigInt. If you need integer truncation then there's Math.floor. In other words: it's not a problem. Our JavaScript SDK is implemented as a plugin and built on top of our C++ SDK. This means that although we currently have no plans to do so ourselves, it will be fully possible for anyone to implement "first class" support for Python or any other scripting language.
  8. Jon W
    The "Copy items as SVG" setting means that items are copied as SVG in addition to our native format. This is for pasting items into external apps. When pasting in Affinity, we always prefer the native format if available - we don't convert back from SVG.
  9. Jon W
    Well... I can tell you that scripting development is still going strong and progressing as planned. There's a lot still to do, but rest assured: we'll get there eventually!
  10. Jon W
    Care to elaborate? JavaScript uses the same 64-bit double precision numbers as every other common language, which Affinity also uses internally. So it's perfectly capable of manipulating any aspect of our documents with no loss of precision.
  11. Jon W
    Hi @Peter Werner, I can confirm we are planning to add support for this. In addition to getting/setting metadata via scripting, we also plan to support setting metadata manually (likely by extending the Tags panel); this is useful for e.g. creating a template document containing placeholder objects which a script can then populate.
  12. Jon W
    Hi @kimtorch. We are doing our best to engage with our users and understand their requirements. Our primary focus is to expose existing application features to scripts/plugins; text support is just one part of this. We are software developers, not publishers, and although we often liaise with the Publisher team regarding text matters, they are not really scripting experts. So you might have to explain some things that may seem obvious to you. We are aware of InDesign text tags: as I understand it, they are primarily used to map to text styles on import. What we're trying to understand, and I hope you can explain, is how this relates to scripting. I would guess that perhaps you envisage a script which would run as a tagged text import filter, overriding the tag -> style mapping which would normally be set up manually in the app?
  13. Jon W
    I'm happy to report that SDK development is progressing well. We are steadily working towards exposing enough app functionality to make useful plugins, but there's still quite a lot to do before we can consider even a "technology preview" release.
  14. Jon W
    Thanks everyone for all your suggestions - please keep them coming! They are all useful. Initially, we'll be concentrating on exposing existing functionality - primarily, manipulation of documents and their contents. Then later we will be able to move on to some of the "new feature" things that have been suggested: custom tools / shapes / brush engines / personas etc.
  15. Jon W
    Thanks for the explanation. Whilst dynamic layout is certainly an interesting idea, it's somewhat outside the scope of scripting itself - it would have to be considered as a completely new feature. Although we have no plans to allow general scripts to be embedded in documents (primarily due to security issues), if we were to add such a "dynamic layout" feature then I imagine we would use embedded scripts (with limited, layout-specific capabilities).
  16. Jon W
    We are planning to allow custom live filters at some point. It would be possible to write one that used GLSL.
  17. Jon W
    We have no plans for layer/object-specific scripts. However, scripts will be able to run in the background and respond to events such as "document changed". Could you perhaps give an example of how such a layer/object-specific script would be used in practice?
  18. Jon W
    We currently have no plans to allow customisation of existing tool behaviour. However, your wish could be easily realised by a script which performs the Expand Stroke command in response to a notional "object created" notification.
  19. Jon W
    Yes - please do all feel free to post your scripting-related feature requests here! Whilst we can't promise to implement them all, it would be great to get an overview of what our customers want and expect from scripting.
  20. Jon W
    This is the approach we are taking. In our world, scripts are just interpreted plugins, with the exact same capabilities as compiled plugins.
  21. Jon W
    This is indeed what we are hoping to do.
  22. Jon W
    The SDK will be fully documented. In fact we expect it to share documentation with our Javascript library, which is largely a wrapper for the SDK.
  23. Jon W
    In some sense yes, but the term "parametric" in the context of editing usually implies that parameters can be changed after the fact (e.g. live filters). Agreed. I agree that such a feature would be a good match for custom brush plugins, but still independent. You might like to raise it on the Feedback and Suggestions forum.
  24. Jon W
    As I said last week: we aren't ruling out built-in support other languages eventually, but we have no current plans to. However, any third-party "interpreter" plugins will have access to all the same capabilities as the built-in ones.
  25. Jon W
    Hi fde101, Thanks for your suggestion. Custom brush engines is an interesting idea and we've added it to our list. Pretty much how the existing brush engine works, unless I'm missing something? This sounds like a general feature request for parametric brushes, which would be equally applicable to the existing vector brush engine and not really specific to scripting.
×
×
  • 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.