GFS

Thank you anon2! Perfect. Very useful to know about Winding/Alternate and I'd tried a lot of things, but not the Reverse button. Sigh... v_Kyr.. thanks for the pointers. Yes Filemaker is a little fussy about SVG, but it's getting there. The crucial part on Export from AFD, is to uncheck 'Set viewBox' in the 'More' settings, otherwise dimensions are set as percentages and Filemaker doesn't read those. You also have to add some fill attributes after export, in a text editor otherwise the SVG icon doesn't show in the icon selection dialog.

I don't use AFD much, being more an AFP user, but I'm trying to adapt some SVG icons that were made for Filemaker Pro and I can't work out how they were done. What I'm producing in AFD works, but not in Filemaker (which doesn't support all SVG styles). Below is a grab of a simple icon in AFD. The 3 transparent rectangle/areas on the right (green circle) were already part of the icon, but the one on the left (red) I added myself. It seems okay, but once imported into Filemaker, the red circled area on the left, that I made in AFD, is no longer transparent. I can see in AFD that they behave differently when using Add/Subtract, so clearly they are different ... I just don't understand how they are different and therefore, how I can replicate the green circled area on the right. Can anyone enlighten me? I enclose the very simple AFD file, which will be easier to understand (except for me) and also the original SVG that I'm trying to adapt/change. Any help, much appreciated. 😊 FM-icons.AFDesign.zip To_Do_Bar.svg

Thanks for the reply v_Kyr. I've solved my problems and now I can solve yours too. 🙂 The percentage width/height tags are replaced by points, if you deselect the 'Set viewBox' option in the Export dialog's 'More' settings. You can Save your settings via the Manage Presets button in the Export dialog's 'More' settings There was a further hiccup with AFD and Filemaker, in that importing an SVG into its 'button icons dialog' worked, but wasn't showing an icon in the Buttons dialog itself (where you choose the icon you want to use). So very hard to work with the AFD exported icons. This I discovered was due to using a Shape in AFD, instead of Nodes. Nodes give an SVG with Paths, which works perfectly. Shapes give you different SVG code.

I'm lost with code, but would like to know if I can configure AFD's export SVG settings (More) so that my exported SVGs match the settings in this example file? (FWIW, this example works perfectly with Filemaker). Here's the code (opening the SVG in a text editor) and I attach the sample file as well. Does anyone know if/how an SVG can be output from AFD to match these settings? <?xml version="1.0" encoding="utf-8"?> <svg version="1.2" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="50px" height="50px" viewBox="0 0 52.33 52.33"> <path d="M19.833,0L32.5,0 32.5,19.833999 52.334,19.833999 52.334,32.500999 32.5,32.500999 32.5,52.333 19.833,52.333 19.833,32.500999 0,32.500999 0,19.833999 19.833,19.833999z"/> </svg> SVG.zip

I've just had this problem. FWIW, in the Export Dialog, going to 'More' and choosing to convert typefaces to Curves, solves the problem.

Thank you Chris.

Is there any way with the new Metadata panel, to remove the Creator Tool tag? I've tried editing the XMP and importing it, but the Creator Tool isn't replaced. Also wondering if Metadata can be applied via Batch Job?

You might want to dig deeper into the Finder. It is a very powerful database and gives you most of the tools that you are after. For file management organisation: I barely use Folders, because they are totally opposite to what computers do so well. I use Smart Folders (searches), Tags and Comments (keywords). With these three things you have an extremely powerful organisational/management tool. For example ... all of my RAW files just get dumped into Root folders. No traditional Folder organisation whatsoever. Of course, I never ever look at the files this way, because in practical terms, although my files are in a single place, they are equally in multiple places simultaneously... as many as I want in fact, thanks to Smart Folders. Tags: You can make as many Tags as you want and you can give the standard ones keystrokes too so these can be used for rapid rating etc. (You can also rename them). They're also available in all standard Mac dialogs (Serif... who knows why... don't use standard Mac windows, so you can't add Tags via the filename in any Affinity window). Comments: You can batch manage Comments, which perform in exactly the same way as keywords in photo apps, except with the advantage that they do it throughout the entire system instead of just your app. Smart Folders: These are REALLY powerful. They have built-in boolean functions (and/or) and can be used to dig down into some incredibly detailed criteria. They can be visible in every Finder window, or you can put them where you want anywhere on your system. If you combine these 3 things with: Gallery view: which gives you thumbnail/large view and essential EXIF, Rotate and Markup etc. You can zoom into any image preview, even beyond 100%, with 2-finger spread. QuickLook: (Spacebar) which can zoom in and out of images with + - keys. Will scroll PDFs as a single page... just like a webpage and which gives you direct access to Markup, Rotate and video Trim etc. will play and Trim video files, without having to open any app. SlideShow: Access via QuickLook or Contextual Menu (using Option-Key). Full-screen images on dark background... single and multiple. Navigate via keys. Ideal for quick presentations. (QuickLook/SlideShow.. cannot Tag/Comment individually via keyboard... it's applied to all because they are all 'selected') Automator: which is the 'glue' for rapid automation, e.g. batch keywording via Comments, keyboard-command Tagging, Image conversion, Colour-space conversion, Resizing, Sharing, uploading etc. etc. etc. etc. etc. You can add all off these things to the Services menu (2-finger-tap on file/folder/anything) and even give them their own keyboard commands. What you can do with Automator is pretty much limitless, as it can include AppleScript, Terminal commands and SQL, but there is quite a learning curve when you go beyond the basics, although there is a very active online community too. As an example, I have an Automator Service, which will take a folder of images, resize them, convert to sRGB, remove accented characters from their names (I'm in France) and zip them *as individual files* which I can then upload to my ftp server. You can of course, do all of the above in full-screen ... even Dark Mode now, which is better for images and the Finder gives you a wide range of Sort options + the Arrange menu. I've really only touched on the aspects that the majority of users are probably not very familiar with, but there is obviously a lot more to commend this approach, not least the fact that if you are in the Mac environment, then ALL of this stuff is retained across Macs and via iCloud too. It would require a changed mindset for most users, but in my experience, it takes about a month, maybe two, to get used to new ways of working, e.g. using certain Trackpad gestures instead of old habits, or ... I'm currently having another go at Spaces in Catalina, which I haven't tried for a long time ... and I have to say... they're not too bad. (FWIW... I use all the gestures! ). A dedicated DAM like Aperture, will obviously be slicker, but conversely cannot handle any and every file type. I should add that if you move files onto Windows disks, they will loose their Comments (keywords) as the Windows file format doesn't support them.

Thank you Chris B. Can you tell me what the advantages of mipmapping are in this respect? Is it just a question of speed?

And there I was thinking that I could use the iPad to do some work with focus merging ... but .. uhhh ... no! Such a shame, because the AFP focus merging is really fast and extremely good, but unfortunatley, it turns specular highlights into white blobs, so you need the sources panel to be able to remove this messy treatment.

I wonder if this isn't a decision about speed by Serif. I expect that AFP has a pyramid of internal jpegs for display and adjusts on the fly for in-betweens. Blur is slow to calculate and can bring AFP to it's knees in processing ... although this has improved significantly with 1.7x. Perhaps it would be enough to simply offer a checkbox to use 'accurate' previews, when desired. My old favourite imaging app had this waaaayyy back in the mid90s. A simple toggle between speed and accuracy.

Thanks Walt. You're correct.. and there I was thinking that zoom to 100% to see if, e.g. banding is really there, days we're over. Ho hum. *However* This remains an issue. I need to be able to see my entire image on-screen, in order to judge how much blur I want to apply. Zooming in to 100% on a ~100 megapixel image is completely unworkable in this regard. So at the moment, in order to see how much blur I want, I have to make a guess in AFP, Export to tiff, look at that, go back, adjust, Export to tiff, look at that, go back adjust, Export to tiff, look at that ... I think we call this a problem. The AFP preview (on-screen image) needs to be accurate.

I have a gaussian blur layer, which when exported to tiff, is not applied to the same level (amount) as the screen preview in AFP 1.7.3. In order to have the same amount of blur in the exported tiff, I have to increase the blur radius from 0.9 to 3.8px

Hi MEB, thanks for the reply. I couldn't find a Mac beta to use instead, so I had to workaround ... neither of the above 'fixes' actually fixed it for me.

Thanks haakoo. That's just the attitude. Perhaps you work for Serif?? Anyway, I already said goodbye, but seeing as it's my profession, I have to deal with the past as well as the future.

I don't think Serif realise how bad this is ... I stopped using AFP because of the several serious masking issues I reported 2-3 years back. Nothing was done until 1.7, which fixed some of them, but even then, not fully. Yesterday morning I had a client asking for some variations on some images, from back then and I've just spent an hour trying to work out what the heck is going on. I realise that most amateurs don't get into much compositing, but it's crucial to many pros and this is definitely NOT what I would call a professional approach. When I suggested a couple of years back, to one of Serif's forum guys, that he was talking crap, when he said it's normal that a Preview doesn't reflect the result, he reported me for bad behaviour, which I guess was an unfortunate pointer and it doesn't look like anything has improved. I'm fairly annoyed right now, which doesn't seem like the attitude you want to be encouraging. Serif really really really needs to address ALL of these masking issues as quickly as possible.

I think this will depend on whoever and whatever apps, if any, take advantage of MacOS 10.15 giving developers access to the Photos database. We just don't know yet. It hasn't even shipped. (Another month?) Obviously it would be in the interests of any developer to make a transition to their system as simple as possible. I would imagine that Catalogs and Collections would be easy as they're essentially a database question. Adjustments may be harder.

It looks like he's proceeding with the DAM aspects. As for using Managed Libraries in Aperture ... most users didn't understand what this involved, or that Aperture offers the choice of both Managed and Referenced, with a fast and easy way of moving files from one to the other. As any database developer would tell you, the golden rule is to have everything managed, otherwise the risk of damage/loss from things being messed up by human beings remains very real. Aperture's Managed database is very good (and can be read in the Finder if you really want) and continues to be used with Photos. Since the changes to the MacOS file system, with 10.14, all of these assets are much safer, because they are constantly tracked. If Nik Bhatt's RAW Power can tap into the Photos database, as he believes he can, then he should be able to quite feasibly recreate the vital DAM aspects of Aperture. The added bonus, is that Apple's RAW engine is very very good. Edit: (Of course, Serif will also be aware of the changes to the OS coming with 10.15, so they too could quite easily produce a DAM front-end for Affinity ... but it would only be for Mac)

On the Mac, this is called the Finder, although most people wouldn't be aware of how powerful it is.

You may be in luck! Nik Bhatt, ex-lead of Aperture, brought out his excellent RAW Power app a while back. It taps into the MacOS built-in RAW decoding, which is used/maintained for Photos. This is what Aperture uses too, although Aperture can no longer use the current decoding. A couple of weeks ago at Apple's WWDC, Apple announced that they are going to allow developers to access to Photos' database in 10.15 Catalina. This means that apps like RAW Power will be able to use the Photos database, which crucially will allow them to share all that metadata and perhaps the adjustments. So I would imagine, that you will be able to import your files into Photos, but then ... not use Photos ... and instead use something else, with more features and a better UI more suited to pros, like RAW Power. The long and short of it is that Nik could build RAW Power into as good a DAM as Aperture AND it will be able to read your Aperture Libraries (because Photos already can). Did I just make your day? Maybe give him some encouragement ... https://twitter.com/gentcoders https://gentlemencoders.com/raw-power-for-macos/

Thanks for the replies. As you said Walt and R C-R, AFP is respecting the metadata, which is great and my problem was coming from the way that Aperture handles files which are lacking a metadata date. In fact, what it does is it displays the Finder date in the exif date field, but if these files are exported *as originals*, that date is not included, presumably because it is not a part of the original file. So that is as it should be. If you export as a version, then the date is applied, which equally, makes sense. On top of this, it turns out that it's trivial to set the date permanently in the originals, within Aperture. So my problems is solved without any headache ... just a lot of fiddling, checking, searching etc. Also good to see that AFP is handling batch conversion in a useful way.

Thanks again and I should have been more specific about which date, but those still don't answer the question. FWIW and not relevant for much longer, Aperture can batch change EXIF date. So I already have this ability. The question is how to batch convert (or retain in AFP when using Batch Job) the original file date, so that the new file's date matches the old (original) file's date. I have many thousands of these images, so doing them one-by-one would be time consuming.

Thank you for the reply. These don't address the issue though. The question is not how to change a file's date, it is how to retain the date of the original file when batch converting (the exif date ... not the Finder date).

Hi, I'm finally preparing to move away from Aperture, which I still use for its DAM, which remains by far the best, as far as I can see. Sigh. I have several thousand old tiff files, that are unsupported in 64bit (you can test this by starting up in 64bit mode on you Mac). Happily, whilst AFP 1.6.7 choked and crashed horribly trying to batch convert these old .tif files to modern versions, via New Batch Job, AFP 1.7beta cruises through them with much appreciated speed and solidity. So far I have made a >2,000 batch conversion. Problem/Question: Obviously the Batch Job is producing a new Tiff LZW file, which has a new date. Is there any way within AFP that I can set the date to the same as the original file (I can't find anything) or does anyone have any suggestions how I can keep the original file date? I suppose it could be done in the Finder via Applescript, but this is beyond my capabilities. Seems like this is something that could be desirable for quite a few people.

There is a bug with inPainting on a pixel layer. I'm not sure what the problem is, but I'm *guessing* it may be to do with having elements of your file (layers) being outside the canvas area. Anyway ... this fixes it for me: •Group your layer •Copy the Group •From File Menu choose - 'New From Clipboard' •Use Transform to get your Group back to correct position and also resize canvas as necessary •UnGroup (This may fix some other weird stuff too)