fde101

To a point... the catch is that this would need to be set up for each file rather than something integrated into the document format itself. Maybe a "save documents with large previews" option in preferences wouldn't be too bad of a thing to offer, but I definitely wouldn't want a "full size" preview of large documents saved in every file... Meanwhile, this at least does exist.

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.

If you haven't already, you might want to post about this on the Windows bug forum and not just here. You could link back to this one. It should get attention from the right people a bit faster that way.

A full-size preview will also require full-size disk space, will take the full-size export time whenever saving the document, and this is in addition to the space already occupied by the file. The Affinity team has already indicated that they designed the file format to optimize the speed of file operations, and this would not only contradict that purpose, but would also waste even more disk space where there are already people complaining that the files are sometimes too large. I for one specifically do NOT want this. Larger than 500 x 500 I could possibly live with, but the full resolution of my 20+ MPix camera? No. The size of the file is not constant either, and neither is the size of the suggested png "wrapper" - as a png file's size can vary even with the resolution being fixed, each time the file was saved there is the potential that the Affinity data might need to move within the file to accommodate changes to the size of the wrapper. The files are not likely being rewritten in their entirety each time the document is saved, so this is potentially a much bigger change to the file format than you seem to realize.

Based on some of the hints I've seen from reading between the lines of some of the various issues and the like that have been identified related to the Affinity document file format, I don't think this would be as simple as you seem to think. The Affinity document format seems to be structured more like a database file than a traditional document structure, and that might not play nicely with a tagged format like the ones you suggest, as the files might be updated constantly while they are open, not just when you explicitly save the document.

I'm sure it is a priority, just not as high a priority as some would like when compared to other things that people are also crying out loud for. Right now the second major release (1.8 up from the first 1.7 release) is in beta, and they are still adding features to the betas, so it's not like they have let this slip for a long time now either in the grand scheme of things. They won't get it all in at once so they need to pick and choose. I think it's too soon for you to make the assumption that this is particularly low on the totem pole, but I would expect that this is much easier to work around than some of the other problems people are seeing and it may be prioritized accordingly.

My vote (only pretending that I actually have one) is for the current behavior when manipulating the layers on the Layers panel to be retained, but for the image to be matched to the boundaries of the old image (adjusted by some method X for a difference in aspect ratio) when replacing one by dragging into the frame from outside the application, when pasting an image from the clipboard, or when explicitly using the "place" feature. I think that probably makes the most sense from a user perspective in most cases? Maybe have a preference to instead center the new image on the boundaries of the old one and match the placed DPI instead of the boundaries...

In InDesign, the picture and the frame are most likely the same "object" as they are in QuarkXPress, so in that context the positioning of the image would be intertwined with the concept of the frame. Publisher is different in that the image and the frame are two separate objects represented as two separate layers on the Layers panel. You can drag an image layer out of its frame and the position is retained, which implies that the position of the image is not a property of the frame, but of the actual image layer. You can similarly drag an image layer into a frame from within the Layers panel. Different program, different design, different behavior. Having said all of that, it is not unreasonable to request that when replacing an image within a frame Publisher adapt the properties of the incoming image to those of the one that it is replacing within the frame (as I would expect it to do if the frame is set to scale to fit or scale to fill)... but that doesn't change the very likely probability that the scale and position of a manually placed/sized image is a property of the image and not of the frame. They are two different layers and each layer in the products has its own size and position; there is no reason why these would be any different.

I think that depends on whether using a setting that automatically scales to fit the frame, vs. a manual scale. If the original image was scaled or positioned manually that could be a different story from one that is set to scale to fit or fill the frame. If the image is manually scaled/positioned, then its scale/position is that of the image layer which is separate from the frame itself, so if you are replacing that layer it makes sense that the position and scale of the old layer would not carry over. It might not be the most optimal behavior, but it might not be a bug either.

True. However, the file format being shared with Photo places the Affinity suite in a somewhat unique position of benefiting from having this set (for the benefit of documents that are then opened in Photo), even though it technically should make little or no difference to the operation of Publisher, except when rasterizing a layer. Agreed, as long as the IDML has such images. If importing an IDML file with no images at all, the program still needs *something* to default to. Also, depending on how images are scaled, the maximum placed or "original" DPI of any embedded images might not be the most appropriate either.

This is largely a result of the Affinity products not currently having an equivalent to the "Adobe Paragraph Composer". This has been requested on various other threads and Serif does not seem to be prioritizing this at the moment, so it is unclear if or when this particular limitation of the product will be addressed.

I believe those are considered properties of the image rather than of the frame. When you replace the image, it is a different image so those properties no longer apply... they were replaced along with the old image.

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...

You can change many of the keyboard shortcuts in Preferences -> Keyboard Shortcuts.

This is in a section of the forum for discussing Affinity Designer and should have been in the section on Publisher. That said, there are already a number of threads discussing this, predominantly this one:

I see what is happening now. You quoted one bullet point of his process and then responded to the topic/post as a whole. I was interpreting the response in terms of the quoted bullet point instead. Yes, I agree that in general, it is better to produce a PDF to send to a printer rather than packaging the Publisher file along with the separated resources. However, if someone is packaging the source documents for whatever reason, then PDF does not solve the specific "gotchas" related to the specific point of that process which you quoted from.

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?

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.

I think this was taken from InDesign? In any case, they are addressing this (keyboard shortcuts) in version 1.8 which is currently in beta.

For that perhaps, but that is not how I am reading the post that you quoted as being responded to. The expressed concerns were related to linked files and PDF as a delivery format is not relevant to that topic.

The "picture control" sounds like it is just the presets for contrast, saturation and the like that most cameras have in their menus for processed JPEGs and such? In that case, while it is unlikely that the Affinity products will include the exact presets that the camera offers, you could get similar effects by manually adjusting the various settings yourself via adjustment layers, or by applying LUTs, free examples of which can be found floating around various web sites, or available for purchase in various collections all over the place.

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.

Affinity Photo doesn't support file import/export plugins at this time, so it would need to be done by Serif and integrated into the product, at least unless/until that changes.

Sure it is... if they are not listed together, but the window puts both of them in the same list. It would not come across very well if one of them used big icons and the other one had a simple list when both of them are in the same list. You also suggested making the list narrower to make more room for the settings on the right, but if the templates continue to be shown as icons, you will wind up with very little space to show the templates in a narrowed list - again, not a problem if they are not listed together, but Serif opted to include both in the list at the same time.

The window covers both and your proposed changes cannot be considered for one in isolation of the other.