spamjim

Here is 4 pixels per inch compared to 4 dots per inch.
Pixels are the entire area and a shade of grey. Dots vary in size and are solid Black. We are talking about apples and similar apples here. Any printer will tell you he would rather have a 400 PPI image to downsample to 300 or 240 or 85 DPI for printing (because customers complain about the product when they supply 85 PPI images to be printed at 85 DPI). 

Oh dear oh dear oh dear, the article is erroneous on so many points.  The designer has absolutely NO control over DPI, this is the domain of the Printer only, we have no control,  a printer printing your photo or design at 600 DPI can have  the same quality as if the printer would print it at 4800 DPI.  We work in pixels not in dots, even home printers have different DPI but that is no concern nor does it matter, 400 DPI is redundant at the point of final design, since the printer can print that at 4800 DPI. The article has confused DPI with PPI.  And I have seen this a few times.  Colour management professionals will never subscribe to the DPI conundrum because DPI has nothing to do with what is sent to a printer.  Your print at 300 PPI, which is encoded within the software as PPI NOT DPI, is then translated and printed at a DPI resolution, 600 DPI can produce exactly the same quality image or design as a 4800 DPI Print in many cases dependent upon the quality of the work.   Besides if one must insist on using DPI nstead of PPI then 400 is pointless since 360 is the absolute maximum in todays technology.  Having anymore than 360 PPI (or DPI if you wish to call it that) does not produce any improvement in visual quality at all.
Respectfully yours
Chris

Hi Chris26,
Welcome to Affinity Forums
This was already brought up quite a few times in several threads. Check this article in Affinity Spotlight to learn why it's labelled like this in Affinity apps.

I feel I ought to apologise because I know that some will think this pedantic nonsense, but there is no escaping a simple reality - DPI is not the same as PPI, and it does not belong in any dialogue box.  The world is awash with confusion over this.  Designers, publishers, photo editing, ALL need to know PPI.  The only people that need to use DPI are the print shops and printing presses.  DPI has no place in any software in Affinity, or anywhere in the desktop publishing office or suite.  I await thine fury!..............(but I can prove it if you so must)
 
PS, the dialogue box should really range from about 90 then 180 then 260 300 360 and stop there.  360 being the absolute maximum.  No quality improvement is available or visible after 360.

Importing INDD requires that Publisher has the stable features to replicate what ID does. This is why you're not going to see INDD/IDML/INX import immediately.

While this is contrary to the concept of a master page, it is a feature in another page layout app, and designers like to break templates all the time... It would be helpful to be able to selectively unlock/override a master page element from an individual page.
 
 

You're welcome to check my words by following the steps I describe.
Lighten up. There's no need for that kind of silliness.
I cannot imagine why you'd be cranky with my post when I explicitly state that what you want is likely possible if the developers take it a small step further.

Joachim_L, I'm not reporting a problem.  I'm saying that Publisher appears to handle this function better than InDesign.
Michail, to restore a master page, you can still "apply master..." to any page where you have edited detached master page elements. However, in the way that Publisher is detaching master page elements, it does not seem like it would be too much trouble for developers to allow the ability to restore individual elements instead of resetting the entire master page design.
 

There's no need to carelessly classify another as an "apologist" to diminish their credibility and recognition of the reality. Nobody can expect to effectively import ID design data if you don't have the Affinity features ready yet to support features coming from ID.
If you're old enough, look back to the advent of ID. It had a very crude PM and QXD importer. ID users most often had to recreate their legacy documents. ID has never had a QXD importer beyond version QuarkXPress 4 and the PM imports (from Adobe's own software) have always been garbage. Adobe had huge resources to develop importers with ID1 (and all subsequent releases) but still did not live up to our current expectations of Affinity.
As you know, each page layout developer intentionally limits the interchange of their documents. We recognize this as "vendor lock in". Instead of blaming developers for not being able to read/import, we can blame ourselves for choosing a proprietary format.

Importing INDD requires that Publisher has the stable features to replicate what ID does. This is why you're not going to see INDD/IDML/INX import immediately.

Agreed.
A workaround for now is to create a multi-column text frame on a master page. Drag guides from the rulers to align with the text frame's columns. Delete the text frame.

Importing INDD requires that Publisher has the stable features to replicate what ID does. This is why you're not going to see INDD/IDML/INX import immediately.

Importing INDD requires that Publisher has the stable features to replicate what ID does. This is why you're not going to see INDD/IDML/INX import immediately.

When using a text frame as a guide to draw page columns, you can adjust the gutter (gap between columns) under View -> Studio ->Text Frame.
 

Agreed.
A workaround for now is to create a multi-column text frame on a master page. Drag guides from the rulers to align with the text frame's columns. Delete the text frame.

Love the beta of Publisher. Only thing I still am a bit annoyed with is setting guides, because they have to be set manually by distance (percentage or millimeter) rather than to add on X number of guides and have them evenly spaced from either margins or the page.
May I suggest a checkbox in the Guides manager?

[x] Space guides evenly
And radio button for
Align guides to (x)Margin ( )Page
It would make it a breeze without having to do math.

I may have missed something, but it would be incredibly helpful if the snapping options recognized column boundaries as snap targets. I think this is something that should definitely be in the 1.0 release.
Also, a grid feature for layout grids with not only support for just vertical divisions for columns, but also horizontal rows would be fantastic. It should be possible to use different grid options per spread or master page.
Ideally, there would also be an option to also rotate this grid at an angle and have rectangular text frames, shapes, images etc. be created and transformed and snapped at that angle to make layouts with slightly rotated content really easy without the need to place nested documents (and all the ugly workarounds that come with that like duplicated styles).