nwhit

Still doesn't work in v442. If I rename an open file in the Finder, then make changes to the file in APub and resave, it creates a new file/doc. All other Mac apps I am aware of over the years will self-correct the changed file name.

Crash report attached. Crashed after selecting the 3 NEF pics. Had not happened after doing a dozen or so, but this was after a lunch break, so not sure of that had anything to do with it. Affinity Photo Beta_2019-07-26-140329_TRAC-Main17.crash

Same on High Sierra

No, didn't click or enter another Persona. I think the key issue (in hindsight) was that I had edited one of the other APh files in another window, saved it, then came back to the main document. Once I did that, I noticed that if I right-clicked on the layer that had originally been copy/pasted from that changed document, I did not get a contextual menu dropdown. Same with trying the Layers "burger" menu - nothing. I was trying to see if there was an Update menu item to bring in the changes I had made to the original text document I had just updated. Since I couldn't get contextual menus to work, I clicked on the top menu bar, possibly the Edit menu, and voila! The 3 grouped Studio panes mentioned vanished from their docked spot in the middle-right sidebar. When I quit and restarted the app, the "missing" group of panes showed up detached as a group just right of the middle of the entire screen. Someplace there is a thread where someone with a similar issue said the panes disappear off the screen, perhaps, but no explanation why. And no explanation why making changes to a file that has been copy/pasted into the main file might cause issues. I'm aware of the several issues in APub with linked files having problems when they are changed, but not sure how that might relate to this since the text elements/layers were simply copy/pasted into the main doc in this case.

Thanks! So far seems a little faster on a couple things tried, and fixed at least one issue for me. Having integrated APh into my workflow more and more, I am, however, finding a huge issue. I've rearranged things a lot in the Studio/workspace. And all too often, if I crash trying out things, I find I can lose my workspace arrangement and have to start all over again rearranging things to get it back to what I prefer for my work. At least I've become smart enough to do a screen capture of my workspace so I know where to begin It would just be a HUGE improvement if we could save and name workspaces in all Affinity apps. Just takes too darned long to rebuild a workspace if a crash or something else resets it back to Default. Thanks!

Appears to be fixed in v147 based on initial tests

Still does it in v147

Interesting note. This is also happening in the Photo beta v146. I did find that if I went into the Export/PDF dialog and turn off the option to Preview resulting file, it no longer opens Preview after exporting a JPEG. And as stated before, JPEG export doesn't have an option for previewing the resulting file, so cannot simply uncheck it there. Not that it wouldn't be a decent option in that and other dialogs.

Consolidated. Normal mode.

For even further clarification , type=text for those too young to remember. I started in the days of "typesetting" and "copy-setting". Even lead hot-type. Too used to the old industry slang for many publishing/printing things.

Agreed. Preview has many, many clever uses. However, it is not an option in Affinity Publisher beta to have it open an exported JPEG. PDFs, yes, but not JPEGs. As I said, it is apparently "storing" that pref from the PDF export options and applying it erroneously to the JPEG export. That said, it would not hurt to have it as an available option for JPEGS. But it just isn't there now, so this is a bug.

The main Affinity Photo beta document that had the issue reported. Made revisions to the other Affinity Photo beta document that contained only text/type. For full clarification/translation of the shorthand slang, I created a new Photo beta document that then had the reported bug problem. Within that Photo beta main document (containing a jpeg background layer) are two other groups of layers containing only type/text. Those two groups of text/type were created in the other two open Photo beta documents (one Photo beta document for each group of text layers, each group containing two Artistic Text elements), and those text/type Photo beta documents remained open while working on the main Photo document containing the background JPEG and the two grouped layers of text copied/pasted from the other two described open Photo beta documents. In other words, all 3 Photo beta documents were open, but it was the one with the background JPEG and the copied/pasted text/type groups that exhibited the reported bug of vanishing Studio panes. [Separated Mode or in a consolidated window?} Consolidated. I'm using the Mac beta forum to report a Mac bug. A similar "disappearance" of Studio panes/panels has been reported, but this appears to have a couple different circumstances.

Not sure how exactly to reproduce this, but it's happened 2-3 times. Had an existing new doc open, very simple, created in the beta. One layer group was from another open APh doc (2 blocks of artistic text), the layers copied and pasted into the main doc. I had just revised that type doc, then went back to the orig main doc to see if I could somehow get it to update or if I had to copy/paste it in again. When I right-clicked on the text group (2 text items grouped), I didn't get anything. I also tried the "burger" menu dropdown (Layers pane), but nothing there. I then clicked on one of the main menu bar items (possibly Edit) and immediately the group of Studio panes (Layers, Adjustment, Effects, styles, Stock) disappeared from the right middle sidebar. When this had happened previously, I made the wrong choice by using the Reset Studio which lost a ton of time, requiring me to completely re-set-up my customized workspace (need to be able to save workspaces!) from scratch. This last time just now, I just quit the app and when I restarted, the missing panes were floating together in a group right of screen center towards the top. I could then drag the group back to its place in the right middle sidebar. Not sure which part of what I did caused the issue but it generated a lot of curse words when I lost my workspace! I'm thinking it is somehow a result of editing the text group in the other open APh doc, then going back to the main doc. The main doc is very simple — a main full-frame low-rez jpeg as background, then 2 groups of text copy/pasted from other open APh docs (2 artistic text blocks in each group).

Has been happening fairly often. An export of a JPEG in APub results in a switch from APub to Preview after the export. The resulting JPEG is not, however, opened in Preview. Had been using that option in APub for PDFs but that option is not there for JPEGs. I've found that I need to quit APub in order to get it to stop switching to Preview.

I've noticed when opening RAW/NEF files in the beta that the pic opens to the far left of the screen. Since the Develop persona does not have any panes/panels in the left column, once the pic is developed and it shows up in the Photo persona, it is covered by the typical left panes, thereby requiring moving the pic back to the center of the window. I can't remember for sure, but I thought in 1.6.7 that RAW files opened in the middle of the screen so that they did not need to be slid over for further work. If this is as-designed, would it be possible to get the RAW files to open in the center instead of far left? Thanks. (Tried uploading a screenshot but came up with an error message numerous times.)

Just did a group of 100 RAW/NEF pics, processed, cropped, tone mapped and custom exported. I used to be able to get some coffee drinking done and checking email etc. during each stage! Now APh is TOO FAST! I'm not even getting my coffee consumption where it needs to be! Thanks for getting this version working so much faster!

Interesting! I just opened the ID X3 PDF in ADesigner and see what you mean on how they are doing it. Interesting! Does the job, so I can't argue with how they do it too much!

Very much appreciate the explanation. And I understand that the many, many issues facing Serif/Affinity in making their apps as competitive and as "pro" as possible are very, very challenging, especially given their highly reduced revenue stream/business model. To once again clarify, my only point in this thread is that in my opinion this is a needed "feature"/capability for many pros who are used to using this technique and need to continue to do this, so I am hopeful that Affinity can solve this issue, as well as the many others it faces. But again, thank you for the clearer explanation. Doesn't solve the issue but certainly interesting to know.

Perhaps what I said did not translate correctly. There were MANY missing technologies when I started converting print shops, newspapers, universities, ad agencies, etc. in the early days. But when opacity and drop shadows eventually evolved and improved, it made things easier/faster/better/affordable. And the evolution of the PDF standard was also a great help. Just did an ID CS5 export to PDF X3. At maximum magnification in Acrobat Pro and Preview, I am not seeing any pixelation of the type. Perhaps I did something wrong. Perhaps it is there and my old eyes can't see it. But based on this test, it is much better (and perfectly acceptable to clients) as opposed to what I get from Publisher X3 output. Why? I have no idea. I'll leave that to the coders and students of the science. But as a designer, we need to put out product for clients and I simply can't see eliminating the use of transparency/drop shadows over text for those hard-copy printing clients. Not when I seem to be able to (still) get acceptable results using ID. Or at least it appears to okay. I'm not trying to argue technology, historical dates, science, licensing, proprietary technologies, etc. We as a firm, and the many other firms I set up over the years, have used these design styles for an awful lot of work, whether that's 10 or a thousand. I seemingly can still output PDF X3 from ID CS5 and get acceptable text rendering results for posters and other printed materials. It appears, based on this thread, that perhaps Publisher may not have that ability. Fine. As I said, I love Publisher and will use it for web work. Just wish it weren't so. And please, I'm not trying to start an argument. Nor am I challenging your knowledge of the subject. You obviously understand the underlying technologies much better than I ever wanted to. I'm passing along my needs and my experience using ID CS5. which appears to work acceptably -- unless I'm not seeing something correctly. Most importantly, I'm just passing along my requirements for doing everyday client work. While there is a lot less actual printed materials work being done today (I have friends in the printing business and others who are now out of it due to the downturn), there is still the occasional need, so need a method to keep doing these things. And I sincerely thank you and others for your help on this and several other issues here on the various Affinity forums. Always try to learn. And always try to understand. Some things I have to simply accept since I don't have the time to relearn too many things. Right now, for example, I'm really fighting the issue with Affinity apps where you cannot save/name the "Studio" setup or workspace. I and others are struggling with betas that crash, mess up, etc. and the workspace setup is lost. And with the new Studio Link, it's even more disastrous if you've taken time to set up each Persona to your working style. Why can't we save workspaces? I have no idea. All I know is that many apps such as FCPX are based on the ability to set up multiple workspaces for different workflows. Seems like it is doable, but I would not and cannot argue the technology involved. Just something many of us need to make Affinity apps really usable on a day-to-day basis. Again, I apologize if I have seemed argumentative. Didn't mean it that way at all. I want Affinity to succeed and I appreciate you sharing your knowledge. sample text under graphics - X3 output - ps.pdf

Perhaps not simple (improper word choice), but it was resolved many, many years ago. Over the years, my firm has done thousands and thousands of drop shadows and transparencies over text ever since that capability was first introduced way back when (I go all the way back to PageMaker v1 and the intro of the very first laser printer). I'm not trying to trivialize the amount of work it has taken Serif to get where they are, but to move forward on the premise that we as designers cannot use transparency or drop shadows over text is not a reasonable offer. Simply far too restrictive for most client's print projects. But as I said, I love Publisher and look forward to using it for RGB web work. And I am hoping that they can resolve this issue so that we can then use it for cmyk print output.

From looking at the workaround, it then appears that there is no way possible to have a drop shadow or transparency on top of text. Is that correct? And can I also assume that even if the graphic with a drop shadow or transparency over text were created in AD or APh and imported into APub, it still would not work with a cmyk-X3 export? Imported/placed in any format???? Eliminating drop shadows and transparency over text is a VERY design-limiting issue. Over the years, we've simply become very spoiled using these techniques over and over without issue. I just hope Serif can resolve this issue.

I think I understand now. The Picture Frame must be the exact size of the graphic element and cannot include anything transparent. Thus drop shadows have to be manually created and added in a masking Picture Frame that does not intersect underlying text. While I now understand how you did this, I can also see that this is a HUGE PITA. I'm thinking that until Serif can solve this issue, my production company will have to continue to use our old CS5 ID for anything requiring CMYK-X3 output for a print shop/print job. Just way too much to be concerned about when creating something if we're suddenly back to the old days of difficult transparency and drop shadows (yes, I remember those days!). I've been really liking Publisher throughout the beta process and have been using it to produce several web pdf publications, but this issue really spells trouble for doing any print shop cmyk work. Just far too easy for someone to forget about the problem and how to get around it, plus the extra time and cost to the client to watch for and fix the issues in a publication. Yes, a designer can work around the problem, but with extra time and cost to the client, plus the chance of problems. Never would have expected something so simple to be "missing" in Publisher, so I am very saddened about having to go back to ID for some of our work. Hopefully one of the mods can assure us that this will be fixed/upgraded soon.

Yes, the current beta (146) for 1.7.2 is noticeably faster for many things on certain computers.

Attached. sample text under graphics - upload.afpub

In playing with this, I guess I'm not understanding how to overcome this issue. I tried putting both a APh TIFF and the actual APh graphic into a Picture frame and still get the rasterization of the Artistic text around/under the graphic element when exporting with X-3. Thus I guess I am missing something important. In all the beta testing on Publisher, I never came across this since I had not tried overlaying a graphic item over text, but this is a big deal for a lot of work on print shop output work for clients. Hopefully there is a simple, satisfactory workaround. I also just tried the same thing in ID CS5 exporting with X3 and it does not raster the nearby areas of text. Sample of APub beta 422 pdf-X3 output. sample text under graphics - X3 output.pdf