fde101

Just to verify, are both documents configured with the same color space and profile?
If they have different color profiles set up then the conversion makes sense as the colors would need to be adapted to the new profile.  Otherwise, I agree that should not be happening.

I've seen this as well and I believe it is intentional.
Photo is optimized for working on raster images in which there is typically a "background" pixel layer.  As the output format of such a document will generally be a raster image as well, I suspect the vector objects are being rendered to match the underlying resolution of the document as this is a truer reflection of the state of what is hypothetically a raster document.

Not when replying specifically to an individual unless you make it clear that it refers to a wider group. Especially when highlighting that their use is not the same as a universal use. If you had meant a wider group you would or, perhaps, should have said.
Is this really going to become a debate about semantics?

What problem would that be?
 
By this do you mean ignoring the values provided by the font and using an arbitrary number that is unlikely to have anything to do with reality?

Hi petrpastor,
Welcome to Affinity Forums
We do take community feedback seriously but it doesn't mean we can fulfil all requests as soon/fast as people would like - even in two years. Affinity Publisher is on its infancy. There's still various areas that need some work (integration with the other two apps, file presets/templates, linked/embedded file management, PDF import/export improvements, preflight etc (besides bugs to fix) until we can add more features. As explained several times we have limited resources compared to other known companies and are also developing a design/vector application and RAW developer/photo editing app at the same time for three different platforms alongside with Publisher, not Publisher alone. All this requires time. I think the teams have achieved quite a lot considering some years ago there was nothing at all. Please bear with us. 

If Serif does choose to provide preset presets for the preflight panel, I think it would be best if they would stick with presets that fit well-defined standards in the print industry rather than cater to all of the oddball requirements that individual users are likely to come up with.
If the presets can be imported/exported, then print shops could provide presets matching their requirements so their users could download them and add them to Publisher if they want to.
 
Agreed 100%.

If Serif does choose to provide preset presets for the preflight panel, I think it would be best if they would stick with presets that fit well-defined standards in the print industry rather than cater to all of the oddball requirements that individual users are likely to come up with.
If the presets can be imported/exported, then print shops could provide presets matching their requirements so their users could download them and add them to Publisher if they want to.
 
Agreed 100%.

What is the rationale behind this design?  It obviously is not a bug if it was designed this way but it is a rather questionable design choice...

If Serif does choose to provide preset presets for the preflight panel, I think it would be best if they would stick with presets that fit well-defined standards in the print industry rather than cater to all of the oddball requirements that individual users are likely to come up with.
If the presets can be imported/exported, then print shops could provide presets matching their requirements so their users could download them and add them to Publisher if they want to.
 
Agreed 100%.

True, but I'm not sure we need Serif to provide a complex set of Presets.
I think it's more important for them to provide the checks, and a small set of Presets. Individual users can create their own to fit their unique situations.

Tossing this one out there for discussion: poor contrast (luma or chroma) between overlapping vector objects, optionally accounting for various forms of colorblindness?

They generally do not respond to feature requests, but they actually did respond to this one a few times:
 
etc.

The problem is that this is a lie as soon as it is printed on the page.

The problem is that this is a lie as soon as it is printed on the page.

You can also use the export persona to configure a png (or other format) and set up a "live" export as you modify the native file, and keep that next to the main file if desired.

72 DPI is the pixel resolution of the display on the original Macintosh from 1984, and for a long time has been the default "assumed" display resolution across many platforms.
More recently, particularly with the introduction of the so-called "retina" and "hi-dpi" technologies, graphics/windowing systems are starting to become a bit smarter about the actual DPI of a given display, or at least something much closer to it...
 
Much higher resolutions are required for printing - 300 DPI for photo-quality prints for example - and since the Affinity products, Publisher in particular, seem to be targeting the print industry primarily, wouldn't it make a bit more sense to target the 300 DPI resolution as a default?
 
Note that even the display on a typical modern iPad is well over 200 DPI...

For those who did not catch this, it was already mentioned in another thread somewhere that an upcoming beta for 1.8 will be adding a preflight panel of some sort.  No details yet on what might be included on the panel.

What problem would that be?
 
By this do you mean ignoring the values provided by the font and using an arbitrary number that is unlikely to have anything to do with reality?

These are features of DAM or RAW development software, not of photo editors.  Serif has already indicated they are working on producing a DAM solution as part of the Affinity lineup, but it will be a separate application from Photo.
I would expect this functionality to be part of that program and would not expect to see it added to Photo.
There is no information currently available about the timeframe in which that new program is expected to be ready.

Yes, control not shift - will fix the post above.

Ctrl?

They do, but they only show the centre of the page if it is portrait orientation, its ok so far for the couple I have set up so far but it would be better if they could be dynamic and show both orientations

No it wasn't.
PDF does not support linked files and was never intended as an editing format.  It is meant as "paper in a file" but with smaller sizes and the ability to scale and search.
The fact that it has been commonly misused as an editable interchange format does not make that part of its intended function, it just means that the format is being commonly used for functions it was never actually designed for.

No it wasn't.
PDF does not support linked files and was never intended as an editing format.  It is meant as "paper in a file" but with smaller sizes and the ability to scale and search.
The fact that it has been commonly misused as an editable interchange format does not make that part of its intended function, it just means that the format is being commonly used for functions it was never actually designed for.

(Sorry, there is no need to let us know what you do NOT know.)