fde101

Serif does not normally respond to feature requests. Sometimes, but not usually. They do read them. https://en.wikipedia.org/wiki/Blend_modes#Divide It is apparently just what the name implies: take the corresponding pixel values of the two layers and divide one by the other.

the teh hte eth het eht

NOTE: most of the below material was for Designer but in general Publisher works the same way... https://affinity.help/designer/en-US.lproj/index.html?page=pages/Layers/LayerMasks.html?title=Layer masking https://www.frankentoon.com/post/complex-masking-in-affinity-designer

Bleed is not considered part of the intended content of the document, but is rather for the benefit of the printing process. Since the whole point of embedding a document is to show the content of one document inside of another, it kind of makes sense that the bleed would be hidden by default, since you would be positioning the document somewhere on the page and making the bleed visible in the document would in effect make something visible in the finished work that was not considered to be something that was intended to be seen.

Unfortunately, this is normal behavior. It is not a bug, but it is annoying at times. I would suggest trying to arrange your panels in such a way that the change in size does not cause a significant impact to the way you work. This could stand to be improved.

Subtract that component's contribution from the contribution coming from other channels?

???

They are controlled with a checkbox in Guides Manager. https://affinity.help/designer/en-US.lproj/index.html?page=pages/DesignAids/guides.html?title=Ruler and column guides

There are two text tools: the "frame text" tool has an icon which is a shape with a "T" in it, and the "artistic text" tool (which I think is what you are looking for here) has the icon with an "A". They occupy the same position among the tools in Photo so you need to press and hold the mouse button on the icon for either one for a moment and a menu should pop up allowing selection of the other one. Also, make sure you are in the Photo persona and not the Develop persona (or other persona) as the text tools are only in the Photo persona. Those are the leftmost icons on the main toolbar (the Photo persona has the same icon as the application itself). If neither one is there, then the information @Arceom provided on how to customize the tools may be relevant.

Picture frames are a feature of Publisher, not Designer.

Maybe another option would be to have a "construction mode" feature that dropped an outline of the existing object as a construction object perfectly positioned at its current location, once construction mode is back in the mix? Then you would be snapping to the construction object instead of to a ghost...

The concept of using a sidecar file or database is so foreign to the design of Affinity Photo that I would be very surprised if the developers ever wasted their time on trying to incorporate such a feature into Photo. Sidecar/database is not the same thing as "non-destructive" and is almost certainly a better fit for the separate DAM software that Serif has indicated they are working on behind the scenes. Photo simply is not the correct application for that... a non-destructive option yes, but sidecar/database no.

The gradient tool in Photo is primarily a vector tool that is intended to be used with the shapes and with paths made using the pen tool. It is actually called the "Fill" tool in Designer and in Publisher even though it can also be applied to the stroke of a shape as well. I think what you are looking for is a different tool, but this one does make perfect sense in the context of modifying the appearance of vector shapes.

Good catch... and no, I think you are correct. I still suspect Publisher is doing the imposition before the page limits are applied. Maybe this needs to change - perhaps the range in the "Range and Scale" section should be done before imposition, and the range in the "Layout" area after? In any case, I do think there is a bug in the current behavior of how the page range is being selected when imposition is being done. Thanks, that matches what I thought you were getting. This might be better handled through the "print persona" that has previously been requested/discussed on the forums?

I take it from this that you are a Windows user... we have an extra modifier key on the Mac so we don't need those. Just a thought... I do agree that key assignments would be nice to have for a bunch of things that are not in the menus.

Limiting the range of pages is handled by the OS, while the imposition is being done by the application. As a result, the page range limitation is likely being applied after the (book in this case) is being imposed - it is organizing ALL of the pages of the book, then only printing a limited set of the imposed pages. However, there is also some rather obvious confusion in how the two features are interacting. With the "book" mode for example, if printing all of 8 pages, you would get two sheets of output: the first would have pages 1-4 organized as 4/1 on one side and 2/3 on the other, while the second would have pages 5-8 organized as 8/5 on one side and 6/7 on the other. The preview does indeed show the 5/8 combination, suggesting that the imposition happened on the entire document rather than on the range of pages, then only a subset of the resulting, already-imposed pages was selected for printing. Note that after imposition there are only four pages (two sheets times two sides), so asking for a range of 4-7 should in effect give only the fourth "page" but for some reason you seem to be getting four pages anyway. The OS and the imposition feature of the application seem to be in disagreement here, so I do think there is a bug here somewhere, but I don't think it is the one you seem to be reporting (explained below). Working on the assumption that imposition is happening first, the pages available to the OS should be 4/1, 2/3, 8/5 and 6/7. You are getting four pages (two sheets) with one being blank, and it sounds like 2/3 were replaced with a blank page and the pages got jumbled within the printing mechanism: it looks like instead of 4/1 with 2/3 and 8/5 paired with 6/7, you somehow ended up with 4/1 paired with 8/5 and 6/7 paired with blank/blank, and that you are trying to assemble the pages like a booklet instead of the book that was selected. In this case, you would have 4/1 forming the front and back, open that and on the inside of that is the 8/5 page, but with the 6/7 page inserted inside of it (7 being the "front" of the inside page) you get the ordering that you indicated. I think you are expecting the imposition to happen to the range of pages you are providing, but the printing system doesn't work that way. Instead, Publisher is imposing the entire document as a book, then the OS is only printing part of what is already imposed. In this situation, after imposition, the OS should have only seen four pages available to print, but it is still trying to grab four pages from the application, resulting in the range being applied in a somewhat unexpected manner. The pages are paired correctly for each side of the page, but it almost looks like it is taking the range of 4-7 and getting page four (6/7), then adding a blank page to the end to account for the fact that there is no page 5 (giving the 6/7 paired with blank/blank), then for whatever reason wrapping around to the beginning of the document and giving 4/1, but skipping 2/3 and giving 8/5 on the back of 4/1? Not sure how that "logic" is working, but I think the fact that you can select pages after page 4 for printing after the book is imposed is the actual bug here.

The Affinity applications do not get along well with the "cloud" storage providers. They expect exclusive access to their document files while they are open. Best practice is to make a local copy that is NOT in a cloud storage area, modify that copy, and copy it back after having closed it within the Affinity application where you are editing it. I would not expect a database application to get along well with this type of storage, and I suspect there are aspects of the way these applications interact with their document files that are similar to the way databases work - I get the impression they are actually modifying the document files while you work, and if the document changes from underneath them, they no longer have the information needed to continue functioning, so they have no choice but to discard the document as the complete state is not maintained in memory? (This commentary is based on observing the behavior of the apps, not on any inside knowledge of the file format). As an aside, four hours between saves is WAY too long... I strongly advise that you save your work more frequently no matter what application you are using!

Getting back on topic... Just to be clear, raster pattern fills already exist. It is vector pattern fills that people are still asking for. This sounds like a bug that should be fixed. It would be nice to have this feature added, along with an option to "expand" an embedded document in place, replacing it with a group of the contained objects. No, layer effects have an effect on the layer itself, but the blend options control how the layer is combined with other layers. They are two different things. Mask layers in Photo do seem to have a rather strange set of limitations that shouldn't be necessary. I agree that there is a lot of room for improvement here.

I'll take the allegedly "inconsistent" default behavior over your supposedly "consistent" behavior any day of the week. It reduces the amount of effort to getting good results, and that is more important for a professional application than the relatively short addition to the learning curve. What you are describing is only superficially consistent: it is useless in this context. It creates more work for the user. Thus your theoretical "consistency" creates an inconsistent amount of work in order to achieve the desired end effect. The existing default behavior provides greater practical consistency in that it evens out the amount of effort involved. Two different perspectives. You are looking for a more consistent learning curve for people who are not as serious about actually using the program. I am looking for a more consistent level of usability for people who are actually trying to get work done with the program.

That's my point: they do behave the same way by default. They all default to the most commonly useful behavior, and require a modifier for the less commonly useful behavior.

That depends on your perspective. If I am resizing a rectangle I am more likely to want to resize without it being constrained. If I am resizing an image I am more likely to want it to resize with the constraint. It is actually quite consistent in that it defaults to the behavior I am more likely to want to use for the type of object I have selected. This is a professional application, and this "inconsistency" adds convenience and helps to reduce how often I would need to use a modifier to get the behavior I am more likely to be looking for.

Open Photo (not within Publisher - run it separately), quit both applications, re-open Publisher, and try again. You need to run Photo once before starting Publisher so that Publisher will recognize that Photo is present.

As you pointed out, the entire feature is new. There is plenty of room for it to grow and improve, such as adding offsets to the individual strokes, adding fx to the list, etc...

Given that the interest seems to be in midpoint and existing edges, and these are basically requests to move either horizontally or vertically by 50% or 100%, would it perhaps be a bit simpler to provide menu options to "Move Up 50% of Height", "Move Left 50% of Width", etc., so that keyboard shortcuts could be assigned? A set of "move by 50%" arrow buttons could be added to the Transform panel too, perhaps swapped with the anchor point selector (have "tab" type buttons underneath to indicate if the anchor point or the arrows should be shown)...