Mark Oehlschlager

@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?

@MattP So, this is a technical problem that no developer has an answer for? I'll take your word on that, but, from a designer/user's point of view, one expects filled vector objects that are perfectly aligned to show no visible gap between them. I appreciate your offer of help, but it would appear that there is nothing to be done here except for a few user hacks (e.g., extending the edges of the vector objects such that they overlap).

I've become aware of a problem in all Affinity apps (released versions and beta versions) where perfectly aligned edges between two rectangular shapes will leave visible hairline gaps between the two objects. Currently running the latest betas and released versions of all the Affinity apps on Mac OS High Sierra 10.13.6. See attachments below. The screenshots illustrate the problem, where I've drawn 40mm x 40mm white rectangles with no stroke, aligned horizontally, over a strongly colored ground. I used the "Page Layouts with Objects" snap preset to align the objects. I've used the Transform panel and the outline view to confirm that the objects are aligned. And yet, the colored ground clearly shows through between the supposedly aligned objects. Please address this bug in the next release of all three Affinity apps.

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

@jer The simplest way to work without investing in expensive and complicated color calibration tools is to work in the sRGB color space. sRGB is not the largest RGB color space, but it has been adopted by device manufacturers as the most common minimum color gamut that most electronic displays can display. Moreover, most desktop printers (inkjet and laser) sold to offices and home users expect sRGB files, which the printer converts (using it's built-in color engine) to CMYK for output. And if you ever have need to send a press-ready PDF to a professional offset printer, you can then convert a copy of the document to the CMYK color space profile recommended by your print vendor (in the U.S. it's most commonly "U.S. Web Coated (SWOP) v2). Check your Affinity Preferences for Color. There you can set your preferred color space profiles for RGB and CMYK documents. See the attached screenshot below for the Affinity factory defaults.

Publisher 1.8.0.531: The contextual toolbar pop-up and slider controls for zoom level remain disconnected from one another. See attached images.

@Matthias I think the whole objective of color management for the designer is to preserve the fidelity of color appearance. That is to say that if a designer selects a particular orange for his artwork in one medium (ink, paint, computer monitor), he can expect the appearance of that orange to remain constant even as the artwork is translated from one medium to the next, or from one color space to the next. It's incumbent on the designer to understand that the color gamuts of the various color spaces (e.g., Adobe RGB 1998, sRGB, U.S. Web Coated SWOP CMYK) are of different sizes and do not perfectly overlap, and to understand the difference between the relative values of RGB and CMYK numbers for describing color in specific RGB and CMYK color spaces (an orange that is described by the relative values R: 255 G: 128 B: 0 in the sRGB color space will appear differently in the much larger Adobe RGB 1998 color space), and the more fixed, absolute and universal values of CIE Lab, which describe the full spectrum of color that the human eye can perceive – independent of device or medium. Equally, our software tools should make it easier to understand the target color space in which we are working (for any particular document) and easier to pick and specify color with the confidence of knowing that the appearance of the color we've selected is right for our target color space and will be preserved on output. That's the design challenge for the software designers and engineers.

@Jowday Thanks. It appears that use of HSL color components is generally associated with the sRGB color space, but can be used as a schema to describe color in other RGB color spaces. Correct? In any case, if the Affinity software is going to allow users to use sliders from various color models (sRGB, CMYK, Lab) to define colors/swatches in documents with a specific operating color space, it seems to me that it would be useful for the UI to provide visual feedback if/when the user defines a color that lies outside the color gamut of the document's color space. Additionally, it would be useful, in the case of working with documents whose color space gamut exceeds the that of the computer display, to offer a way to highlight document colors that would be clipped by the display's relatively small color gamut. In terms of preserving the integrity of the appearance of color on screen when working with art in different documents of different color spaces (i.e., sRGB, SWOP North America CMYK, etc.) I'm not sure what the Affinity software is designed to do. Perhaps, for each color/swatch that the user defines, regardless of what color model sliders the user employs, the software keeps track of the CIE Lab values in addition to the relative RGB and CMYK values? So, if one document is imported into another with a different color space, and "Convert" is the color management policy, the CIE Lab values are used to preserve color appearance and the RGB and CMKY values are allowed to be translated for the new color space. Whereas, if "Assign" is the color management policy, the RGB and CMYK values are preserved in the new space and the CIE Lab values are translated to describe the altered appearance. Maybe? I just wish the Affinity UI made it easier to spec color for specific color spaces with confidence.

@fde101 Hmmmm. Okay, so HSL is an alternative model used to describe color within the RGB cube model. And the size of the color gamut described by HSL values is determined by the specific RGB color space it's operating in. And the appearance of an HSL color will change depending upon the RGB space it's operating in. (i.e., The color values H: 30 S: 100 L: 50 will appear one way in an sRGB colorspace, and appear differently in an Adobe 1998 RGB color space.) Right? So, HSL is not device-independent like CIE Lab.

@Sean P There are a number of questions and concerns I have with regard to the Color and Swatch Panel UI designs that I would like to call to your attention: First, a question: how are we to understand the HSL color model? Is the HSL color model an alternative to the CIE Lab color model for describing the entire gamut of color visible to the human eye? If not, how are we to understand the size and limit of the HSL color gamut? How does it compare to CMYK, or sRGB? Second, I have a concern about being able to define a color/swatch that falls outside of the color gamut of the document's color space without warning. We understand that the size of color gamuts for some working color spaces are smaller than others, and that a color that is visible in one color space (e.g. sRGB) may fall outside the color gamut of another color space (e.g., CMYK). Given that the Affinity UI allows the designer the option of defining a color/swatch using sliders and wheels of various color models (i.e., RGB, CMYK, HSL, LAB), there is the risk of a designer specifying a color using RGB slider values that falls outside the color gamut of a document's CMYK color gamut without any warning from the software UI. It would be very helpful for the UI in all the various color editing and definition panels to flag color definitions that fall outside of the document's color gamut. Third, I have another concern related to the slider options made available to the designer when editing a color/swatch: simply toggling between color model options in the color edit panel will alter original color parameter values. For example, if I define a new orange swatch using HSL values H: 30 S: 100 L: 50, then double click the swatch to edit it, I get a contextual edit dialogue box with HSL sliders. If I toggle the color model pop-up from HSL to CMYK and then back to HSL, I find that the HSL values have changed to H: 27 S: 91 L: 54. Why should this happen? Is this the result of the software mapping an out-of-gamut HSL color to the nearest CMYK color and then translating that color back to the HSL color space? Fourth, another question: as documents may be repurposed from screen to print, and vice-versa, and as swatch collections may be saved, shared and reimported across many documents in a project, would it be helpful to somehow graphically identify swatches as having been defined in a particular color space, or would it be best for the software to keep track of the device-independent Lab color space definition, regardless of what color space the designer defined the color/swatch in? I'm sure there are many other questions to be addressed here, but the general concern is that the Affinity UI should be improved to make it easier for the designer to accurately specify and manage color with confidence and to be warned when a color is outside the color gamut of the current working document.

@retrograde @MattP Hmmm. You got much better results in converting your stroke to outline. Did you draw the stroked curve with the Pen tool or the Brush tool? Using a Wacom tablet, I selected the Brush tool with a basic round brush and drew a freehand curve. I converted this curve to outline, and got 7-8 nodes at the end points – not the elegant 3 nodes that you got. Does it matter whether one uses the Pen or Brush tool?

Is there a Preview Panel in any of the Affinity apps that would allow one to check for correct color separation in documents where spot inks have been used?

Why is it that when one applies and adds a Pantone spot color to an object in one's document, that the swatch for the Pantone spot color in the Swatches panel is labeled generically "Global Color X" by default, rather than being labeled by the actual corresponding Pantone spot color number? (See attached screen grab.) If we're wanting to manage inks, including spot inks, within our documents, swatch collections, and files sent to offset print services, shouldn't the Affinity software correctly label color Pantone color swatches by default as they are added to the document Swatches panel?

@firstdefence Thank you. That's a very clean and efficient solution.