Medical Officer Bones

That printer of yours has fed you complete rubbish: the "Include Appearance" has nothing to do whatsoever with colour management. Instead, it has to do with including items such as buttons and movie posters in the PDF. If you need correct colours, the first thing to get right is to colour manage your workflow. And that means calibrating your screen(s) with a device such as a Spyder. Go from there. You did colour calibrate your screen(s), correct?

There were a couple of very simple reasons why Quark lost its pole position. Remember that Quark ruled the world of DTP at the time, but lost it in only a couple of years. A good article on this can be read here: https://arstechnica.com/information-technology/2014/01/quarkxpress-the-demise-of-a-design-desk-darling/ From a personal point of view: Quark was an absolutely horrible company to deal with. I taught the program at the time, and EVERYONE, EVERY SINGLE student and company I spoke and worked with complained bitterly about their experiences with that company. They were haughty as heck as a company. "Memento Mori": a fundamental truth which was entirely lost on Quark back then. Not anymore, though: they seem to have learned a very harsh lesson.

Check out what this guy is doing in Blender 2.8: https://twitter.com/tauri_34

I think you are missing the point I made: as you say, PDF is meant as a (final) export file format. As such, all the original structure and organization of the original file is lost, and while having the option to import PDF is great (in particular for singular pages and designs), the Publisher developers seem to treat PDF as a sort of intermediate format that they assume can be made to work as a viable alternative such as IDML: a true intermediate format that retains the structure for the most part. And IDML is the only existing candidate file format which is already used as an intermediate DTP file format by various layout software, if perhaps mostly for import. What I am saying here is that IDML is really the only viable option, even if it is an Adobe format, because it is an open standard and relatively easy to support. PDF can never work as an intermediate format for longer complex layout documents. Not if the user intends to heavily modify them. That is why I view Affinity Publisher and PhotoLine (which has supported the import of entire PDF documents for editing in a similar way) as capable PDF editors, but not as editors which can work with PDF-based structured documents. That is just not possible. And that is aside from all the other issues which I listed in the earlier post. Try editing a table after importing it via PDF. Here is a question for you: would you prefer a PSD or a PDF of the same layered file to work with? Most users will probably opt for the PSD, because it retains the structure of the original. More, it IS the original. PSD import and export is supported by most image editors, even if many native PS features are not. Or what about a Word file or a PDF version of that same Word file? A preposterous question, of course: anyone who wants to edit a document knows that the PDF is nigh on useless for this, and will choose the Word file. All word processing software worth its salt support Word import and export. Likewise, IDML is a worthy candidate as a intermediate file format, and is indeed already supported as a general import format by most DTP layout software. Which is why I think IDML should not only be importable in Publisher, but also exportable. @MikeW Scribus supports IDML import only at this time. The community is thinking about integrating IDML export as well. Viva Designer Pro supports my argument here: that company is smart enough to understand the simple concept that InDesign is the industry standard, and that IDML is a good intermediate format. Supporting it is the way to go. PDF is just not a viable alternative for all the reasons I explained.

For anyone doubting the usefulness of IDML import versus PDF import, let's create a list of advantages and drawbacks. I am comparing Affinity Publisher with the (free) open source DTP software Scribus, which indeed DOES import InDesign IDML files. Affinity PDF Import Advantages: keeps the exact (99%) of visual fidelity, including visual effects. text lines are grouped as paragraphs. Affinity PDF Import Disadvantages: original source file's layer structure is not maintained. This leads to almost unmanageable layer situations (try importing a PDF with a table). Layers are a complete mess, completely unstructured. paragraph and character styles are lost, which makes it impossible to quickly adjust text formatting for complex documents, and even for simple documents such as flyers the user will have to manually recreate all the paragraph and character styles. tables are lost and converted to graphical objects consisting of hundreds, if not thousands of elements for more complex tables. images running over page folds in a spread are cut into separate elements. This means it is almost impossible to adjust a crop, for example. external links to images are lost. master pages are lost, and have to be recreated: an impossible task for more complex jobs, like magazines. guides are lost text threading is lost. This means a text edit in an article will not adjust the text flow across all pages for any given threaded article or story. images are cut to crop size. Originals are lost. Scribus IDML import Advantages: Master pages are maintained (the name of each master page is not). Paragraph and character styles are maintained. Layer structure is maintained across the entire file. Tables are maintained (see caveats below). external image links are maintained. Images crossing the fold are kept intact as singular objects. Text threading is maintained. Named colour swatches are maintained. Anchored objects are maintained (with some caveats due to Scribus' method of anchored objects). Original images are maintained. Cropped content is accessible. Scribus IDML import Disadvantages: Visual fidelity is more or less maintained, but it depends heavily on the complexity of the original InDesign document. Some documents require heavy editing to restore the original's visual appearance. Table styles are not maintained, nor is the visual formatting. Guides are not maintained. In short, PDFs lose the original source file's structure - completely. This can't be helped, because PDF is meant as a final publication format, and not really meant for any serious editing, although nowadays many users tend to view PDF as a type of intermediate format (which is rather a bad idea). Which explains why the Affinity Devs decided to focus on PDF import, rather than a solid IDML importer. That, and the fact that PDF being what it is, it retains the exact visual quality in most cases when imported through an existing PDF framework. Just less work. And initially a nicer workflow, because it retains the visual affinity (no pun intended). Probing a bit deeper, and we find that the PDF import workflow yields an utterly unstructured mess. For structured long documentation and publications it goes without saying that PDF import is pretty much entirely useless for anything beyond slight and superficial editing work or simple brochures, flyers, and such. But we could do that work in Affinity Designer. Publisher is meant for more structured and complex jobs - at least I hope that is what the developers are striving for. Even with its drawbacks and limitations in regards to keeping the visual fidelity, if I was asked to edit and heavily modify an existing technical manual of 100 pages and was given the choice between a PDF and an IDML file for import and conversion, I'd never even consider importing the PDF. I would open the IDML in Scribus (or another DTP app with IDML import like Quark), and keep the PDF as a visual reference. Because fixing visual effects and other outliers is FAR less work than attempting to do work with an unstructured and messy PDF conversion with no master pages, text styles, external links, tables, and the broken text threading. It would be an impossible job, and I would have to start from scratch. It is just not a feasible proposition. Even for simple work, such as formatting a table, or a booklet with ~30 pages and lots of text, an IDML file will at the very least keep the structure and text threading. Yes, it may take extra work to fix the visual formatting, but a PDF imported in Affinity Publisher will have lost any clue as to its former structure: both text as well as images. For any serious editing work IDML import is a must. Now, the thing is that IDML is a reasonably simple to understand and interpretable open file format, and I was somewhat surprised (understatement) to discover that Publisher can't import them. If Publisher had had scripting integrated, I am sure someone in the community would have taken up the challenge to write an IDML importer, just as what happened with Scribus. To me the lack of scripting in Publisher is a far greater issue and its main Achilles' heel. I am pretty sure, had scripting been available from the beginning, we would have already seen a first alpha version of an IDML importer. Yet the reality is sombering, and I do hope the lack of scripting will be fixed by version 2. The devs well and truly shot themselves in the feet when they decided to exclude a scripting API.

Sure, whatever works. I prefer Opera since it is installed on my local machine, and I can't be uploading licensed (client) work to an online service like that. I need to be able to maintain control over the files.

Well, the Opera browser is a free and safe browser. I use it quite regularly to convert SVG files to PDF (not so much for browsing, funnily enough).

Did some testing, and in other applications scaling up with Bicubic Spline results in an even nicer/usable scaled up version than your Photoshop version. Unfortunately, Affinity Photo doesn't give the user a choice in resampling algorithms when upscaling and rasterizing a specific layer. I then attempted to upscale the original with the Resize Document option, and selected Bicubic as the resampling method. The result leaves a LOT to be desired of compared to any of the other apps I tested in (Krita, PhotoLine, Gimp). In my opinion, based on my previous experiments with downscaling assets, and now with this particular upscale example, Affinity's resampling code base needs to be looked at again. It is a quite fundamental thing to get right. If other applications have no issues with up- and down-scaling, my only conclusion can be that something is amiss with Affinity's basic approach in resampling. The choices of resample methods in the preferences and document size dialog are fairly limited as well. For downsampling, for example, Lanczos and Bicubic are far from ideal choices, but no alternatives such as CatmulRom or MitchelNetravali are on offer in Photo. As it stands, Photo is lagging behind all the competition in this area. Let's hope the devs will address this in an upcoming release, because it needs to be.

Open troublesome SVG files in the Opera browser, right-mouse click the SVG, and save as PDF. Then open the PDF in Affinity.

Still, aside from the OP's perceived age of Photoshop CS6, the complaint of the OP still stands. It is an awkward and convoluted process in Photo to work pixel-precise this way.

And for those of you who doubt the veracity of option (1)'s usefulness, consider this situation: suppose an asset needs an exact white margin defined. Like the OP, we add guides that define the exact size of the asset first. Then we precisely calculate and place additional guides to set the margins. (Photo's inability to change the ruler origin irritates us while working on this last step.) Then we crop the canvas according to the outside trim guides. Result: the inside margin guides move (or completely disappear when working on a larger canvas). This is unwanted behaviour, of course. We defined those inner guides to remind us of the exact margins, and may have need of those at a later stage in our workflow. But they moved, rendering our preparation phase useless. Just a simple example of why option (1) is actually preferable over (3) as a default behaviour. If anything, Affinity Photo ought to behave like (4). Or (1) - better, the choice between the two.

The behaviour of guides after changing the document or image size in design applications fall broadly in four main categories: existing guides remain in place (what the OP expected to happen): Inkscape, Gravit Designer, Photoshop, Photoline, Xara Designer Pro; existing guides automatically adjust relatively to the new page size. A column grid based on guides will automatically narrow down to accommodate a smaller width canvas: InDesign, PhotoLine with formulaic %-based guides, Xara Designer Pro with Auto-fit, Affinity Photo with percentages; existing guides will move in absolute units in relation to the top left origin of the canvas (Affinity Photo, Krita); existing guides will move in absolute units but in four, three, two canvas edges or a single canvas edge (PhotoLine with px-based guide formulas) ...and a very few design apps allow for a combination of above methods (PhotoLine for example). I believe InDesign has multiple options as well. (1) has its uses. (2) is incredibly handy to have, for obvious reasons. (3) is only useful when guides need to move from the left top origin only. (4) is a much better variant of (3), because the size of absolute margins defined by guides, for example, would be retained on all or defined sides of the new canvas size. Having options (1), (2), and (4) in an design app come in handy for most practical situations in my experience. Affinity Photo supports (3) and (2). (2) is very nice, of course. In my opinion (3) is not that useful to have, because existing guides used as an absolute measure device will move after resizing a canvas and move into one direction only. Both (1) and (4) would be preferable as an available user choice. As far as I am aware only Krita and Affinity Photo (Designer too?) behave like (3) without an option to define absolutely positioned guides relative to all canvas edges or a selection of these. Anyway, I'd like to see more control over how guides behave in Photo in the future. (1) is very handy to have, actually.

@SrPx Blender is slowly making ways into larger VFX and Animation studios as well. Just look at Tangent Animation's NexGen, and all the work done by Barnstorm VFX on primetime shows (both are Blender-based studios). Something unthinkable only 7 years ago. But yeah, if you are planning a career on current job requirements in the animation industry, Maya still rules. Houdini is more or less required for many VFX jobs too. As a freelancer or Indie outfit/small team I'd say go Blender all out - which is already the case anyway with many game devs.

Yes, this is one of those cases where anti-aliasing wreaks havoc with the result, and Affinity Photo does not have an option to automatically render all objects to the pixel grid automatically. Yes, there's Force Pixel Alignment, but a 1 pixel line will have to be placed exactly at 0.5 - which is a bit ridiculous to ask of the user. Other design apps solve this with a simple document wide or even layer-specific pixel snapping that changes the rendered result on the fly. Not so in Photo, unfortunately. One of the many reasons why I think Affinity Photo is rather unsuitable for precise pixel work and pixel art. Another reason being the lack of a simple document-wide option to turn off anti-aliasing. And the Coverage Map work-around is a half-baked one. [ On a side note, I found that it is often the simple basic things which require all sorts of convoluted hacks and work-arounds in Photo. That is why I mainly use it for HDR merging, stacking, and sometimes panoramas, and then export the result to continue work in other image editors. Of course, this is my personal experience, and a bit of a shame. Basic workflow foundations in Photo are quite shaky. ]

Please refer to this thread: A similar import issue affects Publisher: 16bpc greyscale TIFF images are imported washed out and too bright. My hypothesis is that the Affinity developer team never tested such files before. This should be resolved. InDesign and Scribus import these files without any issues.

A quick test of importing your 16bit greyscale TIFF file reveals that Photo indeed cannot open it correctly - or at least, Photo assumes it is dealing with a RAW file. I also tested Krita, PhotoLine, InDesign, Xara Designer Pro, IrfanView, even OpenToonz (animation app), Scribus, and finally Affinity Publisher. All applications load up your file without any issues, excepting both Affinity products. Even Affinity Publisher loads it incorrectly (too bright and washed out). This leads me to believe that the Affinity developers have never tested actual 16bpc greyscale TIFF files while developing the import filters. I would call this a bit of an oversight (which is an understatement of rather planetary proportions). The 16bpc PNG version loads up correctly, though. I would suggest that if you intend to use Photo for your image processing, you scan and save directly to 16bpc PNG files instead of greyscale 16bpc TIFF files.

Initially I expected "Erase White Paper" to work here (found in the FIlters-->Colors menu, but Affinity Photo's won't leave the saturation alone, which results in semi-transparent colour fills. Sigh. Half-baked implementation compared to other apps, unfortunately. After applying the erase white paper effect, duplicate the layer four, five or seven times to restore the fills. Then merge those layers. (Merge visible). Or use the flood select tool, turn off "Contiguous" and click on the white background. Then hit the delete key. But it will leave white fringes, and Affinity defringe function for some reason won't deal with them.

This SVG file is quite problematic: I've opened it in various editors, and none open it completely correct. As stated, even Illustrator gets it wrong with that one leaf. Only the browsers process and render that file correctly. Quick tip for anyone not having access to Illustrator to fix a problematic SVG file: install the Opera browser (https://www.opera.com/) and open the SVG file in it. Right-mouse click the view, and choose "Save as PDF". This will fix all (or 99% of) issues. It depends on the PDF importer of your app whether the dark leaf will be imported correctly, though. Affinity Photo (and I am guessing Designer as well) do not support the soft dark mask that is required for the top right dark leaf. It is relatively easily fixed (just like in Illustrator) in Photo, though. I did some more testing for fun, and found that Krita, PhotoLine and Gravit Designer all deal differently with this SVG file as well - and the results are all over the place. Krita's version sort-of explodes. :-) After converting the file to PDF with Opera, all applications, including InDesign (which does not support SVG files) import it correctly, excepting the dark leaf at the top right. Every single application I tried the PDF with gets that top right leaf wrong, but for PhotoLine which (surprisingly) is the only app among the ones that I tested which gets it right. That particular leaf is created with a hollow shadow mask that is misinterpreted or unsupported by most of the design software. Interestingly enough when I re-save the PDF version in PhotoLine, it corrects this error, and all other applications then import the pdf without any visual issues, and the leaf mask issue is resolved. At the expense of editability, unfortunately. Sigh, can't have it all, I guess. Resaving the file from PhotoLine as an SVG and importing the result in Affinity also works well, although that darn leaf still refuses to be shaded correctly. I checked the result and that leaf's shading is rather complex, which would explain why most software seems to choke on it. They all, expect the browsers and PhotoLine after conversion to PDF, miss that transparent image overlay with the soft shading mask. Check it out below. Anyway, in short: use Opera to save a PDF version, and it will work fine (excepting that darn leaf) in Affinity. PS Xara Designer Pro and Gravit Designer both import the SVG with mixed results, both rendering it incorrectly. As mentioned by the OP, Inkscape's SVG import results in a weird translucent version, but Inkscape does import the PhotoLine SVG re-saved version without issues, though. Neither Xara nor Gravit support PDF, however, so no go for those two.

@>|< Corrected. Although this still doesn't solve the issue when zooming in.

You are right, I corrected this in my answer. But any value over 100% that is not a multiple of 100 results in badly jagged edges in the viewport. That ought to be addressed.

The answer to the OP's question is really very simple: in Affinity Photo and the pixel persona any zoom factor other than an exact multiple of more than 100% results in jaggy-looking edges. No matter the View Quality setting (at least, it makes no difference on my system). That is all. In your screenshot the zoom factor is set to 93.6%, which is a decimal zoom factor that won't allow for a nice looking preview, and Affinity renders the pixels approximately. Which results in outliers, and an ugly preview. [EDIT: on my system it does render nicely below 100% as long as the view setting is set to bilinear, just like @>|< mentions above.] Depending on the software's view rendering implementation the screen interpolation may be much improved. As an example, the older versions of Photoshop were unable to render nice smooth edges at decimal and none times X100 zoom factors. At some point the PS developers used the video card's hardware accelerated OpenGL to enable smooth viewport rendering. Turn off the hardware acceleration in Photoshop, and the same issue rears its ugly head again. Krita's developers spent a LOT of time and effort on getting this right as well. As did the developers of ClipStudio. When I open the OP's file in Krita, I have no jaggies at any zoom factor. Nor in ClipStudio. Or in IrfanView with resample with zooming activated. So, in short, the problem is caused by Affinity's viewport rendering, which is (sorry) sub-par compared to other applications at this time when zooming in beyond 100% and non-multiples of 100%.. At least, on Windows. I haven't checked this on the Mac. By the way, about that file: whoever created it had either no clue about properly rendering a vector as a bitmap, or downsampled a larger version. The giveaway clue: the straight edges are anti-aliased, and if you know what you are doing it can be easily prevented.

Many, many ways to introduce randomness in you work. One obvious method is to scan in or digitally photograph a sheet of paper that you've dirtied up and treated somehow, and combine that in your work with various layer blend modes and masking. A simpler method would be to download one of the multitude of free "dirty" / "scratches" / etc. brushes from the net, and combine them in your work.

Just a quick tip: instead of using the traditional flood fill colouring approach, you may want to investigate Krita's Colorize Mask to speed up this type of work. Things have moved on a bit since the advent of the flood fill tool At least twice as fast and much more controllable. Colorize in Krita, then import the colour layer for easy selections, isolations, and pattern fills.

@Tom Schülke It's an action, not a script. The effect is quite simple to replicate, see https://design.tutsplus.com/tutorials/architecture-sketch-photoshop-effect-action--cms-30614 As far as I can tell, nothing in that tutorial that couldn't be replicated and turned into an Affinity macro. The seller of the Photoshop action merely added a water colour effect in the background.

The example image is a really awkward photo: soft white bloom surrounding the image, white highlights, ... Attempting to place this can in a different dark-coloured background is just not going to work well, even if a lot of work is put into fixing things. Why not google for alternatives without the soft bloom? For example, this one is relatively simple to remove the background from: