nwhit

Trying to understand this. I tried a few other options to see if it would get fixed. 1) Opened one of the AI files in ADesigner, then replaced that in the APub doc. Still no controls for the Picture Frame. 2) Saved from AD as EPS, PDF, JPG. Still no controls for the Picture Frame. It appears that once the error happens at import/Open, and it creates the bad Picture Frames, it would require creating entirely new Picture Frames and deleting all old non-functioning ones.

Opened a different IDML. 1) Noticed that any linked graphics that did not have a file type appendage would not show. Had to go to the actual file, add the appendage, then Replace in the RM. 2) A couple of graphics (AI files) were imported within Picture Frames, but there are no Frame controls showing, so cannot modify the image using those controls. All other graphics using a picture frame do have controls, so looks like it's just the AI file types. This file also created the mystery 1x1 graphic items (2 of them).

I just imported a couple more IDML files and see that most all ID-created rectangles etc. are imported as Picture Frames, but without they usual Frame controls, probably because there is no image within the frames. Maybe this is normal??

Just noticed another odd item. On page 1 a rectangle was imported as a Picture Frame, but has no content contained within it, nor does it show the normal Picture Frame handles/controls. When you select the rectangle (Picture Frame as shown on the Layers pane), the RM shows a jpg being associated with it, but that may be simply defaulting to the top of the RM list. But still odd that the rectangle was imported and/or shows as a Picture Frame. Perhaps this is just how it's done???? Doesn't seem to cause an issue, but a bit confusing.

Just checked a different IDML import, a 4-page (2 - 2-page spreads) and it also had a small 1x1 TIFF created within a Picture Frame. In this case, the Frame can be seen when selected (a grey colored frame with beveling effect), but the 1x1 graphic within the frame does not show when selected or turned off. Obvious, of course, given that it is so small, but still there is no way that a 1x1 graphic element was in the original ID document. Something is getting read and these tiny 1x1 TIFFs are being generated within the document, which then results in APub asking where you want to store them (linked or embedded). In this particular document, I obviously said to leave it embedded unlike the other document where I specified Linked.

I just checked the same doc that I had imported in b518 and saved, and it also has the same two 1x1 graphics. I guess I had not noticed them before, so not unique to beta 523. Odd thing is that I can select the Picture Frame in the Layers pane but nothing is highlighted on the layout. And the two items cannot be Updated in the RM.

In this 6 page document where I had the odd warning of Too Much Embedded Graphics, it created 2 – 1px x 1px TIFF graphics and put them into the Links folder I designated when I got that odd dialog reported in the other thread. However, I cannot see either of those tiny graphics in the 2 places it says they are, and they do not preview in the Finder -- just get a spinning beachball. If I use the Resource Manager's Locate button, it takes me to a page, but nothing is "selected" on the page. A Layer is selected (as per the attached pic), which is a Picture Frame with the 1x1 graphic within, but nothing is shown or selected on the page. I can't imagine that there actually existed a valid 1x1px graphic in the original ID document, so this is somehow being interpreted by the import or IDML conversion. Minor issue in this case, but odd nonetheless.

When I clicked to Update the files, I got an unusual dialog popup. I think I may have seen it before in prev beta, but not 100% sure. Asks if I want resources to be linked instead of embedded, but all files were already linked, so not sure why it would ask. (There NO embedded resources/graphics in the document.) Also noted that 2 of the graphics would not Update and continue to show Modified.

Still have the issue with opening an IDML where all linked PSD, AI, PDF, EPS files show in Resource Manager as Modified and require Updating.

Also be aware that there is a reported bug regarding pics/graphics coming in via IDML import not showing correctly, even after fixing, saving and reopening the file. You can read about it in a post on this forum and it is being worked on. Hopefully will be fixed in the next beta.

I've done a number of IDML imports/Opens and all of the many linked files came in linked. Only items that were created within ID such as rectangles, circles, etc. were embedded. I think it would be good to ask upon opening what DPI is preferred for the doc.

Might not be the issue, but check to see if the import added "soft proof fx" to the affected title text.

Really have a problem telling what the stock pics are with a large monitor. Be nice to have the ability to either increase the thumbnail size (when desired) or use a Quicklook type feature.

Really have a problem telling what the stock pics are with a large monitor. Be nice to have the ability to either increase the thumbnail size (when desired) or use a Quicklook type feature.

Thanks! Will do.

?? Really have a problem telling what the stock pics are with a large monitor. Anyone know how to get the thumbnails larger? Or does this need to go into the Suggestion box?

Agree. As per my comments in the thread on the new "New" window/feature, think it's important that the default is for the Recent Items and Templates sections to be collapsed/not showing initially. Also that the Templates section show a user's own Templates first since it is more probable that if they have created templates, that is what they are more likely looking for in that section.

Guessing it's simply a Placeholder to allow the feature to show and be tested in this early beta (first time for the Template feature).

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!

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.

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.

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.

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????

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.

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.