betzalel@project314.org

I have the original file. It doesn't seem to want to recognize it. So I added a windows username to try to match the path (which was actually a dropbox location), but it didn't seem to autofind or autolink the file.

Is it possible to transfer and recover an autosave file from one machine to another, provided I'm running the same Affinity Publisher version? I had a Win 10 machine running Affinity Publisher Version 1 (updated to December 2022 revision) with a hardware failure. I was able to recover the hard drive just fine and accessed the autosave from the C:\Users\XXXXX\AppData\Roaming\Affinity\[Application]\1.0 folder. On a new Win 10 machine, I installed the latest Publisher Version 1, and I replaced the entire 1.0 folder with that of the crashed machine. But when I started up the Publisher application, the autosave didn't come up. When I tried to open it directly (looking for *.* instead of the normal Affinity extension), it gave me an error, saying that "the file is a linked file but the parent file could not be found". See the error dialogue box below... In hopes of overcoming this problem, I went so far as to make a directory in the USERS file that was the same as my old installation, presuming it was a path-based username error. Is there a way that I can resolve this error and overcome it? I have the old file that was revised, and that opens fine (without the autosave revisions), as well as the HUGE autosave file (about 1.5GB), but I don't know how or if I can marry them together.

I'm using Windows 10 and Publisher 1.7.0.305, and I had problems with outputting a PDF that was balanced in color. My document had three elements; 1) a parchment type background, 2) a smaller white semi-transparent overlay, and 3) text and images on top of these things. Originally, I tried to apply a light shadow feature beneath the white overlay with the "outer shadow" function, and found that in many cases the shadow blended or collided in very strange ways with the parchment layer beneath when I generated a PDF file (using the "print" function). I was able to get the shadowing and transparency to work out after trying different blend modes and color formats and profiles, but after doing so, I was getting strange blending effects and tinting between the my monitor (based on the default WYSIWYG / editor palette color settings) and the actual PDF file that the print driver would output. It seems that no color formats or profiles could yield satisfactory results until I used the EXPORT function instead of the PRINT function. I don't know if this is how the program is supposed to work, but this is contrary to every other program that I have used, which tend to give either a perfect match or a very close match between the screen and the PDF print driver output. It may be how this is supposed to work (for sophisticated print functions), but I will say that using the export function is not intuitive for me, and where I've used programs which do exports, there is a match between the files regardless of the use of the PRINT or EXPORT function. Apart from colors, I had a number of problems with margin/bleed/crop/page size settings. These functions worked fine in the Affinity Publisher program, but it would be nice if these functions were integrated into the same tab or dialogue box or window, along with a little (visual) guideline as to briefly explain how these are typically used. I was using KDP and was getting a lot of errors on the file even though all of my content was within print areas as defined for a 8.5x11" book because I didn't fully understand what KDP expected, and I think if these are soft settings embedded in the PDF file that the KDP is using these parameters in the background to determine if the file is suitable or not. Theoretically, there should be a number of ways that one could express these parameters and get an acceptable output, unless, of course, the printer has expectations as to how the file particulars (i.e., margin/bleed/crop/page size) are configured. Like I said, I wouldn't consider this to be a bug, but I think there's room for improvement and consolidation to make this bleed/crop process more logical.

After just a couple of weeks of using affinity-publisher-beta-1.7.0.283, I've come to like it (hoping that it will overtake AdobeID some day), even though it has crashed a few times. It seems that the autosave has worked well in general, but today after I tried to restart it after it crashed I was forced into an update 1.7.0.305, which didn't want to install correctly (it seemed to take but only after uninstalling the old version and rebooting my system), and it didn't seem to give me any indication that it was recovering from a crash (or that it had saved my file). Fortunately, I learned that it saved an autorecover file like other Affinity software, with an .autosave file extension, which I found in C:\Users\User\AppData\Roaming\Affinity\Publisher\1.0 (Beta)\x_randomnumber_x.autosave. I was surprised to see the autorecover file was sized at 3+GB, especially as earlier files were only 80-700MB, which seem large seeing that the document is based upon only 4 or 5 images (well under 20MB total) and some simple tables. Nevertheless, I was able to open the file perfectly, otherwise I would have lost an afternoon's worth of work. After getting the file recovery issue squared away, I was surprised to find that the newer version was far more unstable, plus it had some sort of menu glitch (see photo below) which wouldn't go away, even when I minimized the Publisher window. It seemed to remain active after minimizing the main Affiniity window. After I restarted Publisher, it seems the glitch went away, at least for now. Also, for the record, I really don't mind being a lab rat in software testing if it's a product and a company that I believe in, and feel happy to give useful feedback in exchange for software trial. However, I don't like this mandatory-update-hold-a-gun-to-your-head-and-never-let-you-go-back-to-the-old-platform policy. It stinks like the gestapo-esque Windows auto update policy, and it's something cruel that a company like Adobe would do. I was forced into an older version of Adobe CC a few months back and it cost me a half day of rework just because their rev control policy isn't squared away (I created the file in a newer version [version control was not an option at the normal consumer level] with formatting features that were not fully backwards compatible). I'm saying all this because I cannot afford to invest time into developing content on an experimental platform/product only to be left stranded because someone from afar decides to terminate the platform's utility in a blink of an eye with barely any notice. Yeah, I'm sure that you have such a point and policy covered in your EULA that I agreed to, but some things are just a simple matter of professional courtesy. It's just bad business to cripple or blind somebody and then feel justified in so doing simply because of the legaleze and fine print. If you take away user control over what version they want or choose to run, I think you're violating the "public trust" and you leave me feeling powerless and betrayed, and with a loss of confidence in your platforms and policies. Please consider that this is no way to begin a courtship.