LondonSquirrel

A strange analogy. I have never heard of Microsoft or Apple being sued because they both provide web browsers which could/have been used to download pirated software.

According to dxomark, the top 3 smartphone cameras are not Apple: https://www.dxomark.com/smartphones/. Sure, I know you are referring to software rather than hardware, but there are many examples in Apple software which are utterly junk in comparison to Android/Windows. On macOS, the hilarious bad joke of Photos comes to mind. And there are numerous complaints about Safari (both on ios and macOS) becoming the 'new Internet Explorer' for not updating with new features.

I managed DNS for years, and having a serial number in the form YYYYMMDD01, YYYYMMDD02, etc, is what I'm used to. Whatever floats your boat... I think this should be built into Affinity, with a choice of numbering/naming schemes.

I prefer putting the date in the filename, because if I copy that file to somewhere else (at least on macOS) the timestamp shows the time of the copy. e.g. (47) % ll background-banners.afdesign -rw-r--r--@ 1 75K 28 Jun 2021 background-banners.afdesign (48) % cp background-banners.afdesign ~/Desktop/ (49) % ls -l ~/Desktop/background-banners.afdesign -rw-r--r--@ 1 xxx staff 76868 27 Feb 09:23 /Users/xxx/Desktop/background-banners.afdesign I can do 'cp -p', of course. Or using Finder it seems to preserve the time stamps. But it's just my preference to have date/time in the filename.

A solution? Maybe not a 100% definite way. But you can take steps to at least minimise the effects of it. 1. Do frequent 'Save as' to a new file name, e.g. Somedoc-20220226-01.afdesign, Somedoc-20220226-02.afdesign, etc. Effectively you are doing your own versioning. 2. Save to a local disk in a directory which is not under the control of a cloud service. You can always move your files there afterwards if you want them backed up. 3. Once in a while, open one of your saved files and check that it can still be read. There are quite a few hints through this thread and others about trying to mitigate corruption to files. These three should help you get started. I have no idea how widespread the issue of corrupted files is. The cases we see mentioned here are probably not the only ones. But out of millions of files it's probably a very small fraction of a percentage. Nonetheless I would not want to lose a file I have been working on due to corruption. If your files are important then consider treating them accordingly.

Correct, because as @Komatös above wrote, there is no RTL in Affinity's apps. You can export the text from LibreOffice as EPS, and place that. It's OK for short bits of text, but it's nowhere near ideal or usable for longer text that you want to integrate in a document. In fact it is quite a long and annoying process - hence only suitable for a simple and short piece of text. I've attached two samples. In the first you will see the text is broken (even if you don't read Persian you will recognise the letter forms are not correct). The second file has the broken parts removed and is quite a reasonable rendition. In my experience if you are looking for a 'full' DTP solution for use with Arabic/Persian/Urdu/Hebrew/etc, Affinity is not the solution for you. If you only want a short piece of text or some 'graphical text', it is doable via an export from LibreOffice (with some cleaning up afterwards). be name khodavand.epsbe name khodavand 2.eps

For simple text, the sort that you see in newspapers and books, I use LibreOffice. Version 7 has a much improved RTL engine.

According to the Pixelmator web site Walt is correct. https://www.pixelmator.com/blog/2021/08/19/pixelmator-pro-2-1-3-brings-huge-improvements-to-psd-support/. For those who don't want to follow the link, they basically spent about a year working on a newer version of their PSD code. One snippet which stands out to me is this: 'we dived really deep into the PSD format itself and have a much better understanding of it, with some fantastic internal documentation' (my emphasis). In other words they had to do some reverse engineering of the PSD file format, and the Adobe documentation does not cover everything (as Walt wrote).

What about "good" ears? Friends, Romans, countrymen, lend me your ears. Anyway, I think this thread has gotten further away from its original purpose. There is no Serif Pascal. In William's shoes I would use FreePascal.

That wasn't really my question. I have heard of multiple master fonts, but never used them. I'm asking what happens today if you export a PDF from an app which supports variable fonts? How do the fonts appear in the PDF? Because PDF does not actually support variable fonts (according to Adobe). So all this talk of one font for all uses seems very moot if you cannot actually use all those custom weights/slants/etc in PDF.

Your best options are Delphi or FreePascal. One is commercial (but I seem to recall a free version for certain uses), the other is free. Why not just use those? They are already available, well supported, with large communities around them, loads of documentation, etc.

I know it's confusing, it was meant to be! So if I wrote in Persian "only 100!", it would be "!فقت ۱۰۰". I think I may have just introduced a problem for William's parser.

How would your system handle RTL languages, let's say Persian: ۳۴۵! or is that !345? These days for text handling I would tend to use Go if possible when doing Unicode text handling. Why not? I've done some with it, some of it is ongoing, and it works as expected (with some care). I mentioned earlier about FreePascal + Lazarus. I don't see what would be so much better about a Serif version of Pascal. To me it's two different skill sets. Writing programming language compilers is a completely different skill set to writing graphics software. I've met some very good programmers over the years, as long as they stay within their specialist fields. Is there even such as thing as 'general programming'? Maybe, but not really. It just means working in a specialist field which happens to be very large. You could take 1000 C# programmers, and ask them to do some FreeBSD kernel programming. I can already see their puzzled faces.

I don't see how 'Serif Pascal' would be more useful than FreePascal and Lazarus. They both have large communities of users and supporters.

No. Your argument is a fallacy. I have never said there are no Linux users. I have said that I have never seen a Linux user in a coffee shop. As I go to a coffee shop > 3 times a week I would expect by now to see at least 1.

It means what I have seen. I have never seen a single Linux user in a coffee shop. Go to 10 coffee shops and see what people are using for their laptop OS. I would expect to see 1 or 2 Linux users if the statistics that Linux people quote are correct.

Others have tried and wasted their money. They were led astray by big words and grandiose claims that Linux is going to be a big thing and now is the time to get into it. WordPerfect, Corel, Borland, etc. They spent the money to develop for Linux and it was money down the drain.

Evidence of the old glazzies. Go to any coffee shop and see for yourself what people are using. I have never seen anyone using Linux in a coffee shop. I have seen innumerable Macs and Windows users. Never once, not even one, Linux user. Linux people have forever pretended that their desktop market share is bigger than it actually is.

Try copying the file out of your Google Drive directory into your Desktop or Documents directory, and try opening the files from there. Files in a Google Drive managed directory may not be available locally at the exact moment you need them.

You raise an important point, but with PSD specifically you are also wrong. From the Adobe PSD specification: 'This document is provided for 3rd parties to read and write the Photoshop native file format.' Adobe intends that third parties use PSD. Compare the above with the language used in the idml specification: 'IDML is intended for consumption by InDesign-family applications, including InDesign, InCopy, and InDesign Server. IDML is not intended as an interchange format for use with applications outside the InDesign family of products, and does not attempt to write or structure InDesign content in a manner that is compatible with other XML layout formats...' There is a clear distinction here.

Unless you have access to the parser you won't know what it will do with the Affinity-specific stuff. And see my point about future developments to idml. Adobe no doubt has a development plan for future versions of InDesign and idml. The fact remains that idml is designed and intended for use within InDesign and not for exchange outside InDesign.

I agree up to a point, Walt. But unless you have access to their parser and see how it handles the Affinity-specific attributes/elements/whatever, you won't know for sure what will happen. Let's say you have an Affinity-specific attribute called 'af-1', what happens if Adobe have already reserved that for a future specification of idml? Much of the programming I have done is in the internet arena, and trying to adhere to RFCs. Occasionally these RFCs themselves are ambiguous (I'm looking at you, IMAP), even though they are not supposed to be. So Bob client opens a connection with a bunch of attributes, and the server end expects something just a bit different. Should the server terminate the connection or try to handle what has been sent as far as it can? I've been in this game for > 20 years, and I've heard a lot of the arguments about how programming (and data exchange) should be done. 20 years ago it was popular to say 'be conservative in what you do and be liberal in what you accept from others' when it came to programming (particularly with internet stuff). Well that just opened a whole big can of worms, and led to huge numbers of exploits of CGI scripts (remember them?) all over the place. Untainting the input is only part of the story. So from my POV, unless I had access to the Adobe parser (so I could run any number of tests very easily), I would not want to use idml as an interchange format unless it was intended for that purpose. If an app is using idml to interact with InDesign, it should be written in bold letters 'this is not what it is intended to be used for'. I see Old Bruce has just posted about the loss of character and paragraph styles. I could easily see how content would be messed up.

To idml they won't be exported at all as there is no idml export.

This is an Affinity forum. I'm not particularly interested (in this forum) in another apps' interoperability with InDesign. Exactly.

Again, that is not what I asked. I will repeat it here with a key part made bold: What happens when the non-Adobe app encounters an Adobe-only feature? How does your app handle that? There is not 1 to 1 compatibility between features in APub and InDesign. Nobody is interested in apps the parts of which work splendidly, we are interested in what happens (and how much work is involved) when it doesn't work. If you have to spend an hour per document fixing up things, and you are doing a document a day, I would say forget about exchanging files and just buy an Adobe subscription. The cost would be worth it. If you are doing one document a year then it's a different matter.