Search the Community

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.

Nobody from Serif has said they don't care. They are a relatively small company with only so many resources that has to make tough decisions on what to prioritize. They do not have the benefit of unlimited financial resources from bleeding locked-in customers for over 20 years. RTL support requires completely re-writing the text engine - a huge project. Supporting Arabic script requires writing a shaping engine - another huge project. Not going to happen any time soon. Indic is another complex script, but it is LTR, and less complex. So no re-writing the text engine needed, and an easier shaper project. My guess is that Indic will happen before RTL/Arabic. It is simply the reality of the situation. Support for either of these scripts is not going to happen any time soon. They have many other things to work on. Different users have different priorities. The lack of cross-reference support is really a problem for me. I do not care at all about RTL or Indic or whatever. They obviously do not care about me because they do not support variable fonts, and they do not support color fonts, and they still have not given me a way to turn-off fake small caps!!! 😁 They clearly do not care about font geeks. Appalling!

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

This is getting out of hand! All I said was that it is very unfortunate that V2 has no support for RTL and complex script. Why would that offend anyone? Why do I need a different thread? You don't like my posts then don't read them! Yikes!

I'd love to be positive about this, I'd really love to. But when you have been clamoring about RTL support since 2014 and you keep getting shunned it's hard not to feel marginalized. FWIW, after this release I renewed my Adobe CC subscription which expires in 5 weeks. I honestly was hoping I wouldn't need to, but it's getting less and less likely that they'll support RTL and complex script at all. There maybe some who wonder why all the disappointment but I hope they understand that lack of RTL and CS support is a deal breaker for others.

Thanks for the reply. Yes I understand that it is demanding from a technical point of view, but (sheesh!) Affinity Designer has been out for eight years now! If free stuff like Inkscape and Scribus can support RTL and complex script why can't Affinity?? Personally, I'd like to know whether it is in the pipeline or not at all. For the time being, good ol' Inkscape will have to soldier on for me...

All the usual bells and whistles and still NO RTL OR COMPLEX SCRIPT SUPPORT!!! Just unbelievable! To be honest, this is bordering on being disrespectful! We've been asking for it since 2014! Is it THAT much of a technical issue?! Or is it THAT low on the list of priorities?! Either way, I (as I'm sure many others) feel utterly deflated by this release...

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

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.

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.

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.

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..

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.

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

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

>> 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...

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.

+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.