Search the Community

ChatGPT 4 Affinity Photo is going to support java script soon . Do you think you would be proficient with making scripts for Affinity Photo or it would require a whole new training and unlikely? ChatGPT The introduction of JavaScript support in Affinity Photo is an interesting development. As a language model trained by OpenAI, I am proficient in JavaScript and have a strong understanding of programming concepts, which would be directly applicable to creating scripts for Affinity Photo, assuming its JavaScript implementation follows standard practices. Affinity Photo likely has its own specific application programming interface (API), which means that while the core JavaScript language would be the same, the specific functions, methods, and processes to interact with Affinity Photo's features might be unique to that software. Learning these specifics would be necessary to create effective scripts for Affinity Photo. This would involve understanding how the API allows a script to interact with the software's features, such as image manipulation, layer management, and other photographic or graphical editing capabilities. The process would be similar to learning any new API or software library: understanding the documentation, experimenting with basic examples, and gradually building more complex scripts. Given my existing programming knowledge and ability to learn from written materials, adapting to create scripts for Affinity Photo would be feasible. However, since I cannot execute or test scripts in real-time environments, I would primarily be able to offer guidance, pseudocode, or untested script examples based on the provided documentation and API references.

It's been since v1 and/or a few years, there have been a number of comments and/or feedback re the lack of support for complex script font such as Unicode fonts for Hindi, Khmer and similar languages; unfortunately Affinity v2.2 still don't have support for such complex characters. Please make such a feature equivalant to Adobe world-ready paragraph composer. Thank you.

A few more. Get (and set) currently selected object / text cursor/range position and attributes. Get (and set) some of the common settings and current defaults. For example, a script might need to know which measurement system is in use or where files are opened from or saved to. It would be nice to be able to record actions to generate JavaScript code. Disable and enable screen redraws, with enable forcing a screen redraw. This would allow complex scripts to do things like generate hundreds of pages without bothering to refresh the screen. Some way to display a modal progress meter with a cancel button, and of course the ability to update the meter. Ability to show/hide/position/scale panels, tools, and document windows so scripts can customize the UI.

Does Affinity Publisher V2 support Unicode fonts in Indian Languages (complex script option) and RTL languages? The earlier V1 did not handle that. I use extensively all the Indian Languages. Madurai Sridhar

The font designer can only "turn-on or off" those features by deciding to use them or not. The OpenType specifications indicate which features should be On or Off by default (and most apps follow the specs). By using Initial Forms (init) and Final Forms (fina) the designer has made the decision to have these replacements done automatically by default. If they wanted these replacements to be only done by user manual selection, they would have used stylistic sets (ssxx), or stylistic alternates (salt), or character variants (cvxx), etc. - OpenType features which are Off by default instead of On by default. There are a lot of fonts which use these features (init, medi, fina) for Latin scripts. Back when you could still search MyFonts dot com by OpenType feature codes, I searched for these codes. There were hundreds of results, and those fonts are still being sold every day. The OpenType specs were clarified in 2016 to say these features (init, medi, fina) are primarily for complex scripts (i.e. Arabic). But many, many fonts were made before that clarification, and some designers still use them anyway. Adobe's own Minion 3 still uses fina in the Latin script. Many script fonts still use them because they just make sense in that situation. I love the Laura Worthington script fonts and she still uses init, medi, fina all the time. Which is why I think it is a bad idea to simply turn-off these features for certain scripts. The best solution is to provide decent font documentation (Laura Worthington's font documentation is fantastic). That way users would know what is happening and what to expect.

https://forum.affinity.serif.com/index.php?/search/&q="complex script"&quick=1

I also work a lot with Indic Complex Scripts such as Hindi and Bangla. Please add the functionality. We are planning to buy Affinity Publisher also when Affinity have this Indic Script facility.

That would be a dream come true. And let me add that we also need support of R-to-L page and section order along with TOC and indexing for such scripts. IMHO this is THE step that would make Affinity products a serious threat to Adobe's. R-to-L and complex script support is NOT only needed by countries that speak languages with non-roman-based script... Virtually EVERY DESIGNER in the world needs that now. A lot of design works are global in nature, so such support is sorely needed. Most of my work is in English, but without support for complex and R-to-L script, I can't take the product seriously, TBH. I hope they add it soon. They probably need to introduce an advanced text-shaping engine similar to the wonderful open source harfbuzz. I find it strange that open source applications like Inkscape, GIMP, and Scribus support complex R-to-L script (some more advanced than others) while Affinity products still don't...! Yes I understand they are still new products but they have ancestry in Serif's older products. At least they should let us know they are going to add support soon and release an approximate time frame. Being totally silent about this is not reassuring..

What made you wait for it? As far as I remeber Serif never said anything about support for rtl complex script support in their Affinity line.

Why do you need ANSI? Affinity is supporting Unicode fonts just fine. just not the needed special features for complex script and rtl writing systems.

Affinity simply currently does not care for complex script support. Probably economic reasons. Asking again and again won't change that.

I was so happy with my Affinity Designer trial that I was about to buy it, but the fact it doesn't support Arabic script is quite appalling, especially as free software like Inkscape supports RTL. I'm disappointed that I won't be able to use Affinity for my work but I'm even more disappointed that your development team is fobbing off a large chunk of the world. You aren't holding your hands up and saying "Ah, we don't have this yet, we need to fix this fundamental glaring oversight", you're saying "our internal company process will keep our software unusable by anyone using RTL or complex script for the forseeable future". Quite pathetic and I'll have to start over now finding good software to work with. Why on Earth are people on here having to justify what language we speak?! Is it 2020 or is this some alternative global hegemeny I've walked into?

If one has the ME version of ID, init, medi, fina are on by default...if I recall properly. But there are methods for turning these (and others) on by default in non-ME versions. A font designer has no control over what an application does nor how a given font is displayed/used. The init et al OT features should follow the spec in operation and on/off status in any application. The font designer is responsible for using OT features "properly." In the case of Latin fonts using, in particular, the init, medi & fina features, well, they/we shouldn't use them. Those features are technically for complex scripts, not Latin scripts. There are other methods for such contextual changes in Latin scripts--which can be a pita to write. I too am guilty of using those features in Latin connected script fonts because they are easy to implement. The use of those features in the "Default" language block in a purely Latin font is, to me, an error. Where I think application programmers go "wrong" in blindly turning on those features on (per the spec, though), is that if those features are turned on merely because the application is written to enable them when present regardless of the language blocks they are contained in then users are generally surprised. If a font has no Arabic (etc.) language declared but the font has one or more of those three features, I believe those features should not be on by default. But, like it is easier for a Latin font to use those features for such effects, it is perhaps easier for application programmers to not make judgements on their applicability.

It's been seven years since the initial release of their software. I think it's safe to assume they'll never support complex script or RTL text. Even if they do waaay into the future it might not be relevant anymore. Just stick to Adobe Creative Cloud, folks. It's getting better and more cost effective. Or use some of the wonderful open source stuff. The latest releases of Inkscape and Scibus are amazing.

Hi SaranMD, Unfortunately this isn't currently supported, but it is something we're aware of and with development. A lot of complex script fonts (such as Bengali, Hindi and Thai for example) use morx tables which are not currently supported so unfortunately will give you the issues you're seeing.

No worries! I ran into this issue the first time I used the first AD for Windows beta. I have several western fonts (usually script fonts) that use the inti (Initial word letters), and/or the medi (Medial, the letters that do not begin nor end a word), and/or one or more of the 3 different fina (letters ending a word) OT features. RTL languages such as Arabic and complex scripts (like the Thai I mentioned) have certain characters that absolutely must be used at the beginning, middle or end of any given word. Which is why these 3 OT features exist. They are not intended to be used for Western scripts...but many Western script font authors use them because they are dead simple to code. A little background. When those three OT features were first introduced, the language used in the specification was a bit ambiguous as to the "restriction," or intended, usage. And so many font authors of Western script fonts jumped on them because of their simplicity to use when coding a font. About 2-3 years ago, the specification for their use was reworded to make it clear. But we all still often use those features as the alternative, using the contextual alternative feature, is more time consuming to include in a font. And if one makes a mistake in what to include, or the "rules" governing their use, is not fully thought through, some characters may not swap out properly or at all. TMI I suppose. But I get on a roll... Take care, Mike

Your right about Arabic, but Hebrew is not a "complex script" at all.

Whenever we ask for RTL and complex script support they keep breaking our hearts with replies like: not planned for any time soon... At the moment and in the foreseeable future, the only serious alternative to inDesign is the lovely open source software Scribus. I'm so glad we have it. Affinity Publisher? Wonderful software but can't be taken seriously without RTL and complex script support.

>> You could also import all chapters as separate documents into the same layout, but is there a specific reason to keep them as independent documents? When I worked at a shop where customers supplied files in multiple formats, we didn't have the luxury of specifying precise file formatting or other preparation. We had to work with the material as-is. It's a perfectly understandable and sensible approach on the authors' parts to prepare books — and especially newsletter articles — as single files. I doubt many of them would have been happy with us if we'd said "We need you to go back and convert everything into a single large file." We wouldn't have been thrilled to have to concatenate all of the material into a single large file either. (I don't remember our ever having done that.) In my opinion the software shouldn't force users to work in a given way and only that way. The developers might find it reasonable, but it doesn't do much for users with varying needs. >> Also, a general note on (lack of) support for tags when importing text files: aren't tag based import filters basically a plain text based feature? They were when I was working with XPress Tags files. (I don't know how it works with InDesign.) At that shop we received a lot of plain text material that needed formatting. Because plain text can be heavily — and very rapidly — manipulated outside a page composition or word-processing program via scripting, it can be (not always "is," but "can be") a highly efficient approach. I'm talking about scores of files updated via script in a few seconds. Perl and other such tools are very quick. >> If so, they are not practical as there is plenty of stuff in Word format that is worth to be imported directly They might sound impractical. But, run a complex script routine on dozens of input files in seconds rather than minutes. It might well change one's opinion about what is and isn't practical. We could never predict how customer data would be supplied. If it arrived in some esoteric format that no program supported, we would have to strip it down to plain text and "massage" the text — say, by adding XPress Tags — for import into the page composition program. Those jobs became rather expensive for the customer due to the additional processing time. And a customer-supplied Word file, even if ideal in some respects, might contain any number of problems that all had to be corrected via search/replace or 100% manual formatting. Word alone isn't, of itself, necessarily a saving grace. >> Batch-based regex support with formatting criteria would allow much the same without requiring any scripting skills, and that would be kind of a minor revolutionary thing and I really hope this will happen at some point. It would certainly move the program along, yes. An entire automated formatting routine stored for immediate access and use would be excellent. >> It should be fairly easy to implement, compared to creating a scripting API with full access to document object model. I hope for users' sakes that the underlying architecture makes that feasible. Would it be easy to implement if there aren't any "hooks" for it in the present design? Possibly not. (I'm not doubting that AP has a suitable architecture; I don't know anything about what's underneath the bonnet.) Someone from AP, replying to mail I sent, noted "It's early days yet." I do get that. They're just getting started...

+1 for RTL and Complex Script Layout Support.

Don't hold your breath for true RTL support (text direction, complex script, document direction). It doesn't appear on any of their road maps.

Are you defending their lack of support for RTL and complex script there? LOL I wouldn't say it's a day's work for sure, but I find it hard to imagine that it's such a HUGE undertaking so much so that they are don't even have an ETA for it!

I fully agree. Without R-to-L and complex script support Affinity's lovely products will NEVER compete against Adobe and others.

Thai fonts is complex script there are a lot of vowels. Hope to see Thai language display correctly soon because I have to use Thai fonts for my work.

We aim to support GSUB and GPOS tables, but we don't currently support the morx table that a lot of complex script fonts use. If this is why your Tamil text isn't working, then I'm sorry but this is unlikely to be fixed for a long time. I can only suggest you try different fonts.