Tim France

@julwest78 I have good news and some not-so-good news. The good news is I've found the reason for the bad import and have put a fix into Designer. Now your file will open normally and look like this: The not-so-good news is it is highly unlikely I'll be able to get the fix into v2.2 as we're quite far through the beta cycle, so unfortunately this will probably have to wait till v2.3. Regards, Tim

Hi @julwest78, I've taken a look at your file. There is a proxy entity in it, which designer warns you about when it opens the file, but I don't think they are the cause of your problems. If you choose "Single Page" on import and select the only paperspace layout available (called "Presentation1") you get a blank document. This is correct behaviour and AutoCAD does the same thing: If you choose "Model" on import, Designer imports the document but has had to zoom out by such a huge amount, you can't see anything. That's because Designer thinks some of the entities in the model are a huge distance from the rest of them and to display all of them, it zooms out. If you do a Select All (Cmd+A or Ctrl+A), you will see a bounding box around all of the entities and that box is massive. If you zoom in on the corner of the box that's on the spread and enable Hairline View mode (View -> View Mode -> Hairline), you will see your entities appear: You could select just these entities and paste them into a new document, then scale / rotate them as a work around. I will see if there's a legitimate reason why Designer thinks there are these huge entities in your document (like in Layer ERLBT00L_ElectriciteBT). Regards, Tim

Sorry, for a few reasons that's not something I can get into at this stage. Similar to StudioLink, Photo-specific scripting functionality will be available from any product as long as you have a Photo license enabled.

Couldn't agree more, that's one of the reasons we've put these examples up. However I should re-emphasise that the examples don't represent everything that's possible with scripting, even at this early stage. It's ok to find the examples underwhelming: Note: "just to demonstrate" and "basic" But like I said, constructive feedback is welcomed, just don't worry that this is all you're going to get. This next bit is mainly for any devs who might be reading this. The Javascript API is built entirely on top of the C API. Actually, it's built on top of a header-only C++ SDK that minimally wraps the C API so we don't have to worry about explicitly deallocating any handles that might be used. We've not cheated and called directly into the Affinity backend from the Javascript layer, it's all going through the C++ wrappers and therefore through the public C API functions. This is great for testing, as tests written in Javascript exercise all abstraction layers. We will likely release the C++ headers along with the C headers. There is a low-level Javascript API that is as similar to the C API as possible, which has the benefit of reducing the amount of documentation we have to write. There are some differences between function signatures, but essentially they are the same, with each C function "projected" into Javascript land. We then provide a set of JS files that wrap those exposed JS functions into ES6 classes and hide a lot of the boring boiler-plate that no-one cares about. For maximum performance, you'd use the C or C++ layer. For convenience, you'd use the high level JS layer, which is what the examples use. For Javascript consumers who want to design a different OOP layer, they are free to require() the API functions directly and wrap them up however they like. I would say that as a dev coming from a mainly C/C++ background, I was surprised at how performant the Javascript levels have turned out to be.

Yes, there will be some notion of a plugin / add-on package and they won't have to be single-execution-and-stop scripts like in these examples. I'm not in a position to promise anything (even with the bribe of a cuppa) but we have done some work on panels because it feels like having some built-in support for UI would be of value.

Yeah, I appreciate the gifs aren't great, so that's why I added the mov attachments so you could take a look at the code. We do have an fs module and it's loosely based on node's, but I feel I should reiterate the disclaimer that none of this is guaranteed to stay in its current form. If you look at emoji.mov, you'll see let table = fs.readFileSync('/Users/tim/Documents/emoji-translations.csv') .toString('utf8') .split('\n') .map(line => line.split(',')) .filter(arr => arr.length == 2); We've got the callback version of read, write etc. too. We aren't going to be node, nor are we going to try and be a web browser, but we will likely draw inspiration from both.

Nothing is off the table, but we're only just getting started. All 3 of those are things the team has discussed at some point.

@Old Bruce like this? I'm only showing a small amount of what we've done And like @Patrick Connor says, there's tons more to do. rename selection.mov

That's a good idea. I'll get it moved.

Hi folks, I thought I'd give you a quick progress update and let you see some of things we've been working on at Serif Labs. We now have a scripting core that we're reasonably happy with and have put together a little test area where we can run Javascript code, so I thought I'd show you some of that. Things to note: This is all VERY early, like pre-pre-pre-alpha. The JS API is extremely fluid and is constantly changing. This is not how the Affinity suite will run scripts and plugins; it is just a sandbox window for internal testing. There is still a huge amount of work to be done. I can't provide any timescales for when scripting will be publicly released, for Beta or Retail. Constructive feedback is welcomed, but I won't be able to answer all questions - see previous points. I'm not claiming any of these examples are particularly useful on their own; they're just to demonstrate some basic scripting functionality. Re Javascript async - yes, we support it, I've just not recorded anything yet. The sleep calls are there for screen-recording purposes only. Here are some demos as low-res gifs. If you want to take a closer look, movs are attached. Create a Mandelbrot image Some dodgy physics Insert a dragon curve "Emojification" (translation?) of text Create a grid of colours Select and hide based on hue Replay a document's edit history mandelbrot.mov balls.mov dragon.mov grid.mov hue.mov replay.mov emoji.mov

Hi @woefi, The dashed lines is strange. If you can send me the file, I'll take a look, Regards, Tim

Hi @joe_l, I'd suggest it is a simplification rather than an enhancement. As well as preventing the creation of HUGE documents, the changes remove ambiguity and mean the "correct" thing is done all the time - this is what your drawing actually looks like. Because many CAD packages don't render lines on-screen with their specified weights, it's very easy to forget to update them to something appropriate for your drawing. The default line weight is 0.25mm so if your drawing's dimensions are sub-millimetre, you should really change your line weights to something more appropriate, but we understand that isn't always a priority when making a drawing. We added the hairline view mode specifically for dealing with drawings which have inappropriate line weights and to make Affinity feel more like Autocad. The ambiguity I was referring to is the "Fit Model to Page" option would apply an arbitrary scale to your drawing. Most of the time, the page size isn't specified for model layouts in DXF files, so the software would have to default to something. While that may look nice on screen, you'd get nonsense results from things like the measure tool, or even worse, you'd get results that are almost correct, but not quite.

Hi @woefi, We made the changes to the import options because it was possible to specify combinations that would ask the app to do crazy things (e.g. make quadrillion pixel documents). In your case, I'd suggest either: 1. Turning on the hairline view mode, which will render lines without their weights, just as Autocad does. This is likely the preferable option as it means things like the measure and area tools will give you correct answers. 2. Overriding the insertion units to something larger. You could correct the measurements with a custom drawing scale after import if necessary. Hope that helps. Tim

As a member of the team working on scripting, I can assure you we are not feeding any kind of AI with prompts

Hi @Intuos5, Thanks for reporting this. Both issues have been fixed and will be available in the next release. Regards, Tim