nwhit
Members-
Posts
735 -
Joined
-
Last visited
Everything posted by nwhit
-
Suggestions for "New Document" window
nwhit replied to Jeremy Bohn's topic in [ARCHIVE] Publisher beta on macOS threads
My feelings for improvements on the "New" window/pane: 1. Agree, should be resizable. 2. Recent Items and Templates tabs should be off/collapsed by default. Recent Items are more commonly/intuitively accessed through the File menu (although it's nice to be able to access them in the New panel); and creating a new doc from the Templates would be less common than using Presets. Thus for visual clarity, speed, etc., nice to have those collapsed. 3. User-created Presets should be at the top of the top-most pane. Most people will want to set up their own "complete" presets for common projects/docs, thus it would be faster/easier to have those topmost. 4. As mentioned, should be able to select and designate a Preset as the default, which would be selected initially when opening the New window/pane. Many users do a reasonable amount of work with a standard layout (for them). Again, ease of use and speed. Love the new flexibility and options of the "New" dialog, but think there are some good improvements to be made for ease of use, intuitiveness and speed. Thanks! -
Quicklook process :: very demanding in v518
nwhit replied to thomaso's topic in [ARCHIVE] Publisher beta on macOS threads
Aha! Had not thought about the idml files, but now that I look, I now see that idml files are included in the "Recent" section. Thus for people who have not tried the IDML import, they might not see this quicklook issue as seriously. -
Quicklook process :: very demanding in v518
nwhit replied to thomaso's topic in [ARCHIVE] Publisher beta on macOS threads
I think I have narrowed this down. The newly designed New dialog pane also is attempting to show previews of ALL recent APub docs and templates (not presets) IF THE ALL BUTTON IS SELECTED, so it apparently is having to search all HD's to get previews of the perhaps dozens of previous APub docs on a person's computer and external drives. That could be an intensive process and might be the cause of this issue. I just tested the beta by opening the CMD-N window and turned off the "ALL" button by clicking on the "Presets" button. I no longer get the runaway quicklook processes nor the excess beta app CPU usage. If I then click on the "All" button, the excessive CPU quicklook processes start again. But if I quickly select "Presets" instead of All, the processes stop. Just a guess, but it seems it is narrowed down to that newly designed New window where with the "All" selected at the top, APub now shows previews of templates and recent docs. For some of us, that's a lot of previews to be generated within that window. Guessing that Affinity is using Apple's QuickLook to generate those previews, but it seems to be casuing excess CPU issues if that "All" is selected, even after you close that window. You have to deselect the All by selecting Presets to get the excess CPU to stop. Once you close that window (such as with a Cancel), those processes (generating previews) should stop I would think. Also likely need some better way to control the preview process so that ti doesn't cause such a huge issue for CPU usage for such a long time. -
Suggestions for "New Document" window
nwhit replied to Jeremy Bohn's topic in [ARCHIVE] Publisher beta on macOS threads
It would be convenient to have it fill all values, but I can't see how it could tell which value is the "master" value that should be used as the "locked" value. For example, if I had set up a margin of 0.25" Left x 0.75" Bottom x 1.0" Top and Right (which is quite common to have different margins), and then I change one of the values and click on the "Linked" icon, which value should it "guess" is the one I want as the "master" value? IIRC, all apps I currently use operate this same way. You first need to click the Linked icon BEFORE changing a value that becomes the new "master" value. Otherwise it might be difficult to determine which is the new "master" value. I imagine that you could say that it is the last field changed that becomes the "master" value, but I'm not sure I've seen any other app that uses that paradigm. -
Quicklook process :: very demanding in v518
nwhit replied to thomaso's topic in [ARCHIVE] Publisher beta on macOS threads
Did you do a CMD-N? I don't get the runaway processes until I try to open a new doc with the new "New" interface. But once the runaway processes start, they don't quit. I just left the beta running in the background for an hour and both the quicklook processes were still running high CPU and even the beta was using more CPU in the background than 1.7.3 or other apps. Update: I just left the beta running in the background for about 20 minutes but did not do a CMD-N since opening it. Did not get either quicklook process showing and the beta used very little CPU (about the same as 1.7.3 and other background apps). It appears that the New dialog is not only causing the high CPU quicklook processes to run, but also then leaves the app itself using more CPU. All of this is with Metal, BTW. Might be a difference???? -
Quicklook process :: very demanding in v518
nwhit replied to thomaso's topic in [ARCHIVE] Publisher beta on macOS threads
The quicklook processes start up with the beta open when you open the create a New document panel. They only stop when I quit the beta, so definitely tied to the beta. I don't get either quicklook process when running 1.7.3, even when opening the New doc panel. -
Quicklook process :: very demanding in v518
nwhit replied to thomaso's topic in [ARCHIVE] Publisher beta on macOS threads
Seeing the same thing. I saw that high CPU yesterday but did not relate it to APub beta. But based on this thread, just opened the beta again. I can see where the quicklook processes start to go wild is when I do a Create New. Th efirst time I tried that, then canceled, the quicklook processes stopped. But the second time I did a Create New, both processes started and wouldn't quit after canceling from the New dialog pane. I had to quit the beta to get them to stop. -
Narrowed the issue. Looks like this is not an IDML or beta 518 bug. I just tried this in 1.7.3 and now see that I can't insert a cursor within a text frame that is linked to the one where I did a Select All. In the docs we've created to date with Publisher, my best guess is that we have used multi-column text frames as opposed to linked text frames. But not sure that this is not a bug Publisher. I would think that if you are working in docs with linked text frames that you should be able to select all text for linked text frames, apply formatting, etc., then click within any of the linked frames and have it clear the Select All. As it is now, after doing a Select All within one of the linked text frames, you can click the cursor in another of the linked text frames as many times as you want and it will not insert the cursor nor clear the Select All of the text shared by the linked text frames. I can see that with our upcoming work where we will now be importing older IDML files that will most certainly have linked text frames (as opposed to multi-column text frames due to the import process), we will VERY often be doing a Select All of all linked text in order to apply formatting, etc. Just makes sense that we could then click within any of the linked text frames to reinsert the cursor rather than having to remember which text frame we started in (with the Select All). With multiple linked text frames on a page, it can be difficult to remember which frame the Select All was done in, thereby making a person wonder why he can't get the cursor to insert within a text frame! (An idiot like me, for example!) Thanks. At least I've narrowed down the issue. Hopefully it can show up in future fixes.
-
That appears to be a sample template included with the beta. I do not see any place where it is being stored, so it would be interesting to see where this sample template is actually kept in the beta. My guess is that the actual release version might include a sample template or two, or Serif might be working with other users/beta testers to have a few available. On the other issue of Presets, yes, it would be interesting to know where those are stored. I've looked in the Library/Application Support/Publisher Beta folder and don't see anything there that is obvious. Best guess is that the Presets are being asotred somewhere within the ~/Library folder/directory.
-
Affinity Publisher voted the best Mac app 2019
nwhit replied to Nana's topic in [ARCHIVE] Publisher beta on macOS threads
Yes, very well deserved! Job well done (so far!)! -
Light bulb went on! Think I see where the problem is occurring a bit more specifically. The inability to deselect text (after selecting all) seems to be only when you try to click within a different linked text frame from the one where you did the Select All. If you click anywhere within the originally selected text frame, you can deselect just fine. But if you have multiple text frames linked, do a Select All in one, then try to click within another linked text frame to deselect, doesn't work. And I am getting this in all of the ID CS5 docs that I've exported/imported so far.
-
Interestingly, I've done a few more conversions/imports and did not get the cropped pics/graphics. But on the ones that have had the problem (like the one in my prior post), they still do the same thing when closed and reopened.
-
I just converted a similar ID doc to the one giving me a problem, exported as IDML, opened in APub beta 518. This one has the same issue with selecting/deselecting text. Interesting that it is in a similar ID doc but not another. That said, the initial one that I tried was a derivative of the older one I just tried, so the problem was likely in the earlier version of that publication and somehow is still in the updated version that I initially tried to convert and open. But for the life of me, I can't seem to see anything in the original ID docs that might cause this problem. It doesn't happen within ID CS5, but both have the issue in APub. I'm going to open a few other older files to see what happens with them. UPDATE: AHA! Just had it happen on a different ID brochure import! This older ID file was not a derivative of the others, so it looks like it is a problem with the import of some ID files. These are ID CS5 files. Will upload one of them if you can get me a link. Thanks. PS. - Loving the way the import is working so far, despite the minor issues. So much better than opening a PDF version since we get properly linked text frames, pics and graphics within frames, the original ID layers are brought in/respected, and the overall layout and type is pretty darned good! Congratulations! And a HUGE thank you from all of us that have archives of client ID files!
-
Need a link please. Interestingly, I just opened another older IDML and I don't have this issue with the text. Seems unique to that ID doc conversion. I think I will try to convert to IDML and reopen to see if it still happens. I also have 2-3 more variations of the problematic ID docs that I can try.
-
Imported/Opened an IDML 6-page doc in beta 518. When I Select All within the connected text blocks on a page, then try to single-click somewhere within those now selected paragraphs, I often can't get it to deselect all the text, even after several clicks. Eventually I can find a spot where it does insert the cursor and deselect the text. Can't seem to see a pattern as to where I need to click within the text in order to get it to deselect all the text. I tried opening a doc created in 1.7 and it does not do this. But the IDML doc imported has the issue on every page (each page has connected text frames). I also have not experienced this within anything done in released versions before. Screen_Recording_2019-12-02_at_5_56.43_PM.mov
-
1.8.0.518 – Partly blurred UI
nwhit replied to SillyWalk's topic in [ARCHIVE] Publisher beta on macOS threads
Not seeing it on Mojave with Metal. -
Affinity Publisher Customer Beta - 1.8.0.518
nwhit replied to AdamW's topic in [ARCHIVE] Publisher beta on macOS threads
Thanks for adding the expandable Hyperlinks pop-up dialogue window! Really should solve the issue we had with many long URLs in a document! -
With new beta 518, imported the same "WWT Wastewater" advert idml file. It loaded fine except all PSD and eps files required updating "Modified" linked files. Also, upon saving the file, then reopening it, the EPS linked file had the same issue as previously where it was cropped until I clicked on it, which then restored it to a full frame. No crashes or hangs so far. Just tried the "Accel Retro" brochure import and had the same issues. All PSD and EPS files required updating in Resource Manager. And when I closed the file and reopened, several EPS pics were cropped. In this case, I had to go to the Layer panel and select the actual pic (not the pic frame) in order to get the pic to go back to correct size. Not a huge issue, but still not working just right I would think. After last opening this one, clicking on the pic in the Layers pane, then saving and closing, when reopening the pics still were cropped. But this time I could just click on each of the pics to get them to resize. UPDATE: Just opened a 6-page IDML. In this case, all EPS, PSD, PDF and AI files required updating the links. Less issues with wrapping in this beta!
-
Looking forward to it! Thanks.
-
Interesting. I re-imported the IDML, corrected the psd-cmyk files, saved, then tried to reopen. Crashes constantly. Not sure what is in this doc that is causing the problem, but it's a common ID file. And it seems to convert everything fine (except the psd-cmyk and adding the soft-proof-adjust). UPDATE: And now I can't open my other imported file that was working beofr, so something is really messed up with the app at this point. New crash report for trying to open the other file attached. Affinity Publisher Beta_2019-11-19-130518_TRAC-Main17.crash Affinity Publisher Beta_2019-11-19-130819_TRAC-Main17.crash Affinity Publisher Beta_2019-11-19-131218_TRAC-Main17.crash