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

michalmph

Members
 View Profile  See their activity

  • Posts

    20

  • Joined

  • Last visited

 Content Type 

Everything posted by michalmph

  1. michalmph
    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. michalmph
    @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. michalmph
    +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. michalmph
    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. michalmph
    @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. michalmph
    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. michalmph
    @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. michalmph
    Seconded, rough roadmap and an estimated target feature list would be great. We could plan out testing and implementation in the pipeline.
  9. michalmph
    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. michalmph
    ❤️@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. michalmph
    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. michalmph
    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. michalmph
    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. michalmph
    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. michalmph
    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.
  16. michalmph
    Is this thread turning into a battle of which language is better, with no support for any language anywhere on the horizon? From my point of view there are two really important questions right now: 1. Is there going to be a scripting feature of any kind that lets me automate stuff and integrate Serif apps with my current Adobe pipeline? (api calls, plugins, inbuilt script editor, whatever, as long as there is documentation for it) 2. If yes, are there any estimated timelines when it becomes available? Until these are known, there's no purchase decision from me. Additionally, I don' t think that there is any point in discussing language support and approach to scripting at this stage - because of the two points above, and because it's Serif's business decision that should be based on their analysis of the market and client base, not personal preferences of a bunch of people with varying degrees of experience on an internet forum. To put it bluntly - I'd prefer to have good job security with Affinity apps scripting in my portfolio, rather than having the apps support my preferred language.
  17. michalmph
    Elements that exceed the artboard are not visible on bleeds. Lack of control of what appears on the bleeds means artifacts on print artwork edges when machine-cut in the printhouse. Also, most likely a bug: I'm currently doing a looping design using symbols (via this thread) and the symbols turn on and off non-deterministically when I place them outside of the artboard, aligned to the artboard's edges. Suggestion to add pre-visualization of elements outside of the artboard on toggle (for example the \ key, mentioned before - clip to canvas visibility). Process of working with a clipping mask to toggle artboard visibility in Illustrator worked well, currently with Designer it causes issues. I'm not sceptical to the feature itself, it seems useful, although requiring a completely different workflow. The way I see it is that artboards in Designer are something different than in Illustrator, and are more of a print preparation thing rather then design tools. Considering that this thread exists, could we perhaps get a workflow demonstration video that covers the expected use of artboards in context of the issues people posted here?
  18. michalmph
    @sfriedberg I used to render from Illustrator to smart layers in Photoshop, but I don't want workarounds anymore. I want to see the design and the intersections as I work on them. Workarounds affect the final design and waste a lot of time. That's why I wondered if there is a solution or best practice to do this in Affinity. @telemax Perfect. Thank you!
  19. michalmph
    How can I visualize a looping design that's to be printed on a tape? Two cases where I encounter this most often: 1. product label design, where the label is glued around a cyllindrical shape (bottle, paper tube, can) with an intersection - so that one end of the label is glued on top of the other after it's wrapped around the packaging 2. continuous tape designs for print or custom adhesive tapes Actually, I think my question is a subset of "how to generate looping patterns", but all the materials I found on this did not show any visualization tools. I end up copy-pasting the design and modifying it by eye, which is imprecise and time consuming.
  20. michalmph
    I'm looking to get invested into Affinity software. I love the programs so far, but scripting is a must have for me. Did we get an official decision from Serif if scripting is going to be supported in the future? If yes, any rough timelines? Most of my commercial work is DTP process automation and pre/postprocessing with Photoshop Illustrator and InDesign. I see many people posting preferences for scripting languages in this thread, so I'll give my view on it as well: - Python has huge amount of libraries for most tasks, and in recent years became supported by an increasing amount of applications. Many people learn it as their first language in the academia, and it's steadily growing in popularity in the last 15 years. (source: https://insights.stackoverflow.com/survey/2019 and https://pypl.github.io/PYPL.html) - Javascript is the original cross-platform language supported by the Adobe ExtendScript software. A lot of people using the Affinity software for UI design and web development most likely come with it as part of their skillset. Personally, either is OK for me, with a heavy preference towards Python.
×
×
  • 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