R C-R

A major drawback to making separate forums is there is considerable overlap in the tools, features, & code base of the two apps. Many things apply equally well to both apps on both platforms. This ranges from fundamental concepts like layers, masks, & Personas to features like UI customization, the vector shape tools, snapping, grids & guides, & almost everything regarding text handling.
 
In fact, since both apps on both platforms share the same native file format, it is possible to open & edit an afdesign file created on Windows in Affinity Photo on a Mac, an afphoto file created on a Mac in Affinity Designer running on Windows, & so on.
 
So among other things this means that some bugs will be common to all four apps, some to one platform but not the other, & some to just one app but on both platforms. It also means that many of the techniques discussed & assistance offered here will be useful regardless of which app or platform people are using.

I believe the correct terminology in the computer industry is "real soon now," delivered with tongue firmly in cheek.  :lol:
 
On a slightly more serious note, as rmar mentioned the Mac versions of the Affinity apps seem to run faster than the Windows ones. This is most likely not because Mac hardware is somehow superior but because there are far fewer Mac hardware configurations than Windows ones the software needs to be optimized for. The developers have said they are working on improving Windows performance, but because of that, if it was me for now I would stick with a Windows system that used 'mainstream' Intel hardware from one of the major PC vendors.

Because the Affinity apps are designed to be very memory efficient there is much less need to page data out to VM than you might think, particularly in comparison to memory hogs like PhotoShop.

Oval, I am pretty sure I know what I was commenting on.  :lol:

Different web browsers running on different OS's may display images using the image's embedded color profile (if they have one) or ignore that & use a default profile for everything. Likewise, there is no guarantee an embedded profile will survive the copy & paste step.
 
So, while there is no way to guarantee every image seen on a web page will display the same colors for everyone, it is generally better to download the image to a file on your system & open that in AP (or whatever graphics app you are using).

Yes, the software names should be less easy to mistake as generic terms. Affinity should follow Apple's example.
 
After all, who could be confused if you referred to Contacts, Photos, Calendar, Dictionary, Messages, or Mail?  :lol:

For future reference, downloading & printing out the attachment to this post may help ...  :lol:

Without seeing an example, I am not sure why no blue bar would appear, assuming (as per the other discussion) the contents of the category/subcategory are disclosed.
 
As for the sizing thing, it just seems to be something users have to decide for themselves. So for example, if you think you will typically use an asset at a specific size, then resize it in the workspace to that size (or copy it to a new document & resize it there) before adding it to your assets.
 
For example, I created a subcategory of cartoon face parts (eyes, mouths, etc.) but later discovered that one of the mouths was about ten times larger than all the others. So I opened a new document, added that mouth to it & resized it to match the others. Then I deleted the too-large version & replaced it with the resized one.

Hi, JokerMartini.
 
I am curious about what other shapes you would like to see in Affinity Photo (or Affinity Designer).
 
Personally, I would like to see a spiral tool added to the collection of 'smart' parametrically adjustable tools like the stars, polygon, etc. It would be really cool if it could produce all or most of the 2D spirals listed in the Wikipedia Spiral article, but I would settle for an Archimedean spiral tool. The spiral is one of the few shapes that is very difficult to create currently in Affinity, & I think a tool to create them would be useful for a lot of users.
 
The only other shape that I sometimes would like to create that is similarly hard to do in Affinity is the coil shape, like the electronic schematic symbol for an inductor or transformer winding, but I don't know if a tool for that would be useful for very many users. I guess more generally coils like that are members of the helix family of 3D shapes, projected onto two dimensions, so possibly the tool could be useful for creating screw thread shapes & the like.

reglico, thanks for the clarification. I was just worried that I had missed some feature in AD or I needed to reset/reinstall the app to find it. In English it is indeed "Expand Stroke."
 
I rarely use it because it too often creates a large number of unnecessary nodes. Instead, for filling a line with a bitmap, I use the (deceptively named) Fill tool. It works for strokes as well as fills -- on the Context toolbar the first item is "Context:" & that gives you the choice of applying a fill type to the stroke and/or to the fill separately. It is easy to overlook the stroke choice because it always defaults to "Fill."

Xara's feather will be a bitmap upon export. But in the application it is infinitely scalable. No different than certain effects in AD.
 
Negative form -- Negative space -- Empty space are all the same thing.

To you there is not. To me there is. Perhaps it is best to leave it at that & move on to other topics.

Hmmm. On my iMac the icon consists of four horizontal lines (& is displayed that way in the help topics as well). So it is symbolically either a cheeseburger or a double-meat patty hamburger or some such.

A_B_C, no need to feel sorry about your comment. It is far from the most obvious thing in the UI!
 
Besides, to be honest about it, I had never even used the Text Styles panel until it was mentioned in this topic (& I finally understood what was being discussed)! If not for that, I never would have read the help topics or been aware of the style options or experimented with them.
 
That is the primary reason I participate here -- there is always something new for me to learn. So I am grateful to all who commented about this.

Well, you can do that. If you don't want to apply paragraph styles to characters, don't. It's fine if you don't need the extra flexibility. As far as I can tell, the only downside for you is that when defining a Character style you are shown some paragraph formatting options that you don't want to use. Just ignore them.

Actually, you can. In the Text Styles panel, click on the 'hamburger' menu icon for the paragraph style. The second item is "Apply {style name} To Characters."

I am in no way a perfectionist. The point of my experiments just to compare how long it would take to get reasonably good results using an existing, affordable auto-trace app vs. manual tracing. My conclusion was that these "quick & dirty" solutions are considerably more dirty & far less quick that they have been touted to be, so while they may have some limited value in a few usage scenarios, they are far from ideal for most work. That is in large part because they are still based on the same algorithms developed 20+ years ago, with a few bells & whistles like color capabilities tacked on to make them seem more modern.
 
So yes, Affinity could probably add a similar quick & dirty auto-tracing feature to Designer without too much difficulty, but it likely would be a disappointment to most of the user base. Besides, since the development team is small & there are already a lot of yet to be implemented features on the roadmap, I would much rather see them concentrate on that, which I believe would add much more value than a "me too" implementation of something that is already available for free or at little cost from other sources.

American,
 
I suggested checking out the build-in help because you said the videos were too fast for you and hard to follow. The help topics allow you to browse through their contents at whatever pace you feel comfortable with. Since the Affinity range is brand new code, unrelated to Serif's older Windows products, there are many differences not just in the terminology but also in what tools are provided, how they work, & the various UI options available. The help topics provide a simple, straightforward way to become familiar with the differences.

For complete info see the built-in Help topic "Vector content defaults" but basically, you select an art or frame text object, set it to the font & font attributes you want & on the Edit menu > Defaults, select Save. Do this separately for the two types of text objects. Also works for vector objects.

It may seem basic to you but there is nothing straightforward or simple about the actual process.
 
Consider what this involves: the app has to analyze all the pixels of the source file & determine what represent edges that should be converted to vector paths. In a document with millions of pixels, many of which will have almost but not quite the same colors, some sort of algorithmic threshold to determine where an edge transitions occur must be established -- if every group of pixels of the same exact color was converted to a filled path, the result could be the creation of tens of thousands of tiny vector shapes.
 
For the same reason, some sort of area based path smoothing algorithm needs to be used to reduce the number of nodes per shape to a reasonable number.
 
If either algorithm's threshold is set too high, accuracy will suffer; if too low, enormous files will be generated that will be hard to edit. Ideally, all the algorithms would be adaptive & interactive, somehow modeling human vision closely enough to determine area by area when creation of more nodes & shapes would not produce any perceptible visual improvements.
 
This is kind of optimization is not easy even for high contrast pixel line art; for a typical photograph with thousands of low contrast edge transitions it would be a formidable task, particularly if the conversion process is required to complete in a reasonable amount of time on more than the most powerful systems available.

I've covered this subject so many times already.
 
The *= notation is used to say "multiple the current real value by a given number".  It is significantly different to just writing "* 2" at the end of the existing text as the text will be showing a rounded value.  So, "3.5" might have actually been 3.510024, but has been rounded for display.  If you type "3.5 * 2" you will get 7, not 7.020048.
 
You can also use "w * 2", which uses the real value for "w"... which in the case of the Transform tab will be the current width.  The *= notation means you don't need to worry about what the variable name is.
 
You can actually type "*2" or "/2" into any box and it will do multiplication with the current real value.  This was a compromise for * and / only.  It does not work for + or - though.  As has been said, using the += notation is important, as +2 will not work as relative addition, but result in a literal value of "2".

I mentioned this once before but since this is what it does, for clarity why isn't it called the Hue Replacement Brush???

It may seem counter-intuitive but a rasterize image file does not have any specific physical size. Yes, it has a specific amount of pixels, but those pixels have no specific physical size of their own. So for example, they could be rendered on a computer display at 0.1 x 0.1 mm per pixel or at 100 cm x 100 cm per pixel, or at any other size.
 
To change the amount of pixels, you can resample the image, but as explained in this video tutorial for Photoshop or this one for Affinity Photo, this is related to but not the same thing as changing its DPI setting, which specifies the default physical size of a print made from the image file.

That is why I am in the habit of using explicit forms like w+32 or w*32. I just wish that worked everywhere, like in the Resize Document or Canvas windows, as well as in the Transform panel, where it does work.
 
While I am on the subject, I have noticed that dragging on a field name to change its field value, which I find very useful in the Transform panel, does not honor the height/width ratio lock when dragging on the w: or h: field names. It also does not respond to the alt/option key being held down to reduce the increment like when using the scroll wheel with the pointer hovered over the field value to change the value, which also honors the lock.
 
Basically, I would just like everything to be consistent for all numeric entry fields.