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

Jon W

Staff
  • Posts

    125
  • Joined

  • Last visited

Everything posted by Jon W

  1. 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?
  2. 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.
  3. 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.
  4. 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).
  5. We are planning to allow custom live filters at some point. It would be possible to write one that used GLSL.
  6. 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?
  7. 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.
  8. 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.
  9. This is the approach we are taking. In our world, scripts are just interpreted plugins, with the exact same capabilities as compiled plugins.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. Hi Ezbaze, We'll have our hands full with JavaScript for the foreseeable future, but we aren't ruling out other languages eventually. In addition, the JavaScript engine is itself implemented using our plugin SDK, to which we plan to add support for alternative scripting engines (i.e. you could in theory write your own plugin to support Python or any other language).
  15. Hi Intuos5, Yes that's correct - the plan is that commands exposed by scripts/plugins will appear in the Shortcuts settings page, alongside native commands.
  16. That sounds like you're using the Crop tool in "Resample" mode. The other modes should just crop without resampling.
  17. Hi @GoldenDesigns, thanks for confirming. This should be fixed in the next update.
  18. Hi @GoldenDesigns, It's possible that this problem is caused by changes to tablet input in 1.8.4. Please could you try following the instructions in this post:
  19. Windows lnk spatial precision is also pretty bad - technically it's sub-pixel, but in practise you only get about 2 points per pixel.
  20. Hi @AlainP, Both these problems have been fixed in 1.8.4.674. The reason we have changed tablet input in 1.8.4 is to improve the precision of pen strokes (see @Aongus Collins' example above). Originally we had a Wintab-based "high precision tablet input" option, but this was unreliable so it was never enabled by default. In 1.8.0, we tried replacing that with a Windows Ink-based solution, but that brought its own problems. So in 1.8.4 we have returned to Wintab and fixed the original problems. It is still possible to use Windows Ink, by running Affinity with the --disable-wintab option and turning on Windows Ink in the tablet driver settings. This is worth a try if you're still having problems in 1.8.4. There is currently no way to return to the "low precision" tablet input that existed in 1.8.3 when Windows Ink was turned off in the app. But given the poor quality of the resulting brush strokes, that is perhaps not such a great loss.
  21. Just to add to Chris's recipe: hovering the pen over the document again should restore mouse responsiveness.
  22. To all users who have experienced this problem: please don't delete any fonts or rebuild the font cache. The current beta should fix the problem without doing that. If it doesn't, please let us know! Thanks.
  23. We will be investigating this issue. There are many aspects to consider.
×
×
  • 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.