You can always ask for a refund.
1 Like
FWIW, I did extensive testing and I did encounter this issue and even considered a possible solution, but there wasnât enough time to implement it so I took a calculated decision that the benefits of the new approach greatly outweighs the negatives. The fact the old code worked for this particular font is accidental, and the new code correctly handles much more fonts. Also the breakage is recoverable since it has no effect on the proper rendering of the text (no gaps) and it doesnât affect line breaking either (so no document reflow). The new code is more cautious and prefers no Kashida to insering Kadhida at bad positions, while the old code would happily insert Kashida where it shouldnât (as evidenced by the multitudes of bugs that have been fixed).
Only a days? It doesnât seem so terrible 
/joke, and I hope not the offensive joke for you . For example I make one project nearly 7 years and I repaired more times some changes that took me a days/.
I understand it is very unpleasant for you - to downgrade to older version or repair the hundreds of documents.
But is it possible to automate the fix of hundreds documents? I think yes.
ODT files are only renamed ZIP, and if you rename ODT to ZIP and unpack, there are the XML files. And it is possible to replace the string XB Kayhan to OtherFont. It is not problem to rename the ODT files to ZIP, and I saw some webs there was the procedure how to Find&Replace in ZIP files. But it was under Linux. Maybe you will able to find some program under Windows or Mac or what you use.
Or it is possible to write the macro that will unpack the ODT files in some directory, or pack the directories to the ODT files. And use some program for batch Find&Replace to change the strings.
Or write a macro that will generate the Shell commands for some ZIP program to unzip/zip the files.
So if you have some font instead XB Kayhan, I think it could not be problem for many days. I donât write it could be easy, but it could not be impossible or so hard .
But of course, these âhandâ editation could be danger 
, but I donât see the problem if only the name of font is replaced. I did this operation for some Templates before few days, and succesfully.
But if you have some complicated formatting and it need also to change some Enters or positions for new font, probably it is not possible to automate it .
Given the text on the fontlibrary.org page, is it possible that the font has both technologies built-in, and so the library possibly could use the other when thereâs no data in the first?
a bit error-proneâŚisnât it ?
The better way seems to adapt the styles of one writer-doc, and in any target.odt if you need:
âStylesâLoad StylesââFrom File....
and of course the whole job for 100+ files can be done by few lines of code!
As you have discovered a serious bug, it is wise to keep this topic, at least as a reminder or an incentive whip for developers. Also, many visitors have already seen and read your question. Being able to search for it has a high value for people needing Arabic writing, at least to be cautious with LO 7.5 and keep an eye on future releases.
Please, restore your question.
PS: I donât know if deleting your account also deletes your posts. Anyway, no user here, even with high privileges, can delete your account. You should ask site maintainers through the Feedback category.
HarfBuzz does not currently offer a way to control whether AAT or OpenType will be used if the font has both, it will choose one or another based on some heuristics that try to replicate what CoreText does with such fonts.
That is all moot anyway, the OP got so upset and deleted everything they wrote crippling the discussion. Until more people complain about this, it is a low priority issue AFAIC.