nwhit

Have had this issue in the last few betas and still there. Using APhoto beta 168RC, have a graphic that is only roughly 7x3" and is a cmyk doc. When I place it in APub b584, the bounding box almost makes it look like a Letter size, thereby requiring either a lot of overhang of the empty bounding box or using a frame or other method to crop. Just cannot understand why it comes in with the strange bounding box. I also have an RGB version of this same graphic created at the same time and it places just fine. Don't know if the error is in APub or APhoto, other than it opens and looks fine in APhoto. I did just try Placing it in a 1.7.3 ADes new doc and it does place with an A4 bounding box, so maybe this is a problem with APhoto???

Keep getting bad output of a linked ADes graphic in the RC. I've tried linking to the ADes version and an eps export version from ADes with the same results. The ADes file is cmyk and was created importing a client's pdf. It reproduces fine when exported as a Digital Small but not with x4. Not sure where the issue is. Exports fine in 1.7.3. Think you may already have these files but can upload any you might not be able to locate.

Not fixed in b584 RC1

Just struggling with exporting pdf for email/web use using the new "Digital - small" setting. Have tried setting DPI at both the default 72 as well as 192 (preferred) and several pics and graphics either do not show at all or are very poorly reproduced. Can export as "Flatten" or for "Print" without these issues. I can also export the same file successfully in 1.7.3 at the 192 DPI using PDF for web preset. Really need this to be reliable or find out if I'm doing anything incorrectly since this is a lot of our client work. I've uploaded (to the usual dropbox link) the APub file with everything embedded plus some of the pdf exports. Attached are the settings screen capture.

It’s working fine. Just a problem with the preview.

Well, I was encouraged reading your post. However, when I did a fresh open of the pdf in beta 556, it opened and scrolled fine. I did a Save As to generate a APub doc. I had the other 2 simple docs open, I then quit the app. It quit fine. I restarted the app and everything opened fine. I was ready to celebrate, but thought I should try once more. Sadly, when I quit and tried to restart the app, got the crash (report attached). When I subsequently restarted the app, it asked if I wanted to reopen previously open windows/docs, I said Yes, but the app opened without the docs opening. Not sure what would be unique to my setup causing the crash when using only this pdf as the starting point for a new doc, but it is doing it repeatedly. Affinity Publisher Beta_2020-02-17-113424_TRAC-Main17.crash

Beta 165 still has the issue of EC previews requiring resizing the window in order to accurately see the preview. Screen_Recording_2020-02-17_at_9_50.13_AM.mov

Looks like that original pdf is causing the problem (already uploaded). I just tried opening it in 1.7.3, saved it, then tried to quit 1.7.3. Crashed, and when reopening neither of 2 files were open despite the dialog. Thus not sure why I can't open that pdf and save as APub.

Using various combinations of the 3 docs, I can sometimes get the beta to quit without crash. However, if 2 of the docs were open, it most often will crash when trying to restart. Then when I try to restart again, even though it shows the dialog asking of I wanted to open the windows/docs that were open, it doesn't open any of them. On the other hand, with just a single doc open, I can usually get it to quit and reopen okay. Starnge! Never had this happen before in any other versions, so don't know if that new pdf-to-APub file is to blame. ------ Okay, just tried with only 1 of the 2 simple files, individually and together (not the pdf conversion doc), and no crashing. But as soon as I open the pdf converted doc along with the others open, in one case I could quit without a crash, but it crashed when trying to reopen. And when I do re-reopen, none of the files are open despite the dialog asking of I want them open. Thus it seems the uploaded pdf converted APub doc is causing the issue for some reason. This last crash report on restart attached. Affinity Publisher Beta_2020-02-14-160205_TRAC-Main17.crash

I just tried to quit with only one of the docs open at a time and no crashes. However, when I opened a third doc that I originally had open when this first started happening, and had only that doc open (a converted/opened pdf), it crashes. I've attached the crash log here and uploaded the APub doc to the dropbox link. Affinity Publisher Beta_2020-02-14-152841_TRAC-Main17.crash

It's nice that both windows can be resized, but I've noticed in trying in this latest beta that neither widow's size stays set after a restart. Especially important in the Resource Manager window where the names of the resources are very often much longer than the "default" field spacing. If either window is resized, should be sticky between app starts. Thanks.

AHA!!! I thought I had seen it before but a search didn't show it! Thanks! Maybe it'll get fixed!!!

Happens multiple times. Crash logs attached. Test docs that were open attached. Also noticed that when trying to restart, those open docs did not reopen, even after the dialog asking if I wanted to reopen windows. Affinity Publisher Beta_2020-02-14-150620_TRAC-Main17.crash Affinity Publisher Beta_2020-02-14-150906_TRAC-Main17.crash Column Rules test - 531.afpub Test_of_clipping,_brushes,_circles_-_beta_556.afpub

Just tried to adjust the resolution min and max settings. The sliders don't change the number, so have no idea what the sliders are doing. Had to dbl-click to manually enter numbers in the fields.

In that same doc, the new beta 556 is having a couple issues in a pdf export (x4) that hasn't been there before this version. Attached are the errors on 2 pages from beta 556 and the same graphic items exported as pdf x4 in 1.7.3.

In b556, still cannot export the file as a pdf x4 if that pdf with the missing font is in the doc. I have just uploaded the APub file (everything embedded) and also the offending pdf graphic. File name: "Clean Water 2019 - WW -4pg - CMYK_print-beta556-missing font pdf.afpub" If I replace that placed pdf with the same CAD drawing that was the pdf but opened in ADes, where it converted missing fonts to curves, and place it as an ADes file, it outputs to x4 fine (although there are now a couple other errors in output in this latest beta that I'll post elsewhere). On the Preflight issue, I understand that Preflight can't likely "fix" the missing font within a graphic element that is a pdf (and has the missing font). But the problem is more that right now if Preflight shows the Missing Font warning, there is no way to determine where that missing font is within the doc! Double-clicking on the error message in Preflight does not take me to nor identify that graphic element, so there is no way to discover where the problem is. The only way I actually found the item with the missing font is that I recognized where that font would typically be used (based on historical experience of doing those CAD drawings). But under any other circumstances, in a multiple page doc, it might be nearly impossible to track down a "missing font" if it is within a placed resource. I guess my suggestion would be that like with any other error in Preflight, when double-clicking on the error message, it should take you to the item that is generating the error. Hopefully that's possible. I'm sure many people place pdf's or eps's into APub docs, and if supplied by outside clients, etc., it is probable they might have missing fonts. Just need to be able to identify the "faulty" item within APub so that it can be corrected/addressed. Thanks.

Thanks. Just tried in today's beta, 556, but same problems. Hopefully the next one fixes it.

I used the old link to upload: The original 1.7.3 file, but embedded resources. The PDF output from 1.7.3 with rgb conversion The beta 549 converted file with embedded resources. The PDF output from b549 with the same settings for rgb conversion.

Just noticed that a couple docs created in 1.7.3 that are designed to be both printed (cmyk) as well as used for web download/viewing as rgb cannot be exported for pdf in 1.8 (not sure which beta this started in). The doc (4-pages) is a cmyk. But in 1.7.3 we exported a Web 192dpi rgb version using the More/Convert Image Color Space. In 1.7.3, the resulting pdf is rgb and no problems with it. In b549 using the same doc (opened in b549) and same export settings, several pics, graphics, etc are not being exported at all or correctly. Problems all over the doc. You should already have this doc (Clean Water 2019 - FW - 4pg.afpub) but can upload if you need it. I'm guessing that it is having problems converting some of the items. Worked fine in 1.7.3, so looks like a regression of some sort. "More" pane settings attached. Started with PDF/Web/192 dpi + the More settings.

I guess I can see where for some workflows, always having the same number of pages for numerous presets might work. But I guess I see the main advantage of having specific format presets is that I can easily open/create a specific common blank document with all the specs "pre-set". Examples being a single page A4 bleed; a 2-sided A4 sell sheet; an A4 newsletter that's always 4 pages; the same 4-page newsletter set up for facing pages instead of scrolling pages; etc. Additionally, since some of the presets are for "photos", "web", etc., can't see those as typically being multiple pages. I guess I look at presets as just that -- all specs are specific to each preset, but can be changed prior to creating the new doc for one-off variations of the "normal" preset. I'm also guessing that most users will assume that what they set for specs when they create a preset will be how a doc is created. Currently, prior to creating the doc, it appears one has to review the specs in a preset to make sure they are what is desired for that common doc. Are there other specs that aren't saved when I create a preset? If it is just the number of pages, then that would seem inconsistent and lead to questions. Overriding a preset's specs for one-off jobs makes sense, but I really think a preset should be just that -- all specs should be preset for simple, quick new doc creation.

I did notice just now that the tooltips don't always show when hovering. I found I had to scroll the preflight window up and down several times in order to get the tooltips to show again after double-clicking on one of them. Happened several times, although not every time I tried, so not sure what the "formula" is for it to happen.

Found the issue. Preflight correctly flagged the issue, but could not locate the item with the missing font. Nor did it show in the Font Manager. What it turned out to be is a linked graphic, a pdf of a site plan CAD supplied to us by the client. As with other discussions of Affinity apps having problems with pdfs with missing fonts, this showed up when Placed within the APub doc and not only showed up as a mysterious Missing Font in Preflight, but was also causing an unidentified error (failure) in trying to export the doc as an X4 pdf. Affinity and I have been working on this doc for a month trying to figure out why it would not export. The good news is the new version of Preflight caught the missing font issue. The bad news is that Preflight could not locate or identify where that missing font was within the doc! Guess the result is that Preflight could use some improvement (hopefully it is possible), and the x4 export error message needs to better identify why the export fails. But at least both issues are somewhat solved for now! 😉

Tracked down both issues (missing font and X4 export). The doc had a linked pdf graphic element (a site plan) that had that missing font within that pdf. That not only caused the mysterious Missing Font warning (but Preflight could not show it was in that item), but also caused the failure of the X4 export. I'm guessing because of the missing font. Seems this could be an issue. I'm sure many people get pdf graphics sent to them where the fonts used might not be 100% matching to theirs. If including them within an APub doc causes this much grief (can't easily find the problems), might it not be better to handle the export error better? Or at least with Preflight have the ability locate the item/resource with the missing font? Both the Affinity team and I have been scratching our heads as to why this doc created in APub would not export. Preflight ALMOST found the problem, but maybe needs a little better capability to actually track down the problem item -- if that's at all possible. My workaround for that doc has been to open that pdf in Designer (which converted the missing font to curves, I'm assuming), then exporting it back out as an eps for inclusion in the APub doc. Perhaps it might be better to just link to the now converted Designer file??? That's assuming liniked Designer files are not presenting any issues within an APub doc. At least this mystery has be solved, assuming Preflight can be improved to find this type of error. We routinely use placed pdf graphics in our page layout docs, so it would be nice to catch this problem before it becomes a time-consuming output error. Never had this problem in ID, which I understand is an issue with pdfs with missing fonts opening or being used in Affinity apps.

Aha! The preset for Preflight had the Hidden Objects pref set to Look Inside Placed Documents checked. I'm guessing it somehow was trying to look within the linked Photoshop file and saying that something in that file was Hidden. I looked at the PS file and there are a couple layers/items hidden. Thus I guess the answer is to not use that checkbox when Preflighting for hidden objects!

With beta 549, this file still does not export as a pdf x4, nor does it calculate est size, same as before. In playing with this in the newest beta, I also made a thread on how it shows a missing (tekton), but the Font Manager doesn't show that font nor does the preflight error click take you to anything. Another oddity is that in running a preflight for Hidden Objects, it shows the top header graphic element as Hidden, but it clearly is not. In fact it shows the error twice, taking you to the same item with each error. If I remember right, this is an item put into the original doc in 1.7.3 from the Assets panel. The Resource manager shows it as a Linked resource, but when I use the Resource Manager's new Show in Finder, it does take me to the original PS file. So, in all, can't export as an x4, showing a missing font that supposedly isn't in the doc, and it shows a resource item as Hidden (twice) when it is not Hidden. You already have this file (Clean Water 2019 - WW -4pg) as well as the matching doc that hasn't had a problem exporting.