Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Daniel Gibert

Members
  • Posts

    279
  • Joined

  • Last visited

Everything posted by Daniel Gibert

  1. Publisher just updated and now it works! Well well well! @MikeTO please send my greatest kudos to the team. Just updated Publisher to 2.0.4 and the issue is solved. The linked images from dropbox now have a standard url and any change is inmediatly updated in Publisher. People, update it asap and enjoy your Dropbox workflow! Just be sure to have dropbox link deactivated in settings. I've become a happier droid today.
  2. Thanks for the info, MikeTo. You don't know how much I want to have this issue resolved to start using v2's books function. Just finished a multi file catalog with 2000+ images and had to export and join pdf in Acrobat multiple times (hugh!) using v1 and in a month we expect to start the next big one, with over 5000 linked files in 13 publisher documents all in dropbox… Would love to do it in v2. Books and single book pdf export was my day one wish and having it and not being able to use it because of the dropbox linkage errors is consuming me. (Sad small violin solo)
  3. Hi Andy_R I've been direct messaging with the Affinity team about this. It seems that the route of files linked from Dropbox is a Dropbox special link instead of the route to the physical file in your drive. It was supposed to be this way if you activate the Dropbox connection in Publisher settings, and a normal route if don't, but for some reasons, it is using the Dropbox route regardless if you activate the route or not. This happens (at least in my case) when you have dropbox in an external drive. They are looking to force the route to be a regular one always when Dropbox connection is deactivated and, probably, so I hope, the next update will bring a solution to this issue. You could look at this in resource manager. Any linked file you use from dropbox has a (Dropbox:path_to_file) route and when the file is outside dropbox, the route is a traditional one: (volume/path_to_file). What they are looking at now is to ensure to only use the Dropbox route when Dropbox connection is active, and only normal when non-active, no matter if the file is in dropbox or not. Let's have hope.
  4. This is an v1 old error that has reborn in the v2. CMYK colors on the FX panel are show as pure RGB. So picking a color is more hard as you can't see the real hue. A little disappointed that this error has returned. It was solved on v1. And it reappears often, as versions are released.
  5. In fact now I use an easiest quick 4 step solution, that always work: Select nothing on the page (Click outside anything) On the Text styles be sure to have [No Style] selected as Paragraph and Character Style On the menu, go to Edit > Defaults > Factory Reset Then you can update your TOC without problem. (And breath on relief) This has been working correctly for me. The defaults you are resetting are basically the info of what the last used style/text is, that seems to be applied to the TOC when you updated it. This 4 steps makes sure that there is no last used styles in memory before updating the TOC, so it will use the TOC styles without adding changes. Not only is easy to solve and save a lot of work (Just do the 4 steps before updating TOC). Also it shows what the nature the bug is. Basically, last used paragraph format is being “added” to the TOC formatting when you update it, mixing it with the TOC styles. It is for this that the bug is not consistent and results are so random.
  6. I would not mind (much) if it only failed to update linked images, but the "old feature error" is such an absurd bug that it is impossible to accept it. On the last beta at least it just delete the linked image, instead of corrupting the document. Just this prevents me to use publisher for production work until it is fixed. Still using v1 against my will.
  7. Well. First Beta of Publisher. The issue persist, but now the behavior has changed. Now, if you save-close without altering the non updated linked file, it updates correctly at reopening the document. If you save-close after moving or altering the non updated linked file, the document get corrupted no more, but the linked file is just deleted. An advance, because you don't lose the Publisher document anymore, but still linked files don't update and Resource Manager still don't detect file changes. And therefore, Publisher still not usable for us. (Imagine reopening the document to find a lot of images missing… yes, better than a corrupted file but…) It is now super-clear that it is something on the App coding (That does not happens on v1) because nothing more has changed but the Beta on our systems. I posted this on the Beta forum too. Looking for future improvements on next beta releases (pleaseeeee)
  8. The issue with linked files from Dropbox external disk persist, although it evolved a bit. Now, if you save-close without altering the non updated linked file, it updates correctly at reopening the document. If you save-close after moving or altering the non updated linked file, the document get corrupted no more, but the linked file is just deleted. An advance, because you don't lose the Publisher document anymore, but still linked files don't update and Resource Manager still don't detect file changes. And therefore, Publisher still not usable for us. (Imagine reopening the document to find a lot of images missing… yes, better than a corrupted file but…) I refer to this issue:
  9. As far as I know, the artboard tool is available on Affinity Designer, not on Affinity Photo. Although you can move and manage existing artboards on Photo if you open a Designer document on it. But the creation tool is only available on Designer IIRC.
  10. linkin-crash.mp4 At your command. I have made the same test in all four macs with the same result. It is always saving the files to Dropbox in external drive. Hope you can find it useful.
  11. Yes of course: Mac Mini m1 - 16gb RAM - Ventura 13.0.1 - external (Direct connection) APFS - Samsung T5 1tb USB-C SSD Macbook Air m1 - 8gb RAM - Ventura 13.0.1 - external (Direct connection) APFS - Samsung T7 1tb USB-C SSD (Also tested on a Philips 16gb USB-2 pendrive) iMac late 2013 - 24 gb RAM - Catalina 10.15.7 - external (Direct connection) APFS - Samsung T7 1tb USB-3 SSD iMac late 2017 - 24 gb RAM - Monterey 12.6 - external (Direct connection) MacOS HFS+ with registry - San Disk Extreme 500gb USC-3 As you can see, we can reproduce the issue in four computers, with up to four different external disk, with 2 type of cable and 2 different formats. In all of them, the issue happens when linking from External drive Dropbox. The corruption happens usually on the second save of the file (Sometimes in the first save) So it is not an isolated issue. Affinity versión is v2 in all devices. System and Affinity suites working from internal disk. Also, remember that this happens only within Dropbox folders. If we test on the same drives outside of dropbox, it works fine. And Affinity v1 has no issues at all. Let us know if you need more info, or a screen videocapture or a remote session. We are very open to help, as we need Publisher new features a lot. And thanks for your attention.
  12. I'm pretty sure that the issue is about Dropbox being in external drive. For some reason, Publisher gets no notification of the changes on linked files. The most outrageous thing is that it works perfectly on v1, so i doubt it is Dropbox the issue. My mission is to be that kind of user :-P
  13. More advances in the possible resolution of the issue After much more experimenting, the culprit has been cornered! IT IS THE (insert swear word here) DROPBOX It is Dropbox that it is causing the issues with the files. Saving and linking files from a Dropbox folder in an external disk causes all the issues. Linking from the same drive outside a dropbox folder works perfectly. It occurs that in all my computers, we save the work to Dropbox in an external drive. This is why the issue is happening. It is an incompatibility with Dropbox. One that does not happen on v1, but it is present on v2. I know that Dropbox integration has been added to v2 (And I have it active) so there is obviously something wrong with it. So i'll rewrite the steps to reproduce it: Make a publisher document and save it to Dropbox in an external drive. Crete a designer figure and export to PDF on Dropbox on a external drive. Place the PDF on the Publisher document and save Modify the figure in Designer and export again, replacing the initial PDF In publisher, PDF does not update, and does not show update option in resource manager (Publisher totally ignores the PDF had been modified) Move the placed PDF around the publisher document, or make any other change, and save (So it is saved without updating the pdf preview) Reopen the publisher document: You get an error that it is saved with a more recent version of Publisher (Which does not make any sense at all). File has been ruined and can't be recovered. Repeat the process in the same external drive but outside of Dropbox and it works fine. At this time I don't have any device with Dropbox over internal disk to check. All my setups are over external drive. Can anyone check it?
  14. More info to refine the issue: PDF - Don't detect change - Don't update preview - Don't allow update in resource manager EPS - Don't detect change - Don't update preview - Don't allow update in resource manager AFDESIGN - Don't detect change - Don't update preview - Don't allow update in resource manager JPG - Detect change - Don't update preview - Don't allow update in resource manager GIF - Detect change - Don't update preview - Don't allow update in resource manager PNG - Detect change - Don't update preview - Don't allow update in resource manager TIFF - Detect change - Don't update preview - Don't allow update in resource manager In resume. If the linked file is vector based, the modification is not noticed at all. If the file is raster based, Publisher know and says that the file has been modified, but does not update the preview and does not let you manually update. Issue is now much more frustrating, because is not only PDF linked images that are not working from/on external drives, which we could somhow avoid. Now is that we cannot link anything without risk of loosing the work (And we are not gonna change whole studio workflow, sync system and backup system because of it, of course)
  15. Well. Hello there. I have been able to reproduce the issue with great detail and specific steps so developers can too. Make a publisher document and save it to external drive. Crete a designer figure and export to PDF on the external drive Place the PDF on the Publisher document and save Modify the figure in Designer and export again, replacing the initial PDF In publisher, PDF does not update, and does not show update option in resource manager (Publisher totally ignores the PDF had been modified) Move the placed PDF around the publisher document, or make any other change, and save (So it is saved without updating the pdf preview) Reopen the publisher document: You get error that it is saved with a more recent version of Publisher (Which does not make any sense at all). File has been ruined and not able to recover. If you repeat this steps on local drive, there is no problem at all. The fail is generated when you move the linked image and save with it not updated. Issue verified in: Mac Mini m1 - 16gb - Ventura 13.0.1 - external USB C SSD (Direct connection) APFS Macbook Air m1 - 8gb - Ventura 13.0.1 - external USB C SSD (Direct connection) APFS iMac late 2013 - 24 gb - Catalina 10.15.7 - external USB 3 SSD (Direct connection) APFS So this issue is not related to Ventura incompatibility but to drive compatibility. In all three cases the steps has been reproduced with identical results.
  16. Are you working on internal disk or over an external disk?. I have had issues with linked images over external not updating, and checked that using the internal disk the issue disappears. It seems a known issue just now.
  17. Hi. I have encountered the cause. Publisher is having problems with files linked/saved on/from external storage. It works perfect on internal disk, but fails to update/reload/save with files in an external ssd The external is APFS formatted, connected through USB C. Unlucky for us, this not solve our issue, because we work all from external disk (And v1 had no issues at all with it) and we are not able to store the work internally. But at least we know why it happens. I have read in the forums that Publisher has a logged issue in Ventura with FAT formatted units. I think that the issue could be updated to include APFS too.. Hope this is info of good use to solve it, and that there is a solution soon. Working with v1 until then (Cry in silence)
  18. Yep. The setting is active (And even tried to deactivate/restart/reactivate it/restart again, No result. We didn't used v1 settings, preferred to set new ones by hand. Gonna try to deactivate 3rd party apps and extensions to see if there is an issue with other software interfering. I'll let you know as I study it.
  19. Hi. Publisher is not updating the external PDFs or Designer. files after being modified. The settings are correctly set to do so. Also, it does not show the "Update" option on the Resource manager. The external files are set to "Linked" The worst thing, is that if you save the publisher document without updating the image, you cannot reopen it again, receiving a message that the file contains characteristics from a former version of Publisher ??????? Procedure: Create a figure in Designer 2 and export as PDF (X1A) Import the figure to Publisher (Linked) Modify the figure on Designer and export again replacing. The figure never gets updated on Publisher, nor the option to manually update appears. Save the document without updating the linked image. It fails at reopening it. I tried with PNG and JPG and it detects the changes perfectly. Tried in a second Mac, and it fails to update too (Although it says that the image has changed, just not updating the preview) and crash trying to reload the image. Seriously something is wrong with placed vector files or the preview interpreter. Publisher becomes totally unusable to me, as I can't risk to damage any of the works I have in progress, all of them using imported PDFs and linked Designer files. Literally, I can't work with Publisher 2 just now. It is an incredible risk, which could cost me thousands on damaged and undelivered works. I'll remain in v1 at this moment. Added info: Tested with 2 computers, one with files in external SSD and other with internal drive, both fails. Both with Ventura 13.0.1 Attached you have an example of a document corrupted. broken file.afpub
  20. Ok. After some trying, I got Designer working good after disabling the Mega client and the Lulu network filter. And it continues to work after opening them again, so it is for sure some background process conflicting with Designer. Not sure what of the two was the culprit. I hope this could be of help to any of you.
  21. Well, on the Macbook Air works well, not on the Mac Mini. As they share the same M1 processor, it seems that the issue is of compatibility nature, probably conflicting with something installed in the mini. (The Air is a barebones computer for testing with minimal ad-ons) I'll try to refine the issue by deactivating apps and system extensions so the issue could be best targeted.
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.