Mark Oehlschlager

@chippwalters No. Nothing new on this front.

@R C-R I saw that. I assume that's some kind of anomaly in the way this version of Designer interprets and reports ppi. Strange. I don't understand why that would occur.

@R C-R Yes, that's a good point. Designer offers helpful feedback in the contextual toolbar when one places an image. See screenshots below. I placed an image in a 1280 x 800 pt Designer document with a raster DPI of 216. By default the image gets placed at a point size and pixel density (216 DPI) that is consistent with 3x pixel dimension export. If I were to manually scale the image up, the contextual toolbar would report a new DPI for the image that would fall below the 3x DPI of 216. That would be the clue that the raster image at that point size ("Logical Size") would be insufficient to export a true 3x asset. I suppose that one could decide that exporting out at 2x would be sufficient, in which case one could afford to scale the image up to the point where the context toolbar indicates an image DPI of 144. Or decide that 1x assets are sufficient, in which case one could scale the image up further to the point where the context toolbar indicates an image DPI of 72. Which reminds me of a neat UI feature I've seen in a WYSIWYG website design app. In that app, you indicate your preferred page dimensions in "Logical" point units, and when you place and resize raster images, a graphic bar gives you instant, real-time, visual feedback about the relative pixel density of the image at its current size, and whether it's sufficient for 1x, 2x, or 3x output. It's one way of working.

@R C-R Yes, just to make explicit how this approach to setting up Affinity documents can be useful for webpage design and the export of 1x, 2x and 3x raster assets. I read the article on Affinity document settings for iOS icon design and eventually understood that it could be applied to webpage design as well as to iOS icons, but this concept of setting up a Designer document with Document Units set to points and DPI set to 216 (3x) received considerable pushback from others who work differently. An article on Affinity Spotlight that explicitly shows how this approach applies to webpage design would have answered my original question and I probably would not have posted the question to the Forum that has generated so much back and forth.

@All Media Lab Thank you for sharing the very useful Affinity Designer template files for the standard Bootstrap page grids.

@MEB Yes. Exactly. Thank you for chiming in. Can I suggest that someone at Serif author an article on Affinity Spotlight to make this approach clear. Regards, Mark

@thomaso Vielen dank für Ihre Antwort. Viele haben darauf hingewiesen, dass dpi / ppi für Bilder, die für HTML-Webseiten bestimmt sind, keine Bedeutung hat, dass es nur um die Pixelabmessungen der Bilder im Verhältnis zur "device pixel density" der Anzeige geht. Natürlich verstehe ich diesen Punkt und stimme größtenteils zu. Die Auflösung, das Verhältnis von "Pixel-per-inch", ist jedoch in zwei Fällen für Rasterbilder relevant: 1.) die dpi / ppi des gerätes anzeigen (das muss man einplanen). Bezüglich der dpi / ppi der Geräteanzeige ist die Variation von dpi / ppi zwischen Geräten groß und ohne universellen Standard. Es ist so wie du geschrieben hast. Es besteht nur allgemeine Übereinstimmung, einige Pixeldichten als 1x, einige als 2x und einige als 3x zu klassifizieren. Für den Designer bedeutet dies, dass alle Rasterbilder mit Pixeldimensionen in drei Maßstäben erstellt werden sollten, um die schärfste Qualität zu erzielen. Natürlich wird das Bild zwischen dem vom Anzeigegerät angegebenen "Device-Pixel-Ratio" und dem CSS-Code richtig skaliert, aber das Bild muss die richtigen Abmessungen haben, um mit den dpi / ppi des Geräts übereinzustimmen. 2.) die dpi / ppi der eigenen Bildsoftware. Hier stimmen einige Leute nicht überein, aber wenn man die dpi / ppi der Bildsoftware so einstellen kann, dass man Bildausschnitte mit 3x Pixel-Abmessungen exportieren kann, während man das Dokument in einem vernünftigen 1x-Maßstab zeichnet und anzeigt, ist es schöner. Wie du geschrieben hast, ist es möglich, eine A4-Seite mit 300 ppi einzurichten, die für viele Zwecke geeignet ist. In den Affinity-Apps habe ich festgestellt, dass dies möglich ist, wenn man die "Document Units" auf "Points" und die DPI-Einstellung auf 216 setzt (wodurch effektiv ein zugrunde liegendes 3x Pixel-Raster erstellt wird). Man kann dann die "Export Persona" verwenden, um die alternativen 1x, 2x und 3x Bilder zu exportieren. In Bezug auf das Problem der Anpassung des Designs für eine "Responsive Site" denke ich, dass die Lösung, die ich jetzt bevorzuge, darin besteht, separate "Artboards" für jeden sogenannten "Breakpoints" zu erstellen. So könnte man zum Beispiel die folgenden Artboards in Designer erstellen: • 960 pt breit (Desktop) • 768 pt breit (Portrait-Tablet) • 480 pt breit (Landscape Phone) • 320 pt breit (Portrait Phone) Man löst das Design für das Desktop-Layout, kopiert dann den Inhalt auf alle anderen Artboards und nimmt Anpassungen an Skalierung und Position vor. Was sind deine Gedanken hier? Welche Methode bevorzugst du, wenn du Webseitenmodelle in Affinity entwirfst? Was sind deine bevorzugten Dokumenteinstellungen? Alles Gute.

In the context of setting up an Affinity document, the document dimension units and DPI setting in the New Document dialogue box is absolutely relevant to exported size of raster images. The Preset for "Web", WXGA 1280 x 800, sets up an artboard where document units are pixels, the artboard dimensions are 1280 x 800 px, and the DPI is set to 72. If that artboard were to be exported out as a PNG, one would get a PNG with pixel dimensions of 1280 x 800. That raster image would look half as big on a new 220 ppi iMac than it would on my 2012 110 ppi iMac, unless, of course one used CSS values to scale the image up 2x, in which case the image would look fuzzy on the new 220 ppi iMac. On the other hand, if you were to modify that Preset such that the document units were points, the artboard dimensions were 1280 x 800 pt, and the DPI were 144, one could layout the page in points (1x equivalent units) and export the artboard as a PNG with 2x pixel dimensions of 2560 x 1600, suitable for display on a new 220 ppi iMac without loss of size or clarity. Those are the effects of choosing those document units and DPI settings in Affinity apps. Postscript: If one sets up a document in points with a 144 DPI and then goes to export, the 2x pixel resolution is present, but only gets exported as 2x with the @2x export setting.

@R C-R This is interesting. It appears that the Page Presets for the non-Apple devices like the Nexus 5 just takes a different route to the same logical conclusion. Whereas the Presets for the Apple devices define artboard dimensions in terms of "Logical" display pixel dimensions with a DPI setting that calculates device pixel dimensions by essentially doubling or tripling the "Logical" display dimensions, the Presets for devices for the Nexus 5 just expresses dimensions in terms of actual device pixels with an actual screen density of 445 pixels (that's equivalent to the density of the iPhone 11Pro, a 3x device). The Affinity Presets for "Web" are targeted at desktop and laptop displays. My 2012 iMac has a device pixel density of 110 ppi. Newer iMacs and MacBooks have displays with a device pixel density of 220 ppi. I believe they present themselves with a Device Pixel Ratio of 2, which means that all of the elements of a webpage described by CSS units will scale up 2x, but the raster images that are referenced will have to be correctly sized for the 2x environment. So, going forward, it may make sense to build webpage mockups in Affinity for desktop page widths where the page dimensions are set up in points with a DPI of 144. In that way, one can still be thinking of a 1280 wide page, but in Affinity that's expressed in points, while the underlying raster is double, expressed as 144 DPI, which means you can slice and export 2x raster assets directly.

@All Media Lab I've read the article you linked to. I understand it completely. I don't disagree with any of the points made. Here's where DPI is relevant to a workflow that uses the Affinity apps to design and build webpage mockups: the New Document dialogue box which asks for Document Units, Page Width, Page Height, and DPI. Note in the screenshot below that the Page Preset for an iPhone 5/SE (Retina) establishes points (pt) for Document Units. Page Width: 320 pt. Page Height: 568 pt. DPI: 144. What's going on here? Well, the Retina display for the iPhone 5/SE has an advertised "Logical" display size of 320 x 568, but has an actual device pixel dimension of 640 x 1136 (326 ppi for what it's worth), 2x the so-called "Logical" display size. The Affinity Page Preset for this device sets me up with an artboard that measures 320 x 568 pt (units that correspond to the "Logical" display size) with an underlying raster density of 144 DPI (2x the assumed raster density of 72 DPI) And, if you temporarily switch the document units to pixels, you'll find a 320 x 568 pt artboard at 144 DPI produces an artboard that measures 640 x 1136 px, exactly the dimensions of the 5/SE display in terms of physical device pixels. What does that mean for me? It means that I can begin a webpage mockup in Affinity Designer, targeted at a 2x mobile device with a "Logical" display width of 320 px, work in the 1x equivalent units of points, but still have the underlying device pixel density to slice up and export raster image assets with sufficient 2x pixel dimensions. I can also use Affinity's Export Persona to generate a 1x version of those raster image assets if I choose. So, it is within the context of using Affinity apps to design webpage mockups and export raster image assets that DPI is relevant.

@R C-R Not sure that DPI is irrelevant here with respect to slicing and exporting assets. Here's the way I'm understanding the page presets: Traditional typographic points from the print world have been conveniently adopted here as a proxy for CSS Reference Pixels ("Logical Pixels"). Traditional typographic points are 1/72nd of an inch – 72 points per inch. Nevermind that on my 110 PPI iMac a 72 x 72 px PNG will actually appear to be 0.65 inch and not a full inch. What's important is that on a 1x display, 1 point equals 1 device pixel. But, for a 2x display, 1 point (stand in for the "Logical Pixel") equals a 2x2 device pixel cluster, hence the doubling of the DPI setting in the Designer Page Presets from 72 to 144. And, for a 3x display, 1 point equals a 3x3 device pixel cluster, hence the tripling of the DPI setting in the Designer Page Presets from 72 to 216. The benefit here, as I see it, is that the page layout designer can start a new document measured in points (an assumed 1x design scale) with an underlying 3x raster density (216 DPI) and be able to slice and export raster assets for 1x, 2x, and 3x device displays.

@firstdefence Thank you for the article and the related sample Designer file. Question: When you set up your 12 column guides, is there an advantage to drawing the columns as curves rather than using the Guides Manager to set up column guides? In your sample file for a 960 px wide webpage, you set up the document in pixel (px) dimensions with the DPI set to 72. This is of interest to me, as it gets to the heart of my original question. I've since taken a closer look at the Page Presets in Designer's "New Document" dialogue box for the type categories "Web" and "Devices". I've noticed that any new document started from a "Web" preset assumes page dimensions set in pixels (px) with the DPI set to 72. Any new document started from a "Devices" preset assumes page dimensions set in points (pt) with the DPI set to either 72, 144, or 216 (depending on the device targeted). All of which suggests that Serif are using point units (pt) to represent so-called "Logical Pixel" page dimensions (the CSS reference pixel dimensions that get scaled up by the Device Pixel Ratios), and using the underlying DPI raster density settings to represent the 1x, 2x and 3x device pixel densities that dictate linked raster image dimensions. I guess one of the assumptions made here by Serif is that the collection of "Web" page presets are targeted at desktop and laptop displays with an assumed 1x Device Pixel Ratio, and therefore page units are set to pixels (px) and the DPI is set to 72. The latest iMacs and MacBooks from Apple, however, employ Retina displays and are considered 2x devices. So, it seems that the best practice, whether targeting desktops or mobile devices, is to set up Designer documents/artboards with page dimensions set in points (pt) that reflect the "Logical Pixel" dimensions of the targeted device, and to set the DPI at 216 (3x pixel density). That way, one can lay out a page design using points (equivalent to CSS reference pixels, or "Logical Pixels"), and know that placed raster images can be sliced and exported out at 1x, 2x and 3x sizes.

@R C-R Thanks for the link. Yes, I'm familiar with the rudiments of HTML and CSS. I understand that responsive websites depend upon CSS and JS queries about browser version, OS, Device Pixel Ratio, and browser width in order to associate relevant stylesheets with the HTML page, which can then dictate size and placement of blocks and links to appropriately sized image resources. I was originally curious about how best to set up a Designer document for producing webpage design mockups with a special consideration for targeting the various devices and their unique device pixel densities.

I respectfully disagree with the notion that designs cannot or should not originate from pencil sketches and graphic design apps like Designer. HTML and CSS are advanced enough now that any design produced by a graphic designer can be reproduced by code. The notion that webpage designs should be done exclusively by coders unnecessarily discounts the aesthetic expertise of visual designers. The healthier view here is to find the tools and the workflows that link the collaborative contributions of designers and engineers. Having said that, the original question concerned recommendations for how to set up an Affinity Designer document in terms of pixel dimensions and DPI. The answer appears to be that one should plug in pixel dimensions for the new Designer document/artboard that correspond to the CSS reference pixel dimension of the webpage (what James referred to as "Logical Pixel" dimensions), and not to worry about actual device pixels, as the Device Pixel Ratio communicated by each device will scale the CSS pixel dimensions up such that a 2x device will map one CSS pixel to a 2x2 device pixel cluster. As for the linked raster images in a webpage, one just needs to make @1x, @2x, and @3x size alternates in order for those images to remain sharp on the 2x and 3x (Retina and Super-retina) devices. Thanks for the replies.

@All Media Lab Okay. Thanks. It sounds like your firm never works from a page layout prototype produced by a graphic design tool. This is my problem, as I need to be able to pass along page layout designs produced in Affinity Designer to Website development shops. More and more, I'm getting the impression that for those whose workflow does include working from layout designs produced by graphic design apps, the simple guideline is to produce those page layout prototypes with page dimensions specified in pixels, which will correspond to the CSS pixel dimensions of a 1x device (what James calls "Logical Pixels"). And, as actual physical device pixel density varies dramatically from device to device, the page layout designer should worry less about type and images displaying at exactly the same size on every device, and more about making sure that the proportional size relationships are preserved on every device. For example, if I draw a 200 x 200 px box on a webpage mockup in Affinity Designer on my iMac (which has a display pixel density of 110 PPI), then in the subsequently developed responsive webpages, I should expect to see a box of the exact same physical dimension in the Safari browser on my iMac (110 PPI), and a box of similar physical dimensions, if not exact, on my iPhone 8 (a 2x device with a device pixel density of 326 PPI). Many thanks for your replies. Best Regards.

Okay, and when sketching out page layout designs in one of those other non-Affinity apps, before going to code, do you specify page dimensions in terms of CSS pixels (i.e., 1x "Logical Pixel" dimensions that get scaled up for 2x and 3x device displays)?

@All Media Lab Okay, but when you and your colleagues are working out page layout designs (before any coding or slice exports), what app are you using and what assumptions are you making when you indicate dimensions and DPI/PPI in the new document setup dialog box?

@All Media Lab Before you and your colleagues go to code, when you are just designing the page layouts for desktop, tablet and phones, do you use either of the Affinity apps, and if so, how do you set the design documents up in terms of dimensions and DPI/PPI?

@All Media Lab Thanks for the screenshots of your header image export. I assume that you are working from a 3x version of your image, and exporting out downsampled 2x and 1x versions.

@Old Bruce Thanks for you reply. Not really asking for a lengthy commitment to research from anyone. Just asking for best practice recommendations from those who have knowledge of the problem of designing for the Web and mobile devices. Or, if no one on staff can answer definitively, an honest reply saying as much would be fine. I've just re-read an article by @James Ritson on DPI, and the conclusion I draw from that article is that one really can't assume a standard 1x pixel density (or what James describes as "Logical Pixel" resolution) of 96 PPI. https://affinityspotlight.com/article/understanding-dpi/ The best take away advice I can glean from the article is that a designer should layout Webpage design documents with pixel dimensions that correspond to the "Logical Pixel" dimensions of the Webpage for each device, the 1x Device Pixel Ratio working environment (e.g., 1024 wide for a desktop browser, and perhaps 320 wide for a mobile phone in portrait orientation), and either disregard DPI settings altogether, or use 72 DPI as that conveniently corresponds to traditional typographic points in print design. Beyond that, rely upon proportional relationships in composition, and then generate @1x, @2x, and @3x versions of all linked raster images, so that the higher res images can be properly substituted on so-called Retina display devices. I'm not aware of this file name nomenclature. Is this meant to be a file name suffix? How is it used?

@MEB Really hoping that someone from Serif can take the time to address my question here. Who on staff should I address my question to? Sincerely, Mark O

@Sean P Sean, could you please respond to my technical questions here? I would appreciate if someone from Affinity could help provide a clear set of best practice guidelines for using Affinity apps to design webpages given that we live in a world of 1x, 2x and 3x devices. Should we design pages in Designer or Photo with a 96 ppi raster resolution (1x), and then separately set up 288 ppi Photo documents to generate 3x images? Thank you for your attention.

@acapstick Andy, I remember you authored an article on how to set up Designer to design icons for iOS. Can you shed any light on the technical aspect of my question above? I'm just looking for some simple workflow guidelines for designing Webpage layouts with an understanding of the relationship between my Designer document units, the CSS reference pixel, and the countless instances of mobile and desktop device pixel densities. Thank you.

I'm writing to request recommendations for the best workflow using Affinity apps to design Webpages, and then to export 1x, 2x and 3x raster assets. It's my understanding that the W3C has established a theoretical, device independent, CSS reference pixel grid that designers can work to with a pixel density that is 96 ppi, where the various mobile and desktop devices that end up displaying the Webpages will apply a relevant Device Pixel Ratio (1x, 2x, or 3x) to scale the Webpage type, layout and imagery up to cover the actual Device Pixels. If I understand the situation correctly, I should begin my Webpage designs by opening up an Affinity Designer document at 96 ppi (DPI) with artboards that match the pixel dimensions of my target page (e.g., 1042 x 600), and then use the Export Persona to export assets out at 1x, 2x, and 3x. Does that sound right? And what about some instances of raster art, like a hero image. Should I work in the opposite direction (i.e., from an Affinity Photo document with triple the dimensions and resolution: 288 ppi), and then export downsampled 2x and 1x versions? What works best for all you Web designers?

@jer I should add that if your target output is the printout from your HP OfficeJet Pro 7740 Wide Format printer consider the following: the quality and finish of your paper (standard uncoated office copy paper, or coated paper for photos or high-fidelity color output) color matching options presented by the print dialog box (with Mac OS I can select either "ColorSync" or "In Printer"; see attached image) If you are still not getting desired results, consider using a Soft Proof adjustment layer at the top of your layer stack (see attached image), where the color profile of your OfficeJet Pro 7740 is selected. If you've installed the printer driver for your printer on your computer, the corresponding color profile should be available for you to select here. This should give you an accurate impression of what the printed output will look like.