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

michalmph

Members
  • Posts

    20
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay, that one was pretty cool. You'd record a sequence of actions in software by clicking around. They'd get written to a file in that hexadecimalized obfuscated code. You could copy that and include in the script, it would get evaluated like normal code. It had a bunch of undocumented functions and features that you could only get that way.
  2. @Jon W@Tim France@kimtorch Guys, this is it. This is probably the most important event in this thread, next to the actual feature announcement. I understand Kim's irritation. Let's just get over this and work towards a good scripting system that recognizes client's needs. I come from the graphic design side. I barely dealt with in-line text formatting. The 400 pages catalog took 24-27 minutes when rendered to viewport in InDesign CS6. This process required saving every 15 pages so InDesign would clear an internal memory buffer, otherwise it could crash randomly. I couldn't get it to work headlessly or by generating the IDML, and there was never time to refactor. To give you a scope of the problem: I had no idea about the text formatting tags. No one taught me that. I didn't find it in the documentation. I didn't know it existed. I used InDesign's built in formatting tools to set styles (line numbers, paragraphs, etc). I can write an RPA that syncs multi-user input from Photoshop and Illustrator, merge them into an individual asset, and push it to a desired position in an InDesign doc. Or do automatic asset management if you need to develop POS for 30 store locations, each with different dimensional requirements. I could stack hundreds of regexes to process stuff without conflicts. But I didn't know about the text tags up till now. (thanks btw :D). I'd suggest you guys figure out how to get meaningful feedback that would let you write a feature spec and gather necessary documentation reference. This thread is peanut gallery, and we need an actual need assessment, and features based on the results.
  3. +1 to Linux support, even if it's officially through WINE. Some 3d pipelines use Linux extensively (Houdini, Mari, Blender, and a few others have Linux variants), but there's no good native graphic and vector editing tools. Some competition from Krita and Inkscape. No competition in DTP, unless Sphinx counts 😄
  4. Here with a little bit of a business perspective. Be there when it's usable and legally settled, not when the bubble bursts. There's no point in diverting dev assets to AI stuff. Most of the development of AI tools is opensource. Companies that try to turn profit on the AI generators are rarely innovative regarding their technologies, with notable exception of data giants, who also have the resources to tackle the lawsuits coming their way. That brings us to another issue: regulation. While Adobe may offer lawsuit cost coverage to users, I think Affinity would prefer to focus on something else, and artists would prefer to have a safehaven while things settle down. AI is very problematic to artists and creators right now. Whatever camp you're in, this is a fact and it needs to be recognized. There's regulation coming about, and it seems it will be region-specific, with differences between EU and US visible already. Depending on the outcomes, you may have to phase out the solution, region-lock it, or do other PR-damaging stuff. Digital asset management tool, as per @Stephen Coyle post from the other thread, would be a much better resource allocation. And Linux support. There's no competition and no coverage there. Great post, great analysis, on point. One bit of misinfo: you can deploy image generative tools on consumer GPUs very easily, and you don't need cloud services for fast generation - Nvidia RTX 20xx/30xx series are already capable. Getting a good pipeline for StableDiffusion via plugins sets you miles apart from Adobe quality-wise, although having higher technical requirements from the user, and dodging/dilluting legal support. Language models are becoming deployable locally as well. Which is, sadly, reflected in the amount of trolls spewing FUD on this forum 😑
  5. @tzvi20@Old Bruce Thanks! Would be great to get an announcement when it hits the beta, I'll jump on the possibility to test it.
  6. Good opportunity for you guys. Adobe is in a weak spot right now, since they migrated from a built-in ExtendScript to VS Code plugin causing a lot of confusion in their community. It's probably one of the worst moments to get into their scripting environment right now. I don't know what they intend to do with it in the long run, but right now it's a mess. My suggestions: - Provide examples of API calls from different programming languages. - Good documentation, self-documenting if possible, including listing parent/children functions, allowable types, working examples of usage. Minimize friction. - Focus on good Data exchange, especially in DTP. Moving frame parameters back and forth into Publisher would be great - from keeping texts in version control or easily editable in Google Docs, to exporting numerical frame parameters to CSVs for fast manual edits, creating IDML templates, etc. Regarding IDML - check out the activity around https://github.com/Starou/SimpleIDML - they tend to attract people with particular usecases. - Provide some means of code obfuscation, so people can create commercial plugins and sell them. Are the scripting features available to betatesters?
  7. @chocolatkey That's what we need more of in this thread - actual case studies. +1 to "record action and convert to script" - AFAIR this returns an obfuscated version of user-performed actions in ExtendScript, I've used it in a few tight spots when automating the pipeline. Similar thing exists (or used to exist) in Blender, where you could see the Python calls to operations while performing actions - basically, you had an API level log of actions performed by the user. That would be great. Talking about obfuscation - I think plugin developers might want to protect their IP in some way. Giving them tools to do that would be nice, so their work doesn't automatically become opensourced. That's a prerequisite for a good marketplace ecosystem and user-profit model. Adobe uses a really primitive and easily reversible obfuscation. Personally, I used to work with very big catalogues that needed a lot of changes parallel to the design process. I'd extract the 'data layer' of the document, like frame contents, image links, product prices, and whatever was becoming an issue, place it in Google Docs, and multiple people could amend the changes simultaneously. The changes would then be backported to the document automatically, with minimum engagement of the graphic designers.
  8. Seconded, rough roadmap and an estimated target feature list would be great. We could plan out testing and implementation in the pipeline.
  9. Personally, I'm beyond building emotional relationships with the technology I use to get the job done 😉 We probably get the best of both worlds - gets as high-level and as low-level as practically possible, with very sane defaults considering the demographic. Technically, I think it would be nice if the default JS integration was built on top of the C api, so they would match feature-for-feature. I kinda suspect it's gonna be like that, because that means Serif doesn't need to maintain two distinct solutions. In that case, it would be nice if the JS implementation was opensourced, even retaining copyrights - the non-JS-inclined people and addon devs would get a lot of delicious and testable API usage samples. That has been a source of great confusion with Adobe ExtendScript documentation, in many areas you had to go by feel on what data types are accepted by a function, sometimes to the point of documentation being not only vague, but plain wrong.
  10. ❤️@TonyB Great news! Thank you for officially confirming this. It's a lot of reassurance for us scripting people to know it's on the horizon, even if it takes a lot of waiting. Good move on JS support IMHO, as it onboards the existing Adobe scripters with the necessary DTP expertise, and a lot of the frontend guys.
  11. I feel you, it was the same for me. The programming language question used to be a legitimate concern due to specialist availability, but I think it's been solved a few posts ago (recommendation for language-agnostic API). For some reason people still find it necessary to post their preferred languages. At least the thread gets bumped, I guess. I'm subscribed in hope that we'll get an update from Affinity about the feature, but I'm not getting my hopes up. We had a time window at work where we could have started using - or planned for - Affinity apps in the pipeline, but that's no longer the case. Now I'm just curious if the feature gets released, and if yes, will it'll bring some interesting stuff to the table that I could use personally.
  12. That post really reads like an advertisement. I think we've kinda agreed that having a language-agnostic API would best for both Serif and their users. Its risk-free, future proof, and lets users use whatever language they like. The real important question is, are we getting this feature, and if yes, when.
  13. I wrote this in another thread some time ago, I'm not against "Serif" way of doing things. If the equivalent of writing addons would provide the same features as scripting does in current Adobe pipelines, I'm all in for that. Doing things differently is good. It opens possibilities. As long as the features and the documentation allows us to mirror, migrate, or integrate with, the existing pipelines. To me, the most important aspect of scripting is not about having fancy new design features. It's about reducing the time the humans need to waste on inhumane tasks. Identifying the error-prone, manual, repetitive and labour-intensive tasks, and automating them, so no one has to do them anymore, forever - and instead focus on the more enjoyable and fulfilling parts of desktop publishing and graphical design.
  14. Do you think this could be summarized as below? 1. We need a language-agnostic scripting interface thats: - officially supported for a few main languages (AppleScript, VBA, JS - for compatibility reasons with Adobe apps, for out-of-the-box deployment and seamless integration with existing solutions) - documented well enough so we can write libraries/packages for other languages (Python, Lua, etc - means opening up to community support, maybe?) Having deployable network instances, alike Indesign Server, would be cool though. You could just push computationally intensive worktasks and batch operations to a network instance without occupying the local machine. Its orthogonal to apps acting like servers, just a thought. I think we should focus on features rather than technical means of how to achieve them. If Serif decides to implement a scripting feature, it's probably going to be dependent on the internal architecture of the apps, and long-term support by the programming team. Suggesting technical solutions of a problem is impossible without knowing the underlying constraints. Besides, this thread is 2 years old, and Serif may have already done work on it that renders this discussion invalid. Calling @Patrick Connor Is it possible for you, or anyone at Serif, to give us any updates on a scripting feature, or a current/planned functional equivalent? original post:
  15. And yet, this particular "feature" has given us a lot of awesome technologies that browsers and virtual machines use currently, which might not have happened if JS was designed well from scratch A website can currently run arbitrary code on your GPU without having it escape its sandbox. You can run interpreted code with crazy performance. And so on. All programming languages suck in one way or another. All people have preferences and opinions which languages suck more than the others. That's why discussing this is pointless. Especially that a good API should be designed as language-agnostic, and then bound to preferred languages, or enable wrapping itself to anything meaningful. Python or JS today, Haskell or Rust tomorrow, design it well once and you won' t have to do it again.
×
×
  • 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.