[Mac: Affinity documents are not "Documents" for Finder search purposes.]

2 minutes ago, loukash said:

I do neither. IDMarkz Free is only my QuickLook aggregator in Finder on Ventura.

Does having it installed cause Publisher documents to be collected by spotlight / finder file search as "Documents"? Because, that's the goal.

 

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

Just now, R C-R said:

I turned off "Recents" in the sidebar many years ago because it only showed certain document types & also among the dozens & dozens of files it listed it showed certain files that I had not touched for years. 

That said, I am running Catalina & on the Apple Menu there is a Recent Items item that shows the last several Affinity files I have worked on, among others.

Oh yeah, THOSE recent items work fine, the issue is more that if I want a gestalt of recent files in a single finder window, trying to create your own search query based on modification dates etc. tends to pull in a bunch of xml files from ~/Library for every preference that's been updated etc.

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

44 minutes ago, Oufti said:

It looks like something like that happens.

However, since I installed Affinity v.2.6.2 (on Monterey), I'm for the 1st time able to see a list of recent files when I option-click on the Publisher app icon in macOS Dock. It's a pleasant surprise… 

Hmm interesting, right clicking on dock icons to get recent files isn't something I use, but on Ventura I see Publisher and Photo showing previous files, and they're both 2.6.0 still.

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

5 minutes ago, loukash said:

Try https://markzware.com/products/idmarkz. Even the free version is useful for QuickLook, thumbnail preview and some basic content statistics.

Oh I don't need to convert them, I have a VMWare Snow Leopard system set up with my last CS version configured for my legacy workflows. More that I was wondering if the reason my .psd documents show up is because Sketchbook Pro has registered that it can handle them, and whether Affinity apps are missing some step to make their documents known to Spotlight for the Documents category.

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

43 minutes ago, markw said:

It’s not just Affinity documents not showing there for me on Monterey, I have noticed other app specific file types also don’t show up there, for example; ArtRage Vitae and Glyphs, even Numbers which is an Apple app is absent.
It only seems to show common “standard” file types that aren't created and used by just one app.🤔

And yet my SketchUP .skp documents are there, my Quickflow .qfl documents. For me .numbers are found. As are my .psd documents, even though I don't have Photoshop on this system, but I do have applications that can read .psd (Sketchbook Pro). My InDesign documents aren't showing up however, and nothing on my system reads .indd

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

7 hours ago, R C-R said:

Are you talking about the Recent Folders item in Finder's Go menu or something else? If so, as a test, create in (for instance) AD a simple document & save it to the Desktop (which is a folder). Give it an easy to see name like "This is a test" or whatever. Close the document, & check Finder's Go > Recent Folder's list to see if the Desktop folder is listed there. If so, open that folder & look for the saved document. If it is there I think it is working as designed.

No, I'm talking about the Recent category in the Finder Favourites, which is in the sidebar, and also directly in the Go menu. It's a non-user-configurable saved search query, and as far as I can determine seems to be documents in your home directory, and mail attachments, but nothing else in ~/Library.

For some reason, it doesn't seem to consider Affinity files to be Documents... or Images.

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

4 minutes ago, nickbatz said:

I don't know whether this is helpful? (Bad screenshot - I should have included the top part showing that I searched for "goldbird.")

(And I don't know what the locked file is - possibly a recovery file.)

Yeah, that works for me, but the problem is that the Recent category in Finder seems to operate specifically on the Document category, which means none of my Affinity documents show up in it.

[Mac: Affinity documents are not "Documents" for Finder search purposes.]

I'm using macOS Ventura, could anyone else check this for me: None of my Affinity documents show up in the Finder's Recent category, and when I do a file search for Kind:Document, or manually choose Kind > Document in the search criteria dropdowns, no Affinity documents will show up.

I search for ".afpub" in the finder toolbar search window, it will prompt for Kind: Affinity Publisher Document, and find all my afpub documents. But if I then add the search criteria Kind Document, it finds nothing.

So spotlight thinks Affinity files are not "documents".

It thinks my SketchUP files are documents and finds them ok, so what's going on?

[Publisher: Why do ruler measurements not default zero to spine?]

1 minute ago, Old Bruce said:

With the rulers showing you should be able to drag the origin to the centre of the spread. You may be aware of this already, the sad part is there is no way that I know of to have this automatically set for all spreads/pages. Spread after spread.

Yeah, I've been doing that where necessary (actually setting through the Guides... setting, but for my current 120+ page document, it's just baffling me that there's no document-wide setting, and why in the absence of a document-wide setting, spine-zero wasn't the default.

The why of it though... it's that Ghostbusters thing of "You're right Ray, no human would stack books like that."

[Publisher: Why do ruler measurements not default zero to spine?]

I haven't been able to find (searching) a way to set an entire document to use spine as zero for spread measurements, so I'm assuming there isn't one.

I've been doing DTP since 1994 - Pagemaker, Quark, InDesign etc, I've never encountered anyone making a DTP app that doesn't default spine as zero, and doesn't let you change it on a document-wide basis. We measure books from spine for a reason.

So what's the thinking with Affinity having an unchangeable (document-wide) ruler zero as top left of left page of spread?

Unless this is a bug?

[Publisher: How does placed image scaling (down) work, when scaling the document up on export?]

I'm experimenting with Publisher for fixed-layout EPUB publishing, where the goal is to export the entire page layout as a single image, and then build the EPUB by hand in HTML. (yes accessibility issues will be handled, this is to get the rendering engine out of the loop and accommodate multi-formatting to .cbz)

For the moment, say I set my Publisher project at 2400x1600px page size, and I'm placing 46MP TIFF photos on the pages, scaled to fit, if I then choose to export the pages at 4800x3200px for 2x hidpi, does Publisher resample from the source images at export, or will I end up with an interpolated enlargement of that baked-in scaling down from the initial image placement?

Do I end up with:

• 46MP > 4800x3600, or
• 46MP > 2400x1600 > interpolation > 4800x3600

Thanks,

[Stacked palettes disconnecting over time.]

This problem effects all my 2.6.0 Affinity apps.

I have all my palettes out on my second, and third (portrait) displays, they're stacked in long columns - one palette magnetically attached to the bottom of the one above, etc. So you can grab the drag point of the top palette, and the whole column can be moved as a single unit.

I am finding that after a couple of days of sleep / wake cycles etc, the palettes have inevitably disconnected from each other. They're still in roughly the same positions, though they seem to all have randomly changed in dimensions by a couple of pixels.

The only way I can really express this, is the magnetic effect with which the palettes connect just seems unreasonably weak. Affinity's palettes are an order of magnitude less strongly connected to each other, in terms of:

• the eagerness with which they jump to connect
• the amount of time you have to hold them to initiate a break to split them apart

...than any other applications with dockable palettes I've ever used.

I don't know if it's some problem Affinity has coping with sleep / wake cycles (because we know Affinity DOES have a problem coping with display disconnect / reconnect events associated with sleep / wake) that other applications don't have a problem handling, but no other apps I use have their palettes do this fractional resizing thing, and none of them have their docked palettes just disconnect from each other on their own.

I don't know what other information I can provide...

Action: Palettes are docked to each other on secondary screens.

Expected result: they stay connected to each other, and the same size. Dragging the top palette drags all the connected palettes as a group.

Observed result: they change sizes randomly by fractional amounts, which seems to break their connection to each other. Though they remain in roughly the same place on screen, dragging the top palette will reveal it is not connected to any others.

[Publisher 2.6: Extra Large thumbnail size setting not respected on relaunch]

16 minutes ago, MikeTO said:

I'm seeing the same thing in the 2.6.2 beta. It's not just XL - it doesn't remember Small or Medium either, it just reverts to Large when restarting.

I wonder if it's a symptom of the same way it doesn't remember changing the proportional split in the panel between Masters and Pages.

[Publisher 2.6: Extra Large thumbnail size setting not respected on relaunch]

Issue: Setting thumbnails to Extra Large size does not stick through a quit and relaunch.

Expected Behaviour: Set Thumbnail size to Extra Large, quit application. On next launch, thumbnail size retains Extra Large setting.

Observed Behaviour: Thumbnail size reverts to Large Thumbnails, including when relaunching by opening the same document.

MacOS Ventura 13.7.4

Publisher 2.6.0

[Publisher 2.6.0: Swatches > Web Safe Colours. No swatches included.]

9 minutes ago, carl123 said:

@mattspace

@walt uploaded the web safe colour palette here, which imports into Windows via the swatches panel. You might want to try that on your Mac

PS You might end up with 2 of the same categories - just delete the empty one if possible

 

Well that fixed the symptom - I have websafe colour palettes again, and with some renaming and re-exporting I was able to get them to the correct version of English. Much appreciated.

Curious as to why it happened in the first place, however.

[Publisher 2.6.0: Swatches > Web Safe Colours. No swatches included.]

33 minutes ago, Alfred said:

Your screenshot shows that you have one entry for each of ‘Colours’ [UK English spelling], ‘Gradients’ and ‘Greys’ [UK English spelling], but two entries for ‘Web Safe Colors’ [US English spelling]. What are your system and app-specific language settings?

Here's System Settings:

Here's Publisher's settings:

Designer's settings:

Photo's settings:

[Publisher 2.6.0: Swatches > Web Safe Colours. No swatches included.]

5 hours ago, MikeTO said:

Yes, the colours should be listed below. Do you have the same issue in all three apps, if you have the other apps?

You can probably reset the swatches by clearing your user data (start Affinity with Ctrl held down) but that will clear a lot of things so hopefully there's another way to reset these swatches.

In Designer, I have two sets of empty Web Safe Colours:

Photo doesn't have the Web Safe Colours set at all:

Something seems very confused.

[Publisher 2.6.0: Swatches > Web Safe Colours. No swatches included.]

Is this a bug, or "works as intended"?

All the other swatch sets are pre-filled with swatches, but the Web Safe Colours option is completely empty. Surely that should be pre-filled with all the standard web-safe hexcode colours?

macOS Ventura 13.7.4

[Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.]

1 minute ago, R C-R said:

Sorry but to me that explanation neither rings any bells nor makes any sense (as for as it matching Windows). I did look for topics about this but could not find anything other than complaints about the Mac V2 method is quite inferior to the V1 one.

And of course, there is the counter-example of the dock-to-document-window thing to consider.

Great, but I'm over this discussion, as it's strayed off topic & really doesn't matter to the issue at hand - that Publisher doesn't respect the OS settings for scroll behaviour in the document window. Bug report is filed, and we'll see what happens.

[Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.]

1 minute ago, R C-R said:

What do you mean? Windows has its own version of separated mode, so if the reason was to mimic Windows we would still have it

So if you have a link to some topic where they explain the reason for this as you say, can you provide it?

Besides, if it was all working to the Windows standard, then we Mac users would be able to dock multiple studio panels on the left or right like Windows users can do.

I don't remember the specific post, I just recall the explanation given at the time for why separated mode as we had it, where you could have multiple normal document windows, rather than having a special primary window and extra "views" had to go away, was that the Windows version didn't support separated mode the way the Mac version did (which I presume is because Windows generally requires every app to contain all its document windows within a parent root window, whereas macOS is rootless in that regard), and that they wanted to get both version working in an identical fashion.

[Remembering panel positions on different dual monitor configs]

A solution would be to use Studio configurations Window > Studio and manually configure a palette layout etc for each setup you typically use. Then swap to the one you're using when you change your setup.

I use them to recover from Affinity not handling Sleep / Wake correctly in situations where the sleep process has issues, and one of my displays is dropped by the system. The only problem, is the tools palette isn't captured by Studio layouts, so if you use it as a separate floating thing you'll need to move it manually each time.

[Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.]

12 minutes ago, thomaso said:

To get clarification from Serif after all the vague speculation it may be helpful or necessary to file a bug report in the V2 bug forum.

Done.

 

[Publisher: Document viewport scroll behaviour not honouring System settings]

macOS Ventura

Publisher 2.6.0

Setting Settings > Appearance > Click in the scrollbar to: Jump to the spot that's clicked.

Situation: In Publisher, with a long multipage document, scroll to the end of the document, click the scrollbar's track near the top of the document viewport.

Expected behaviour: Scroll handle jumps immediately to the point that is clicked, Document jumps immediately to the point corresponding to the scroll handle's new position.

Observed behaviour: Scroll handle only moves a short distance, corresponding to the document only advancing ~one spread pages in the desired direction, approximating the behaviour of Click in the scroll bar to: Jump to the next page.

Palette scrollbars appear to implement the scroll behaviour correctly for both options.

[Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.]

1 minute ago, RNKLN said:

Affinity products have their own method of indicating a file has changed. They're not following the OS (at least not macOS), which is not good, is my opinion. But, there is an indicator (the asterisk on the right hand side).

Yeah, which strengthens my suspicion that the reason the scrolling behaviour isn't honouring the system-native settings, is the windowing model isn't using system native APIs etc.

[Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.]

9 hours ago, R C-R said:

??? Neither one is standardized to the other. Each one is supposed to use the windowing system provided by the OS. (In fact, initially AD was a Mac-only app & it was only after they developed AP that the Windows versions were offered.)

Again the reason we lost separated mode, is because Windows' window model doesn't support it. That was explained at the time. So Affinity is working to the lowest common denominator.

The other thing is the level of the windowing system supported - you can spawn the window bounds with native calls, but then fill he widgets within with your own home-rolled solutions. That's how Electron apps work.

9 hours ago, R C-R said:

Not sure what you mean. The close button for me is always filled with red. What it should do is get a white dot when there are unsaved changes. That strikes me as yet another bug.

Try setting your system to Accent colour Graphite, and highlight colour Graphite. No filled close button with unsaved changes. Lack of that UI indicator is a common symptom of using a non-native UI toolkit.

*edit* I don't know if it's different for you on macOS Catalina (according to your sig), but on Ventura, regardless of accent colours the close window control is not filled when there are unsaved changes. Tested with TextEdit, and the correct behaviour is observed, so it's an Affinity level issue.