Weird / destroyed pictures after export, looking like barcode

[PeterB.]

Hi,

I have a strange problem with exporting a document to pdf. Some of the images (logos) are placed as pdf/ai files on master pages. After exporting the document to PDF they look like a sort of weird barcodes. What I noticed is, that this problem only occurs when publisher says "Loading 2 images" in the title bar. This notification stays there forever until I doubleclick every page (including normal pages). The problem doesn't seem to happen when I place the logos directly on normal pages.

Is it only me having this strange problem?

Thanks

[Gabe]

Hi @PeterB.

Can you attach the document in question so we can have a look?

1 hour ago, PeterB. said:

that this problem only occurs when publisher says "Loading 2 images" in the title bar

Sounds like they might never load, so you only get corrupt data. 

[PeterB.]

Hie @Gabe

the layout contains customer data (logos, photos) which are copyright protected. So I can not upload it publicly. Is there a way to upload it only for internal serif use?

[Gabe]

Sure. You can use this link: https://www.dropbox.com/request/bcPMbC467oSNQ0JlQAjj

[PeterB.]

thanks! I uploaded a ZIP containing all files and a screenshot where I marked the affected two graphics (bottom left and bottom right in publisher).

[Gabe]

I've got no problems here. Can you try to manually break the link for those 2 resources? (moving them in a different folder and then re-link when you open the afpub file)

[PeterB.]

I tried what you suggested and that actually works! But I'm a bit worried this could happen again. Is there an option for creating a log file when exporting to pdf so I can find out if this is maybe caused by a wrong network volume path or something?

[Gabe]

Hard to say form my end what to look out for as I've not had the issue. You can enable PDF logging following these steps: 

If you still have the old (broken) file, try to export and attach the log on the same dropbox link.

[PeterB.]

Thank you! I will try this and send the log if it ever happens again.

[thomaso]

23 hours ago, PeterB. said:

The problem doesn't seem to happen when I place the logos directly on normal pages.

What do you mean with 'directly' and 'normal' here? How had you placed the images when the issue occurred?

Just in case: visually this look reminds me to a recently reported (logged) issue caused by copy-paste of text + images that were pinned.

 

[PeterB.]

1 hour ago, thomaso said:

The problem doesn't seem to happen when I place the logos directly on normal pages.

It seems that it only happens to the logos/graphics that are placed on master pages. The logo appears on every single page later so in order to save time, it's easier to place it once on a master page instead of doing it on every single page seperately. master page vs. normal page, I don't know how else I should call a normal page?

[thomaso]

Peter, thank you - and sorry, I was not aware before of the "master" you explicitly had mentioned. (I distinguish them as 'master pages' and 'document pages', though it's not unambiguous, too.)

[PeterB.]

@Gabe error occured again. same file, same problem... I just uploaded the Log File, .afpub and exported pdf. Can you please have a look? Tried to find an error in the log but it's too hard to understand for me...

[Gabe]

I reckon it might be your network drive. Can you see if it's fine with resources stored locally and not on your network?

[PeterB.]

2 hours ago, Gabe said:

might be your network drive

that's what I thought first, too. I did da deep check over night to ensure the raid and disks are all healthy. No problems or errors there. And I think if it would be caused by my network drive, this error should appear in more than just one single publisher file, right? The client is one of my bigger ones so I'm using the same logo file dozens of times a day in different apps (indesign, publisher ...) and layouts. No problem so far.

And i'ts only happening if the logo is placed on a master page. If i cut and paste it on a normal page the problem is gone. I uploaded a Screenvideo.

[PeterB.]

I tried another thing: clicked on the master page layer on my normal page and chose detached. moved the logo to the normal page an exported another pdf. voilà the logo is no longer broken but the graphic on left, which i didn't move, still is.

[PeterB.]

And if I just use the replace function on the master page and replace the logo with the exact same file, the logo is exported correctly. the graphic on the left still not... I don't know but that doesn't sound like a network or drive problem to me... 

[thomaso]

33 minutes ago, PeterB. said:

this error should appear in more than just one single publisher file, right?

14 minutes ago, PeterB. said:

replace the logo with the exact same file, the logo is exported correctly.

In this case the object on the master page might be 'simply' corrupted somehow. – So, what if you don't replace but delete the entire object and reload it from scratch to the master again? Does it export with issue then?

By the way, concerning replace: Though the following is not directly related to your issue the replace method may cause other issues, too, than this: There seems to be a difference in a replace result, depending on the way an image gets replaced: either via Toolbar button or via Resource Manager:
https://forum.affinity.serif.com/index.php?/topic/119795-replacing-images-in-a-frame-changes-scale/

[PeterB.]

18 minutes ago, thomaso said:

In this case the object on the master page might be 'simply' corrupted somehow. – So, what if you don't replace but delete the entire object and reload it from scratch to the master again? Does it export with issue then?

seems to work. Let's see if this is a permanent fix. But I think elements should not geht corrupt in a layout software, so in my personal opinion that should be analysed.

[thomaso]

> But I think elements should not get corrupt in a layout software, so in my personal opinion that should be analysed.

I agree. Theoretically.

In practice, even with the 'veteran' InDesign, I experienced about once a year a document as damaged (didn't open any more). Oddly enough, having colleagues open the affected file on their Macs often seemed a successful solution, even though we all had the same hard- and software.  Also occasionally an image within PDF export appeared weird, after a certain learning curve it was just easier & faster simply to delete and recreate the object than to start investigation to solve the issue.

Concerning your file: Gabe had, earlier in this thread, obviously started to analyse your document and did report his current result, didn't he?

I am quite confident Affinity developers definitely do analyse documents daily – otherwise they would not be able to find solutions for the issues and bugs, detected and reported by the forums community. But a single corrupted object may appear as quite a small issue, if you consider as long it is not reproducible but happens, for what reason ever, in a certain document to a certain object only, the profit of detecting the culprit may not be worth the effort. To analyse such a single situation can be extremely demanding since there are heeps of possible influencing processes on a computer's background, system files included, which, actually, are the result of many 'simply' humans mind work.

[ Compare: You suddenly can't find your key but feel to be sure to have placed it there. Then, rather by chance, you discover it at an unexpected place and even remember now when you had placed it there. – Would it make sense to analyse how this single situation was able to happen? Would it prevent it from happening again? ]

[PeterB.]

@thomaso I have no doubt that the affinity team is working hard as hell  I never meant this as criticism.

[PeterB.]

@Gabe sorry but I have to ask another question regarding this problem: Does it in any way matter how the Volumes (on Mac) are connected an what protocoll I'm using? I suspect that this special problem seems to occur more often if I place the graphics via an alias to the logos folder on my network drive.

And it seems to also happen only with publisher files that I created with older versions of publisher.

[Gabe]

We've always recommended to work on local drives and not network drives. We've not been able to reproduce the issue just yet. 

19 minutes ago, PeterB. said:

I suspect that this special problem seems to occur more often if I place the graphics via an alias

What is your exact workflow? Do you always use aliases? You've still not answered my question. 

On 7/9/2020 at 12:41 PM, Gabe said:

Can you see if it's fine with resources stored locally and not on your network?

 

 

[PeterB.]

11 minutes ago, Gabe said:

What is your exact workflow?

I create aliases on my desktop to often used folders on my (SMB connected) network drive (like clients, logos, photos or special graphics). I then pull these aliases to the sidebar of my finder window so I can reach them with only one click instead of having to go through the network path all the time.

Normally I create a new layout file and then place the logos, graphics and so on via a click on the alias in the finder sidebar. This usually works fine. But for some (repeating) projects I use existing layout files that I created earlier. For example a poster with the same basic layout: open the existing file, saving it under new name, changing headlines, graphics, logos - finished. And I think this error only occurs with this existing files but I can not clearly proof that. Is there a way to see in what version of publisher a file was created?

22 minutes ago, Gabe said:

You've still not answered my question. 

sorry overlooked that. It's fine then. But it seems to be also fine if I just do a replace of the same files or sometimes restart publisher (as far as I've investigated). 

 

26 minutes ago, Gabe said:

We've always recommended to work on local drives

I'm sorry but this is not a good idea for me and of course my team... We need to use shared drives as we are working on projects together. For example if a logo on a network drive has changed, the ressource manager tells that. So no matter who is editing a document, it's ensured that the used files are up to date. And also the latest publisher layout file is easy accessible for every team member.

[fde101]

On 7/17/2020 at 6:09 AM, PeterB. said:

We need to use shared drives as we are working on projects together.

Native Affinity documents have been known to become corrupted while working on them if they are stored using one of the "sync" services such as Dropbox or iCloud and you try to open them from there, but I would not expect that particular issue with a more traditional network drive mounted via a protocol such as CIFS (SMB) or AFS.

However, given the potential for multiple users to be accessing a file at the same time, it would be necessary for an application to implement appropriate file locking to make this safe depending on how those files are used.  I have long suspected based on the behavior and previous reports related to the Affinity document format that the file may be actively modified while the application is open.  If there are not appropriate locks in place and you attempt to share those documents in realtime, they could possibly still become corrupted.

As the recommendation from Serif continues to be working on a local drive, I would not place confidence in that locking.

Furthermore, the way that file locks work can vary between platforms, and as Windows-style file locking (CIFS/SMB) can be quite different in its semantics than native Mac-style file locking, even if the appropriate locks are in place for native use on the desktop, there is a possibility they may not translate accurately over the network share - this has been a problem in the past even when interconnecting different UNIX systems - so I would not be surprised if the issues were directly related to the manner in which you are attempting to share these resources.

Placing standard image files (TIFF/PNG/JPEG) and the like on the network drive should not be an issue, but I would be very careful if attempting to do this with native Affinity document formats until such time as Serif can harden its use of the file semantics to ensure that it is safe to work this way.

 

If you really feel it is necessary to continue working in this manner, and you are all on Macs, consider trying this over a native AFS share rather than a CIFS (SMB) share, as that should provide native Mac file locking semantics.  It might be instructive as to whether or not you can reproduce the issue under that environment...  but even then I would advise caution.