Tim France

Hi @yesterdayjones, I can confirm that this is a (different) bug. It has been fixed and will be available in the next development cycle (2.6.0). Thanks, Tim

A QR Code stores only 1 payload type. If you choose URL, that QR code shape will store the URL and nothing else. You can verify this by creating a QR code with a URL and populating the vCard fields in the editor (make sure you switch back to URL after you've filled in the vCard fields). If you then save the document, restart the app, reopen the document and edit the QR code, none of the vCard fields will be populated. This is by design - there was a concern that you could accidentally leak information if all the data was stored in the QR code itself. It's the editor that remembers the last settings for each payload type. It does not persist them between app sessions or in documents.

The button missing on Windows has been fixed, but we just missed this beta. Re AF-3024. All the other shapes retain their data across documents, so making QR codes do otherwise would be an exception to the norm that might cause more problems and confusion, so the Clear button was added as a compromise.

Hi @Hangman The same effect can be achieved by reducing the size of the QR - is it that it could be specified in modules that you like?

Yeah... vCards are loads of fun. The vCard "spec" (it's kind of standardised in a few RFCs) states that fields are terminated with CRLF. Not LF, not paragraph separators, but "\r\n". Multiline fields (e.g. notes) must use slash n (i.e. "\\n") to escape their new lines. An earlier iteration of this editor only had a single multiline text field and I actually replaced paragraph breaks with CRLF in it, but then there's every possibility that someone will say "no no no! Don't do that! I deliberately wanted paragraph breaks in my Text data!". Here's the kicker - some versions of Android's scanner will accept some exotic unicode breaks instead of CRLF! But the iPhone I tested that on flat out rejects it. TL;DR I thought automatically replacing paragraph breaks with \r\n was a good idea but it breaks functionality for other cases.

It still is - you can type this in the "Text" type. Perhaps this lends support to the suggestion it should renamed "Custom" or similar. Note you should percent-escape your data though (however some QR readers don't mind if you don't)

The QR code objects do not retain any extra information other than their specified type. The extra information is shown and saved in the editor only so you can easily create different types of QR code without having to retype a lot of information each time.

My mistake. I'm sure you take the point though Anything is "legal" in a QR code - it is just text (technically it doesn't even have to be that - you can have raw byte data if you like). The only thing that makes a particular type is how it is formatted / constructed and if it is supported by the QR reader. There aren't any official standards, just conventions that most QR readers follow... but even those differ between Android and iOS.

What about the American style 1-800-CALLDAVE?

Yep, I think that's fair!

Well... maybe. But the WhatsApp help specifically states the link should be formatted as described in the tooltip. See https://faq.whatsapp.com/5913398998672934 You could argue that it strip leading zeros, but that leads to this next problem: There is no standardised format for phone numbers, so validating it isn't really feasible. Even if I tried to validate against some common formats (I did initially), there are many locale-specific rules and conventions that don't follow them, but are valid in certain regions. I felt it best to leave it up to the user to get it right. Going back to WhatsApp, I could strip zeros, but then should + be stripped too? What about spaces? The automagic could significantly change the number. I think the most sensible approach is to validate against the official WhatsApp spec.

Hi @Seneca, I don't really have anything specific to say other than the team is still smashing out APIs! We've also had to go back and do some of the less interesting "that can wait" tasks, such as dealing with shut down properly e.g. you start running a script and then decide to shut down the app halfway through its execution - we need to make sure things like asynchronous ops are properly aborted / synchronous waits end gracefully. We've also been re-evaluating the high level JS layers to make sure they were intuitive and usable. We went hell for leather to get bits of the app exposed, but didn't do them in a particularly good way e.g. this kind of sucks: let clrData = new RGBA8(0, 0, 255); let clr = new Colour(clrData); and should be something much more concise like: let clr = RGB(0, 0, 255);

Hi @kimtorch, Could you clarify on what you mean? Are you referring to parsing some text with tags in them or do you mean tagging text frames / individual bits of text with a tag and then have a script use those tags to find and manipulate bits of text? I'm assuming the latter because the former doesn't require app support - it would just be a case of writing a script to parse the text. If you mean tagging bits of the DOM (like text frames) or individual glyphs within a story, that is something we're already considering. Could you describe a standard use case?

This. The scripting devs are going to have to dedicate a significant amount of time towards documentation. We can't expect our docs team to document the ins and outs of an API (technically multiple APIs), it's simply not fair or realistic. Besides, we'd have to tell them what to write, which would mean pretty much writing the documentation anyway. Sure, they'll be able to present it in a way that looks good and integrated with the normal app documentation, but the devs are going to have to provide much of the content. We're planning to use one of the many available documentation tools to do most of actual generation for us. The current favourite is Doxygen, largely because most of us have had at least some exposure to it. Please remember too that the scripting team sometimes has to do bits of work away from scripting development. As the dev who wrote the DWG/DXF importer (and now exporter - see here 🙂), I tend to be the one tasked with its fixes and improvements. The same goes for Move and Shape Data Entry. Everyone in dev could put in those fixes, but it makes so much more sense if I do them because I'm most familiar with the code and should be able to do the work faster. The members of the scripting team do spend most of their time doing scripting work, but it's not 100%.

Hi @Bruno Jolie, I've taken a look at your file and can confirm it is a bug in Affinity. The problem is the file contains a single Polyface Mesh, an entity that Affinity does not support. Once we've skipped over that during import, there is nothing left in the document and due to a particular set of circumstances, things go wrong. I've fixed the crash and while I was in that area, I added support for polyface meshes. The changes will appear in a future version of Affinity (likely to be 2.4) Tim