fde101

Interesting...
Yes, w/2 works as does w*.5 - I wonder what I messed up earlier when I tried an expression like that there...
 
Thank you!

Tools are on the toolbar on the left.
Properties of tools (such as the type of gradient) are in the context toolbar at the top of the window.
That is consistent and appropriate.

It seems that the tool has two rules:
if a path is closed, offset either outward or inward otherwise the path is open, so offset both outward and inward The first Fill option, "Auto closed", results in the behaviour described above.
The second Fill option, "Force open", results in a closed path being considered as unjoined at end/start and then the open path rule is followed
The third Fill option, "Force closed", results in an open path being considered as having a linear segment joining end to start (as happens in Affinity Boolean operations) and then the closed path rule is followed.

This is really a different category of selection than the other options.  The current set of options work at the object level but this would almost require discontiguous text selection to be implemented first as these are properties of a subset of a text object, rather than an entire object.
I would suggest that if this functionality is needed Find and Replace should be used instead, though that is only available in Publisher - this could easily take the form of a "Find Same Font/Style/..." option which would configure and execute the search to do exactly that as well as displaying the Find & Replace panel if it is hidden, in one step.

The status bar when using this tool says that holding option while using it should clone the object but that doesn't seem to be happening - am I missing something?
Any chance of the contour getting an independent stroke from the main object?  Currently the stroke moves to the contour, which is appropriate, but would be nice to have the option of applying a stroke in two places as a result of this tool...

Serif has often placed milestone releases on sale for a short time upon release (such as the release of Publisher when it first came out) and existing customers are typically notified of those sales.
A 2.0 release might follow that pattern, and customers who jump on it would get the "discount" of the sale pricing?
Just hypothesizing, but it would seem to fit the pattern they have established so far.

Not as such, but something more like the "talk" / "discussion" pages on a media wiki site might be useful as a means by which to provide more targeted feedback to the documentation team, if provided on the online version of the help (affinity.help site)?
That would be sort of "attached" to a help topic but still on a separate page with the interface making it relatively clear that it is out of band with the actual help text...

Not as such, but something more like the "talk" / "discussion" pages on a media wiki site might be useful as a means by which to provide more targeted feedback to the documentation team, if provided on the online version of the help (affinity.help site)?
That would be sort of "attached" to a help topic but still on a separate page with the interface making it relatively clear that it is out of band with the actual help text...

In ID this is handled with a section prefix.

Serif has often placed milestone releases on sale for a short time upon release (such as the release of Publisher when it first came out) and existing customers are typically notified of those sales.
A 2.0 release might follow that pattern, and customers who jump on it would get the "discount" of the sale pricing?
Just hypothesizing, but it would seem to fit the pattern they have established so far.

Serif has often placed milestone releases on sale for a short time upon release (such as the release of Publisher when it first came out) and existing customers are typically notified of those sales.
A 2.0 release might follow that pattern, and customers who jump on it would get the "discount" of the sale pricing?
Just hypothesizing, but it would seem to fit the pattern they have established so far.

@Ceresede
Welcome to the Affinity forums.
Since your comment refers to the interface on iPad I think you should really post to the dedicated iPad suggestions forum here.
Jeff

However, it is unclear if there will be any sort of special discount for 1.x version owners, or by the time the 2.0 versions are released if that would be possible for purchases made through either the Apple or Windows stores.
We can guess that there might be a special sale price for a short time after the initial release, similar to what they have done in the past, but there are no guarantees about that or even what the full retail prices will be.

Missed it by one minute - I just posted about the same thing 🙂
I hid mine to avoid having the duplicate.
Also noticed that the selection bounds around multiple selected objects do not expand to include the contour area which may be mildly confusing sometimes when trying to determine what is selected.

Create a new document in Affinity Photo Add a Perspective Live Filter (should be the only layer in the document) File -> Open in Designer Open or switch to the Assets panel Create a new category or find an appropriate one Select the live filter in the Layers panel In the hamburger menu for the subcategory, Add from Selection Rename the asset subcategory to "Perspective" Now, to add a Perspective live filter to a document from within Affinity designer, simply drag it out from the Assets panel onto the document then adjust its position in the Layers panel appropriately.

This is really a different category of selection than the other options.  The current set of options work at the object level but this would almost require discontiguous text selection to be implemented first as these are properties of a subset of a text object, rather than an entire object.
I would suggest that if this functionality is needed Find and Replace should be used instead, though that is only available in Publisher - this could easily take the form of a "Find Same Font/Style/..." option which would configure and execute the search to do exactly that as well as displaying the Find & Replace panel if it is hidden, in one step.

This is really a different category of selection than the other options.  The current set of options work at the object level but this would almost require discontiguous text selection to be implemented first as these are properties of a subset of a text object, rather than an entire object.
I would suggest that if this functionality is needed Find and Replace should be used instead, though that is only available in Publisher - this could easily take the form of a "Find Same Font/Style/..." option which would configure and execute the search to do exactly that as well as displaying the Find & Replace panel if it is hidden, in one step.

By definition that would not be "pass-through" any longer.
 
PDF looks like gibberish unless it is interpreted.  Here is an example of a portion of an uninterpreted PDF file:
 
 
Whether it is interpreted by code from Serif, Apple, Micro$oft, Adobe, or whoever, at some level it must be interpreted to be meaningful to a human observer.  So yes, it is quite obviously by design that the PDF is "interpreted" when displayed on the screen - that should not be in question.
The question is one of the interpretation of the PDF being sufficiently incomplete that not all elements (such as embedded fonts) being handled in the manner prescribed by the format.  Because the Affinity software only interprets a subset of the PDF standard and that subset does not cover the features being used by the file, other things get left out and the resulting image does not reflect the expectations of users.  It is in effect an approximation of what the PDF is intended to look like... but then, so are all other on-screen renderings of a PDF file as they are all raster by the time they are displayed and raster representations of vector objects are approximations by nature; it is really a matter of some approximations being better than others.

On the Mac you could always consider using Apple's APIs to render the embedded PDF data as it is native to the graphics system.  That obviously won't help Windows users, but you could still use the previews when they are available and fall back on what you are doing now when they are not?

This seems like a rather curious decision...

On the Mac you could always consider using Apple's APIs to render the embedded PDF data as it is native to the graphics system.  That obviously won't help Windows users, but you could still use the previews when they are available and fall back on what you are doing now when they are not?

Hypothesizing here:
The "ti" combination would commonly produce a ligature of some sort.  When the PDF file was written chances are the ligature was given a single code point which happens to map to that particular variant of the letter "e" in whatever encoding the PDF claimed to be in.  If the font was embedded with the document the ligature could have simply been substituted for an unused code point and would have rendered correctly (which is the true purpose of a PDF file - to look good as-is, not to be easy to edit; it is "digital paper" not a proper editing format), but when imported into the Affinity product, which does not use the embedded font, it would have read it as the "e" character and used that instead of the ligature that was encoded in the PDF?
Note that this form of substitution would make sense if it allows the application to use a single-byte encoding for the text instead of a multi-byte one, as this in theory saves space and reduces the size of the PDF file with no impact to its visual appearance - again, the primary purpose of a PDF file which is not produced for reasons of accessibility or searching.  My guess is that if you opened that PDF in Preview / Acrobat Reader / some other PDF viewer with search capability and tried searching for one of the words that has "ti" in it, it probably wouldn't come up in the search either.

It does that already.
 
Currently it does select from hidden groups, locked groups and hidden locked groups.
 
This doesn't seem to be available at present.
 
Select Same -> Fill Color does work on gradients, including those with different angles but otherwise matching.  If you "Reverse" one of the gradients (using the Reverse button on the gradient editor) it won't find it, but rotating it all the way around still allows it to be matched.
 
Select Same -> Shape effectively does this.

It does that already.
 
Currently it does select from hidden groups, locked groups and hidden locked groups.
 
This doesn't seem to be available at present.
 
Select Same -> Fill Color does work on gradients, including those with different angles but otherwise matching.  If you "Reverse" one of the gradients (using the Reverse button on the gradient editor) it won't find it, but rotating it all the way around still allows it to be matched.
 
Select Same -> Shape effectively does this.

It does that already.
 
Currently it does select from hidden groups, locked groups and hidden locked groups.
 
This doesn't seem to be available at present.
 
Select Same -> Fill Color does work on gradients, including those with different angles but otherwise matching.  If you "Reverse" one of the gradients (using the Reverse button on the gradient editor) it won't find it, but rotating it all the way around still allows it to be matched.
 
Select Same -> Shape effectively does this.