518 - embedded image suddenly 3/4 masked

[narrationsd]

I opened a project which had been fine in last beta, and found a main image was showing only 25% of its content, per attached pub-on-open.png.

Experimenting, I found that magnifying the view a few times in succession would bring back proper 100% display, per attached pub-after-several-resizes.png

Saving the project with 518, closing Publisher, and reopening on the project didn't help -- same 25% result showing.

Life is sometimes a mystery, isn't it...!

[Jon P]

Hmm, this was an issue but some of the examples I had were all fine in 518.

If you insert it from scratch is it fine?

Can you upload the file here?

[narrationsd]

Jon, apologies for the delay -- had to wait for the weekend to spend the several hours it took to narrow this down, and produce demo files that should let you play with it.

Along the way notes:

• this problem occurs on an afpub that was generated from an Indesign idml.
• theidml was a bit of a mess. I cleaned up the area of this image, but problem remained.
• Actually creating an afpub with the 518 beta and this image, there was not a problem - was clean

Then, here are the particulars for the demo sent, same on the original

• As you receive it, even the thumb image in the Windows 10 latest everything file preview is quartered
• the same when you open it
• If you save a copy of the afpub, and then change the image to Embedded, via the Resource Manager, save, close Publisher, and reopen, the problem will have gone away.
• If you save another copy, then with the Resource Manager Replace the image with the nearly identical brignt.psd provided, save, close Publisher, and reopen, the problem will go away(!)

The trick of it is, the original afpub has the linked image _named_ the same as was in the idml and preceding imdd. However, I created this by opening the original image with Affinity Photo, clearing the content, then pasting in the same image as in bright.psd, adjusting so it overlapped the boundaries so those remain the same, then saving under a name that's 'near'  the original in the idml and afpub files. Just -b added to the name.

• once you've cleared the problem by embedding the File0773soft25b -b.psd, it will not recur. You can Replace the embedded with the same file linked, and there will not be the quartering problem.
• I'm a little surprised this didn't turn out to have to do with the exact file name. But it may well have something to do with the exact dimensions of the psd, which is why I created it in the way I did.
• The original jpg for the psd-- if I linked that, no problem. Problem only on the psd. I'm not giving you that original jpg as it's private. But you could perhaps duplicate this aspect by exporting the psd to a 100% jpg. I would guess that is not going to have the problem either, when you link it. Bu then in my experience going back to linking the psd will.

Ok. As you may imagine, there were lots of intermediate steps to arrive at what could duplicate, and in a small file. I nearly gave up, but persistence got you this demo. I hope it helps clear up a corner in Publisher -- seeming likely to have something to do with creating an afpub out of an idml, but maybe it's just something about that psd and the framing dimensions.

And, just before leaving this note, I had a look inside the demo file, and found a bit left over of the original mess -- all the groups around the image. So, I cleaned those out, and in fact removed the extra Layer, so that there is no grouping, just the image and a blank caption (which lies in its 'from jpg' name). The quartering problem still remains, so has not to do with any extra layering.

I wish you guys fun, and actually hope this winnowing, demo, and counter-demo procedures will leave the cause clear.

Regards,
Clive

files are in that Dropbox bucket you provided





[Joachim_L]

Just out of interest. Is there a path inside the PSD? I have noticed, that importing an IDML using PSD with paths is shrinking the path of the PSD. But this seems to be fixed with .518

[narrationsd]

Hallo Joachim,

Interesting idea, but there isn't a path in the PSD -- just had another look to see, using Photoshop CS6.

I'm hoping the stark appearance of the image, precisely one-quarter visible, should alert the developers to the problem they apparently solved before Beta 518, which will make it easier to understand what's still triggering it.

Interesting name for your village...

Grüss,
Clive

 

[Jon P]

Thanks for the info, I've found i can nicely reproduce it by just placing the file (clicking so it's placed at it's original dimensions), ensuring it isn't actively selected and then saving/reloading the file it is placed into.

I've logged this, it's very similar to another issue that we fixed recently so am surprised it wasn't covered by this fix

[narrationsd]

Jon, sounds good - that's just what you should see.

The rest of the information is to cover results of variations, which may help home in on what's actually going on.

Glad to hear you guys are on it -- quite appreciating both what Affinity does, and how each of the portions continue to improve.

[narrationsd]

Nice to be able to report that on Beta 523 this item is essentially fixed.

By the time the afpubis fully loaded, the linked image now shows in full.

It is still a little hinky-- during loading phase, the linked image is still showing only a quarter.

Would note that resaving didn't seem to help with this, and that it's more evident on a longer document than the demo, so that it takes longer to complete loading. You can show this solidly by just adding pages onto the demo. The one I'm looking at has about thirty pages, almost all text.

You'll likely want to fix in full, but should be just a matter of ordering and/or when to event/publish to actual display...

This will make overall impression as comfortable as it is now once document fully shows.

Cheers to devs