Jump to content
You must now use your email address to sign in [click for more info] ×

PDF export issue in beta


Recommended Posts

I am experiencing odd PDF export issues concerning PNG linked images. I prepared a simple afpub file with a single placed (linked) image to demonstrate, and the file and linked image are here included as attachements.

When I export it as PDF with the preset PDF (for web) in 1.7.3, it exports it as I would expect:

1.7.3 export.pdf

When I open the same file in 1.8.0.549 and export it with the same export preset, this is my result:

1.8.0.549 export.pdf

It appears that rescaling is involved, because if start with the PDF (for web) preset, but then change the DPI to 300 (document resolution), then it exports as expected.

mac 10.14.6

 

 

test_files.zip

Link to comment
Share on other sites

  • Staff

The image has been compressed differently, I can't reproduce this from your example files, it exports fine for me.

If you can constantly reproduce it can you attach a screenshot of the export settings it is using?

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

Here are the export settings (but it is just the PDF for web preset):

485878282_ScreenShot2020-02-12at11_32_28AM.png.35ef68f97c8caf36dc3ade35a11b2aba.png

 

I am able to download the zipped package from my own post and reproduce the problem from the downloaded version. However, I did notice a key detail, and it is something odd. When I try to open the document in the beta, and it gives me the message about "Opening non-Beta Document," if I choose "Make a copy," the export is successful, but if I choose "Continue," that is when I get the export problem.

-------------------------------------------------------------

While we have this file, I have noticed something else. Open that file in the beta and choose "Continue" like I just described. With that file still open, go back to the Finder and from there try to open the same file with the beta again. Every time I try it, Publisher beta hangs. 

 

 

 

Link to comment
Share on other sites

  • Staff

I still can't reproduce this (without intentionally exporting to a much lower DPI) I'm fairly certain the export DPI isn't being set correctly but I'm not sure why continue/make copy would change this. The only difference I've spotted is I need to re-link the image when making a copy of the file. Those exports settings look fine and should produce the 50kb~ pdf, and do for me, I'll continue to try poke this and find out what I might be missing.

Quote

While we have this file, I have noticed something else. Open that file in the beta and choose "Continue" like I just described. With that file still open, go back to the Finder and from there try to open the same file with the beta again. Every time I try it, Publisher beta hangs. 

This is already logged with us but thanks for making sure we knew.

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

Wow, the next build came quickly. However, it did not fix the problem.

I do not know what else to do but show you this quick demonstration in case I did not explain adequately in my written description. Maybe I failed to point out something relevant.

Right before I filmed this, I downloaded the zipped files afresh from my first post and opened the decompressed folder. That is what you see at the beginning of this video.

Link to comment
Share on other sites

I got similar results with your image:

PDF_export_test2.pdf

I tried this test two ways with the same results. The first time I created the document in 1.7.3 and then opened in 1.8.0.556 in the same way as before (and followed the same steps as in the video).

For the second test, I started a fresh document in 1.8.0.556, using the A4 "Print Ready" preset. The result was the same either way.

I am using macOS 10.14.6

Link to comment
Share on other sites

  • Staff

You are on the same MacOS are my macbook. If you export to "Web - (digital - small size)" and re-enter 72 into the DPI field and press enter to ensure its accepted and then export is it correct?

Have asked colleagues to try this and none of us can reproduce this so far :(

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

@Jon P Reentering 72 and ensuring it accepts it does not seem to help, but I have noticed that the problem does not happen every time, even going over the exact same steps. In the video below, I had my test file open (with your new graphic), and I exported seven times in what I think was the same way each time. Four times it failed (the graphic was just a solid green) and three times the graphic was exported as expected.

Link to comment
Share on other sites

I do not understand how the same steps could produce different results. Here is another video (the most boring 30-second clip on the Internet) that shows a symptom that is probably related. In this clip, I keep selecting the same preset over and over, but notice that the estimated file size is usually 4.83kb (rather small I would think), but three times it is 22.23kb. Why should I get different results from the the same thing?

Link to comment
Share on other sites

42 minutes ago, Jon P said:

do you have this image inserted from a cloud drive by any chance?

No. In the last two videos, the .afpub and .jpg are both saved to the desktop, and the exported PDF was also being exported to the desktop. I continued the same practice in these tests below. Note that I do have iCloud Drive, but the "Desktop & Documents Folders" syncing is not activated. 

31 minutes ago, Jon P said:

If you embed all the images do you find the behavior more consistent?

I still encounter the export problem even when I embed the image (via the so-named button in the Resource Manager) and save again before exporting.

18 minutes ago, Jon P said:

Also, do any of you have "Auto update images when edited externally" ticked in Preferences 

Yes, I do have that preference ticked. However, I just unticked it for an experiment, and I also got a bad export on the first try after unticking and restarting the app.

I'm about to try a further test with multiple images and multiple instances of each to see if they fail all at the same time or different images at different times, as it seems to be the case with PatrickM.

Link to comment
Share on other sites

8 minutes ago, garrettm30 said:

I'm about to try a further test with multiple images and multiple instances of each to see if they fail all at the same time or different images at different times

I have tried that test now. I have edited the file to contain four duplicates of each of the two images we have been using in this thread (the first is a png that I provided in the top post; the second is a jpg that Jon P provided in post #9). All files and exports were saved to the desktop. The duplicates were created with option drag (so should be a link to a single file for each image).

Now on to the results. For exporting at 72 dpi, I invariably got the following result every time in at least ten tries. Notice the very top of each image, which shows some more image detail than the rest of the image. It is like the filestream gets misinterpreted somehow.

PDF_export_test_multiple_72.pdf

For exporting at 300 dpi (the document resolution), I got successful exports most of the time, but in a few tries I got results like the following. I saw it fail both on the png only and the jpg only as in this case:

PDF_export_test_multiple_300.pdf

Conclusions: I observed that the failures were always at the file level rather than the instance level. By that I mean that if an image failed, all four copies were bad; otherwise, all four copies were good. Further, it seemed random whether it was the first image only, the second image only, neither image, or both images. I never made any edit to the file between all of these tests, and the only change of export options was manually entering either 72 or 300 dpi.

By way of experiment control, I performed this same test on the same file in release 1.7.3. I exported at 72 dpi ten times, and it was a good export every time when using the release version.

I have attached the .afpub file that I used for the tests in this post.

PDF_export_test_multiple.afpub

 

Link to comment
Share on other sites

  • Staff

Thanks for the effort you've put into providing additional info on this, I'm looking into trying to reproduce this at the moment but still having no luck, I have a few ideas I'll look into and I'll give you an update if I figure anything out or eventually reproduce this!

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

I did not see anything about this fix in the notes for 584, and I was nervous about this going to release candidate.

However, I am not able to repeat the problem at all in this first RC. I am using the same files from my previous post (right where I had left them), and I am following the same steps. I have tried at least twenty time, and I have varied some of the export settings as well. It exports as intended every time. Additionally, the file size estimate does not vacillate between two different sizes as it did in my video above ("the most boring 30-second clip on the Internet").

I don't know if this is one of those unmentioned "miscellaneous" fixes or if it "fixed itself." But I don't know what else to say: so far it does seem fixed. @PatrickM How about in the Windows release candidate

Link to comment
Share on other sites

  • Staff

It's good to know it's fixed in the latest beta, the other user reporting this has indicated the same.

Let me know if it happens again. I could never reproduce it to begin with (even after writing a script to change the export preset a lot of times and checking the size was always the same), so it's intriguing why we could never see this, but good to know it seems fixed!

Serif Europe Ltd. - www.serif.com

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | 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.