John49

Old Bruce, thanks for your suggestion - it would indeed be a solution, especially if I applied it to the Section naming and numbering. However, for my document, I consider it to be too much like hard work and could prove a bit awkward to maintain, particularly in the case of adding extra pages to sections throughout the evolution of the document. For now, I'll just use the standard page numbering in the page footers and the Section naming (but not section page numbering) in the headers. This way, ToCs and Indexes will work fine and the user will at least be able tell what section they are in (if not exactly where in the section) when randomly opening the finished book. Perhaps the Affinity development team could consider my earlier suggestion, or some other method to allow numbering of section pages differently from the running document page numbering.

I have a different but related problem. I'd like to have separate document page numbers and Section page numbers. For instance, assume I have a 100 page document and I want to add a page number field in the page footer. This number would therefore go from 1 to 100. Now, assume that this document, for the sake of easy explanation, has 10 sections, each of 10 pages. In the document header I want to put the section name and section page number. So, document pages 1 to 10 would be Section 1 pages 1 to 10, document pages 11 to 20 would be Section 2 pages 1 to 10, and so on. The problem seems to be that there is only one field designator for page number: the hash symbol #. In the appropriate document master, I placed the hash symbol in a text box at the bottom of the document. This, unsurprisingly, worked fine! However, back on the master, I placed <Section Name> # in a text box at the top of the page. Once I created some sections and specified numbering to start from 1 for each one, I saw that the section names and section page numbers were working fine. BUT the page numbers at the bottom of the page were now reflecting the section page numbers at the top rather than the running document page numbers. Also, because I started each section with a Heading 1 style, every entry in my ToC was pointing to Page 1! I didn't create an Index, but I am assuming that the same issue as with the ToC would exist. There clearly is a field somewhere in Publisher that contains the document page number - this can be seen in the Section Manager panel (see attachment). It would be good to be able to access this together with an "offset" or "Start numbering on Page..." option in case the user wants to skip a couple of leading blank pages before numbering starts. Obviously ToCs and Indexes would need to read this value to avoid the "which of the ten Page 4s do you want" problem!

I have already seen and tried "shift-click on flow icon" and think it's great for heavily text oriented content, where the text box occupies the bulk of the page. However, it does have some significant limitations in other circumstances: I created a facing page layout, placed a small text box on the left hand side of the left page and a picture frame on the right hand side of the right page. (Sure, it's not a particularly realistic layout, but it does serve to illustrate the point). I then pasted a chunk of text into the text box and then shift-clicked the flow icon. The image below shows the result: no text box appeared on the first right hand page, even though there was room for it; the text boxes are created in a mirrored layout - not unreasonable considering a facing page layout was chosen. But, what if I did want a text box on the first right hand page along with the image? What if I always wanted the text box on the left hand side of the page? It's all fixable of course - it just takes a good bit longer. As I said in my earlier post, the best feature with templates is being able to quickly change something globally throughout the document - a tweak only to the appropriate template and the job's done. Remember the very earliest word-processing software before "search and replace" was properly implemented?! Maybe what I'm requesting is unreasonable. I'm not a developer, so maybe don't understand that highly customisable templates might need very complex coding that bloats the software or makes it run unacceptably slowly. Still, requests and comments have been requested.... :-) Again, a big shout out to the Affinity team. I'm very impressed with the Mac versions of Designer and Photo and absolutely blown away by the iPad implementations of both.

Picture frames suffer from the same issues. You can create a master containing them and apply it to a page, but the frame loses all functionality and cannot be resized/moved. I'd like the ability to build masters with text boxes having defined text styles and flows, together with picture/photo frames. Obviously you'd only spend time doing this if you knew you were going to need multiple occurrences of those layouts, but doesn't that make the case for having this ability even more valid? Once you've finished the draft of your document and, inevitably, wonder if it might look better slightly increasing the photo size and changing the text from 3 to 2 columns, you're rather more likely to try it knowing that you need do it only once if you're using a master rather than having to do it 50 times for each occurrence of that layout! Otherwise, Affinity Publisher is looking very promising. Keep up the good work, guys!

You're quite right. My normal workflow is to dump my NEFs on to my Synology NAS, process them in Affinity, then output JPG versions to Apple Photos. Trying to stack the NEFs imported from my NAS causes a crash, as you reported. It's the first time I tried a stack. Importing NEFs in this way for panoramas ("New Panorama" in Affinity) works fine so I (wrongly!) assumed that all would be ok with stacks.

Agree that stacking uses JPG and not RAW. Regarding importing though, I've successfully imported 3 x 25MB .NEF files using "New Stack" without a problem (although as mentioned earlier it seems it's the JPG part of the file that's imported, despite the RAW files being selected for import). I'm using a 64GB iPad Air 2 with Affinity Photo for iPad 1.6.3 and iOS 11 beta 5.

Krist - the latest version of Affinity Photo for iPad (1.6.3) together with the latest iOS release (10.3.3) renders the workarounds unnecessary - RAW photos (.NEF in my case) imported into Apple Photos via the Lightning SD Card Reader are now "seen" by Affinity Photo for iPad and are opened directly in the Develop persona. Thanks again to the Affinity team for quickly resolving this issue.

The ability to import RAW files into Affinity from Photos is, in my opinion, of huge importance. It is obviously doable as several apps from other software houses demonstrate. Another alternative, although possibly more difficult, would be to import the RAW files directly from the SD card/USB/camera dongles when plugged into the Lightning port. Now that iOS 11 has been released to developers, it is an ideal opportunity for the Affinity developers to address this issue and also ensure tight integration with the new "Files" app. Come on guys - you have a good product that could be made great with a few comparatively minor tweaks. Is there a companion DAM app on the horizon??

PhotoNewbie: I don't have Affinity Photo yet so can't comment on that, but RD provides a way of moving RAW images imported into Photos (via USB/card reader adapter) to iCloud Drive, from where it can be loaded into Affinity.

Oops! Peter has already suggested a workaround using Readdle Documents. As he says, Readdle will not display the RAWs but will at least transfer them to iCloud. It's a bit messy, but at least it provides a way of getting the job done when all you have is an iPad.

The RAW import issue is of critical importance to me - I always shoot RAW and up to now have been using Lr to import and process RAW files. I'm considering dumping my ageing laptop and moving to iPad Pro only as it is now powerful enough and has sufficient memory to handle all my requirements. Affinity Photo for iPad has all the functionality I would need, unlike Lr mobile. The upcoming iOS 11 has a "Files" app, but at this time it's not clear whether it will allow file transfer from the iPad card reader/USB dongles direct to iCloud, or whether all files with RAW/jpg extensions will be forced through the Photos app. If Affinity does read RAW files imported into the Photos app, then I have no problem and will likely buy it straight away, but there seems to be some doubt whether this is the case or whether it is just the embedded jpg that Affinity reads (see James' post). Would it be possible for an Affinity developer to provide a definitive answer? If the answer is jpg only, then I would suggest that fixing this should be first priority for Serif! Alternatively, does anyone have a workaround?