lepr

It's made clear by a red diagonal line across the thumbnail of a disabled Mask/Adjustment in the collapsed row. At least that happens in the apps on macOS.

Hi all,
This is indeed a known issue, so I can only say we hope to fix it soon.
Lee

Same here, but being an option for three is much better than no option at all.

You have the Extended Dynamic Range option enabled in the 32-bit Preview panel when the brightest part of the sky looks orange rather than yellow.
That option is enabling the display of R, G or B values that are greater than the range that can be encoded in a JPEG export or a screenshot, which are standard dynamic range formats.
In the case of your HDR sky, all G and B values are not greater than 1.0 (equivalent to 255 in an integer 8 bits per channel image), and so they get exported intact to a standard dynamic range image. Some R values also are not greater than 1.0, and these get exported intact to a SDR image. However many R values are greater than 1.0 and get clipped when exported to a SDR image, hence the diminished redness (a shift from orange to yellow) of the brightest part of the sky in the JPEG export and screenshot
Disable the Extended Dynamic Range option in the 32-bit Preview panel to display only the standard dynamic range that is exportable in a JPEG (or a screenshot).

You have the Extended Dynamic Range option enabled in the 32-bit Preview panel when the brightest part of the sky looks orange rather than yellow.
That option is enabling the display of R, G or B values that are greater than the range that can be encoded in a JPEG export or a screenshot, which are standard dynamic range formats.
In the case of your HDR sky, all G and B values are not greater than 1.0 (equivalent to 255 in an integer 8 bits per channel image), and so they get exported intact to a standard dynamic range image. Some R values also are not greater than 1.0, and these get exported intact to a SDR image. However many R values are greater than 1.0 and get clipped when exported to a SDR image, hence the diminished redness (a shift from orange to yellow) of the brightest part of the sky in the JPEG export and screenshot
Disable the Extended Dynamic Range option in the 32-bit Preview panel to display only the standard dynamic range that is exportable in a JPEG (or a screenshot).

It's a display problem that has always been in the app. When a pixel selection is at edges of the canvas, you'll see the ants appear/disappear from different edges as the zoom level is adjusted.

Then its a platform difference on iPad 
(I know this thread is in the Desktop section)

Don't do a Boolean operation unless you actually want to destructively modify the selected object(s).
Instead, simply press the period key to toggle between 'base box' and 'regular bounds'.

It would be great to be able to select multiple junction points of a mesh warp and have a "Transform Mode" option similar to Node Tool to rotate or scale them as a box.
We have something something approaching with the Twist or FishEye presets, but the proposed Transform mode would be more flexible and allow multiple transformation on the same mesh. 

The preview shows what you'll get if you choose New Layer With Mask for the output, instead of just Mask.

Yes. One way is to use the Channels panel to transfer the lightness of each monochrome image to the respective L, A and B channels of a new Pixel object.
Place the three monochrome images into a LAB document and use Rasterise command to convert them to Pixel objects. Name the Pixel objects "L", "A" and "B" (without the double quotes). Run the attached macro which will generate a composite Pixel object named "LAB". L, A & B to LAB.afmacro

C, M, Y & K to CMYK.afmacro

C, M, Y & K to CMYK.afmacro

Yes. One way is to use the Channels panel to transfer the lightness of each monochrome image to the respective L, A and B channels of a new Pixel object.
Place the three monochrome images into a LAB document and use Rasterise command to convert them to Pixel objects. Name the Pixel objects "L", "A" and "B" (without the double quotes). Run the attached macro which will generate a composite Pixel object named "LAB". L, A & B to LAB.afmacro

Yes- different platforms are likely to have subtly different fonts.  They may have the same name, but might be produced differently.  As I stated before - the specific error with failure to perform the bool op is down to edge case calculations as a result of possibly only one or two curves in the font glyphs. This will be rectified in 2.1.

You certainly could be right about results differing because of the difference between font versions on Windows versus macOS, rather than differences in the Affinity code on each platform.
 
There is no "Divide (Compound)" command. I guess you are talking about alt/opt-clicking the Divide button in the toolbar, similar to alt/opt-clicking the Add/Subtract/Intersect/Xor buttons to create a Compound.
Alt/opt-clicking Divide does not produce a Compound. The alt/opt key is a modifier for Divide when one or more unfilled curves are in the collection of operands. The key is used when you want the fragments of unfilled curves to be kept, otherwise they are discarded.
When filled text is an operand in a Boolean operation, the text is first wrongly converted to unfilled curves instead of filled curves (a persistent bug for several  years now), and then the Boolean operation proceeds. Hence, the difference you were getting by doing a simple Divide with filled text versus an alt/opt-Divide with filled text. You were effectively dividing with unfilled curves when dividing with filled text.
 

Same here. I've only seen the problems happen in the macOS apps if a file contains curves converted from text by the Windows software. My inexpert suspicion is something is crucially different about the output of the text-to-curves code in the macOS apps versus Windows apps.

Yes, that's how AD1, AD2 and APub1 work, but APub2 is broken.
APub2 currently always maintains the pixels dimensions and changes the physical dimensions when PPI is changed, regardless of the document units being pixels or physical. APub2 currently does not allow the user to maintain the document's physical dimensions when changing PPI. It seems illogical for that loss of functionality to be a design decision of the developers, therefore it's most likely a bug.
As I said earlier, AD and APub do not resample Pixel objects when the document's pixels dimensions change, therefore there is no "document crippling" and no reason to mention resampling. Instead, these apps nondestructively scale Pixel objects when the document's pixels dimensions change. Only Photo destructively resamples Pixel objects when the document's pixels dimensions change, and there is a Resample checkbox in Photo.

Thanks! I'll take a look later today and come back to the thread.

Here are more comprehensive test files attached, and some notes on results after performing Boolean operations:
a) On Windows v1 (just as a reference):
Red color indicates shapes that were left invisible after operation (not really an issue) The two elements Boolean operated on each artboard are from top to bottom: frame text + rectangle, art text + rectangle, frame text converted to curves and merged + rectangle converted to curve, and art text converted to a curves and merged + rectangle converted to a curve Subtract simple fails when performed on frame and art text, but works if text is first converted to curves and merged; subtract compound works fine Intersect simple fails when performed on text (all objects lost) Xor simple has issues Divide simple has issues when performed on text objects, works fine if text objects are converted to curves and merged; Divide compound fails to divide any objects
b) On Windows v2:
Subtract simple still fails on operations involving frame text, or former frame text converted to curves and merged Xor has issues with frame text and former frame text converted to curves and merged Divide works fine only with art text converted to curves and merged
c) On macOS v2, when opening a file where text objects have been converted to.curves and merged on Windows:
There are issues in Subtract, Xor and Divide when operating with frame text converted to curves and merged Divide simple fails with text objects 
d) On macOS v2, when text objects have been converted to curves and merged on mac:
There are still issues with divide simple when operating with text objects. Divide compound works fine.
What is strange is that the results are clearly dependent on the font that is used. The font in this test file was Arial. The differences between Windows and macOS might be dependent already on different versions of Arial these OSs have (the Windows version is much more complex and has e.g. OpenType fractions). Just using Arial Bold instead of Regular gives different results and gives similar or identical results on Windows (v2), compared to macOS:

In light of this, there is hope that this could be just a minor glitch, more related to specific feature in the font than the actual glyph shapes. If so, then it seems that the major issues that are left with Boolean operations are related to Divide simple involving text objects (on both platforms).
I might have done mistakes, so here are the test files I used:
boolean_regular_v02_before_from_win.afdesign (created on Windows and having versions of texts converted to curves and merged on Windows) 
boolean_regular_v02_before.afdesign (having versions of text objects converted to curves and merged on mac, so using diffrent version of Arial)

Selecting a Layer never directly selects the member objects. It is sufficient for changing the fill and stroke of members of the Layer because the app has been coded to propagate such changes to the members of the Layer.
In the first reply of the thread, Walt told you how to quickly select all members of a Layer: 
with Edit All Layers disabled, select a Layer (or a member of the Layer) then press cmd+A (ctrl+A on Windows)
 
Edit: anto has posted good videos now

If you apply fill colour, stroke colour and other stroke attributes to the Layer, these properties will be propagated to the members of the Layer, and the Layer will remember the properties.
Next time you select the Layer, the remembered properties will be displayed in the Colour and Stroke panels (although you may have changed the appearance of individual members in the meantime). You can apply a new appearance to the Layer and that will be remembered and propagated to the members, as before.
The same is true for Group objects.

Hopefully, the following will make clear what is working and broken (red text) in the 3 apps.
Versions 1 & 2 of Publisher and Designer (in Document Setup window)
Broken in Publisher 2 only - to maintain document physical dimensions when changing PPI: set document units to physical then change PPI To maintain document pixels dimensions when changing PPI: set document units to pixels then change PPI Versions 1 & 2 of Photo (in Resize Document window)
To maintain document physical dimensions when changing PPI: ignore document units, enable Resample then change PPI To maintain document pixels dimensions when changing PPI: ignore document units, disable Resample then change PPI

You're looking at the help for Photo, but this thread is concerned with broken functionality in Publisher.
A Resample checkbox is appropriate for Photo because that app destructively resamples Pixel objects when the document's size measured in pixels is scaled.
A Resample checkbox would be inappropriate for Publisher (and Designer) because these apps non-destructively scale Pixel objects when the document's size measured in pixels is scaled.
 

I have been enjoying doing cad-like work in Designer for a long while now, but being more into CAD design by promoting it for such work, I have been using it more for my work with laser cutting now. It would be incredibly helpful if there was at least first a basic set of variables that can be placed into generic number field (width, height, corner radius, etc etc) so that a single variable can have a ton of fixes. This would be helpful for cases like, the thickness across dozens of parts needs to be adjusted, or a part needs to be extended so 1 variable would adjust multiple parts.

A second update to this that would make it even better, it to be able to apply these variable length constraints to vertex pairs in shapes, so shapes themselves would alter based on those variables. 
 
Something incredibly similar, but more basic, already exists in Designer - and it's called pallets. Change one color, and everywhere it is used changes.