fde101

Yes. I’m also inclined to support that. Otherwise we’ll be perpetuating a practice that doesn’t seem to in accordance with the specification, as I would understand it. Indeed, what Walt said about the use of U+202F in French typesetting is already in the standard.
Unicode-Spaces.pdf

But that can be accomplished by the user (or the program) using a Narrow Non-Breaking Space in that context and others that need it.
If Thin Space is always non-breaking, then how does someone who wants it to be able to break accomplish that? (In other words, there's a broken/missing function if Thin Space is non-breaking.)
It might be more appropriate for Affinity to convert thin spaces to narrow non-breaking spaces when importing DOCX or IDML files, and leaving Thin Spaces working as they're defined (breaking), if you want compatibility with Word and InDesign.
 

I use FontBase to keep the Google fonts installed and updated.  I checked and the Quicksand fonts that it has installed for me are working perfectly.

No, but Rasterize & Trim is.  You would only use it on the pixel layer(s) that were cropped.

Native Affinity documents have been known to become corrupted while working on them if they are stored using one of the "sync" services such as Dropbox or iCloud and you try to open them from there, but I would not expect that particular issue with a more traditional network drive mounted via a protocol such as CIFS (SMB) or AFS.
However, given the potential for multiple users to be accessing a file at the same time, it would be necessary for an application to implement appropriate file locking to make this safe depending on how those files are used.  I have long suspected based on the behavior and previous reports related to the Affinity document format that the file may be actively modified while the application is open.  If there are not appropriate locks in place and you attempt to share those documents in realtime, they could possibly still become corrupted.
As the recommendation from Serif continues to be working on a local drive, I would not place confidence in that locking.
Furthermore, the way that file locks work can vary between platforms, and as Windows-style file locking (CIFS/SMB) can be quite different in its semantics than native Mac-style file locking, even if the appropriate locks are in place for native use on the desktop, there is a possibility they may not translate accurately over the network share - this has been a problem in the past even when interconnecting different UNIX systems - so I would not be surprised if the issues were directly related to the manner in which you are attempting to share these resources.
Placing standard image files (TIFF/PNG/JPEG) and the like on the network drive should not be an issue, but I would be very careful if attempting to do this with native Affinity document formats until such time as Serif can harden its use of the file semantics to ensure that it is safe to work this way.
 
If you really feel it is necessary to continue working in this manner, and you are all on Macs, consider trying this over a native AFS share rather than a CIFS (SMB) share, as that should provide native Mac file locking semantics.  It might be instructive as to whether or not you can reproduce the issue under that environment...  but even then I would advise caution.

If you happen to be on a Mac, you can access the Apple Color Picker from the View menu, and HSB sliders are available from there.

This is largely a result of the Affinity products not currently having an equivalent to the "Adobe Paragraph Composer".  This has been requested on various other threads and Serif does not seem to be prioritizing this at the moment, so it is unclear if or when this particular limitation of the product will be addressed.

Storing the gradient settings for a pixel layer makes no sense, considering that as soon as you use a brush on it, altering those settings would overwrite the brush stroke.
Doing nonsensical things for the sake of usability is more of a hinderance than a help.

The Desired Letter Spacing is in % on Windows, not px.

I've noticed that too. I'm logging this as we speak. Thanks.

@MEB, in your example, the ellipses at the top level are still showing a cascade triangle but have no associated menu.  I tried with a pair of rectangles and if I click on one of those, everything gets deselected - it does not select an object from the first level of menu.
Is that intentional or a bug?
 
It definitely feels like a bug.

Consider as an alternative setting up an automatic live export in the Export persona and keeping a separate PNG or JPG (or TIFF if really necessary - PNG is much smaller and still recognized by most everything; JPG is lossy but if that is your final output format anyway then you already have it when you are done?) next to your .afphoto file?
That way you have a separate preview file which gets updated automatically as you work, you retain all of the settings by using the native format, and I have generally found that the native format loads and saves much faster than using PSD (or likely TIFF) as trying to work with those formats directly will generally be treated as an import/export behind the scenes every time you try to load or save, meaning that the software is converting the file back and forth every time you try to use it anyway.

Only filter (‘effects’) plugins are compatible. Other types such as acquisition, automation and file format plugins cannot be used in Affinity Photo.

Most of the time when people are asking for the "hex color input" they are looking for something they can copy/paste into HTML/CSS code for use on the web, and that would need to be RGB.
To make sure we are clearly interpreting what you are asking for, are you looking for the actual HSL values to be encoded as HSL in hexadecimal format (which would be compatible with nothing), or are you asking for the RGB values to be encoded as hexadecimal and displayed on the tab along with the HSL color wheel (to be able to transfer values back and forth with HTML/CSS)?

No one? I have not not felt any need to trim pixels outside canvas. When I export the image they are gone. No problem.

They might need to go with a system similar to the way the swatches work: there would need to be both application or document style categories, and within document categories have the option of making "global styles" that would retain their links back to the definition.
 
That said, I think we need to go a step past this.  Consider how Item Styles are defined in QuarkXPress: practically every attribute of the style has a checkbox to indicate if it is present in the style or not:

In contrast, the current Styles in the Affinity products are all-or-nothing.  I think the entire Style system in the Affinity products needs to be revamped, replaced, or supplemented with a new type of Style which allows for more precise definition, expansion into additional areas (such as specific position/size attributes), and permits the option of having styles at the document level which maintain links to the objects they are applied to.
 
One place that it could take a step beyond QuarkXPress would be to retain links from multiple styles applied to a single object.  In QuarkXPress, if I have an item style set up that sets the horizontal position and size of an object, and another that sets its border (stroke) color and width, then I can apply both to an object, and because the attributes do not overlap it will obtain both sets of properties, but only the last one I applied to it remains linked to the object - if I update both of those styles, only one of them gets updated for the object.  It would be better for the application to remember which styles were applied to the object in what order, and go back and re-apply any changes made to the styles in that same order.
 
I would also like to point out that there could potentially be the option of reusing some of the underlying implementation of symbols in providing this functionality, depending on how it is actually set up under the hood.

They might need to go with a system similar to the way the swatches work: there would need to be both application or document style categories, and within document categories have the option of making "global styles" that would retain their links back to the definition.
 
That said, I think we need to go a step past this.  Consider how Item Styles are defined in QuarkXPress: practically every attribute of the style has a checkbox to indicate if it is present in the style or not:

In contrast, the current Styles in the Affinity products are all-or-nothing.  I think the entire Style system in the Affinity products needs to be revamped, replaced, or supplemented with a new type of Style which allows for more precise definition, expansion into additional areas (such as specific position/size attributes), and permits the option of having styles at the document level which maintain links to the objects they are applied to.
 
One place that it could take a step beyond QuarkXPress would be to retain links from multiple styles applied to a single object.  In QuarkXPress, if I have an item style set up that sets the horizontal position and size of an object, and another that sets its border (stroke) color and width, then I can apply both to an object, and because the attributes do not overlap it will obtain both sets of properties, but only the last one I applied to it remains linked to the object - if I update both of those styles, only one of them gets updated for the object.  It would be better for the application to remember which styles were applied to the object in what order, and go back and re-apply any changes made to the styles in that same order.
 
I would also like to point out that there could potentially be the option of reusing some of the underlying implementation of symbols in providing this functionality, depending on how it is actually set up under the hood.

OpenCL driver support on Windows is inconsistent and probably shouldn't be relied upon.
OpenCV is a computer vision library, not a compute acceleration API, so that isn't really in the same category as the others.
CUDA is proprietary to Nvidia and best avoided as it would not work on GPUs from other companies.
So no, you only really have one GPU compute API on Windows too, or at least only one that can be reasonably expected to be available and usable on the majority of systems.
There are wrapper implementations which implement Vulkan on the Mac over top of Metal - meaning that it doesn't really offer anything that you can't do with Metal, so Vulkan on Windows doesn't really have any technical benefit here compared to Metal on the Mac.  It is at best a draw.

Most GUI toolkits (I haven't really looked at the current Windoze APIs but I'm assuming this is still the case for those) will include flags with both mouse and keyboard events indicating which modifier keys were held down when that event took place.
This means that when a mouse button down event is received (for example), the event will indicate that when the mouse button was pressed down, some mix of the shift, control, and alt keys (for Windows - it would be shift, control, option and command on the Mac) were held down.
They won't say anything about the tab key.
 
Technically it should be possible to track this separately within the application itself, but it's a lot more work to keep track of, the application would need to figure out when to skip processing of whatever else the tab key might be doing, would need to deal with key repeat events, etc...  it's a bit more complicated to "reuse" a typing key than you might expect, particularly when setting up a modifier that might be used when editing text at the same time?
 
You would also need to deal with the OS intercepting combinations such as ALT+TAB, meaning that various combinations of modifiers would not work at all...

In the Affinity products they are separate layers, which complicates things from that perspective as depending on what the OP is really after it may be something that has no direct equivalent in the Affinity products or something which would need to be handled quite differently.
If this is in fact what the OP is after, what would probably be the closest possible equivalent in the Affinity products (something that also does not currently seem to exist) would be a "New Layer Containing Selected" command which works like the Group command, but embedding the selected layers inside a Layer layer (the naming of these could use a bit of work) rather than a Group layer.
Currently you can do the equivalent of that by using the Group command to group the objects and then choose Promote Group to Layer from the Layer menu to convert the Group layer to a Layer layer, so two commands instead of one...  Group has a keyboard shortcut (Command+G on the Mac), and you could assign one to Promote Group to Layer from within Preferences if that would help.

Thanks for the video @nitro912gr 

This behaviour was changed in 1.8 and is now expected behaviour.
If you have an object selected in an Artboard - then the Marquee tool will only select the contents of that Artboard. With no object selected you can select anything from any Artboard. If you disable 'Edit All Layers' (the paper stack icon - under your Layers Panel) - it will ALWAYS restrict your Marquee selection to the selected Artboard / object inside the Artboard.
Hehe that made me laugh that you strayed here @fde101 must have missed the warning signs and strayed from the path.

I see the same happening on 1.8.3 on the Mac.
Not sure if it is correct behavior or not, as I indicated earlier it doesn't really bother me either way.
Also not sure how I ended up on a Windows bug thread as I don't normally stray into this part of the forum, but in any case this apparently is not OS-specific.

There is a light color scheme available within Preferences, but I would suggest you try adjusting the "UI Gamma" setting first to see if you can find a better contrast level without going quite that far.
Neutral gray as the bulk of the interface is critical for professional applications that deal with image-related manipulation.  Having colorful elements in the UI can throw off the user's perception of the colors within the document itself and be the cause of errors in the results.