Mark Oehlschlager

@wgwild Unfortunately, Publisher only allows for two levels of nested styles: the base paragraph style; and a single nested character style indicated in the "Initial Words" panel of the paragraph style window. We should continue to lobby for multiple nested styles here on the Affinity Forum.

@Adam Simon Some things are definitely handled differently in Affinity, and leading is one of them. In Affinity, standard leading (line spacing) is actually set in the Paragraph panel, NOT in the Character panel. What looks like a leading attribute field in the Character panel is actually a "Leading Override" attribute field. Presumably it made some sense to the developers that someone would want to override the leading values set in the Paragraph panel, and so redefined the leading field in the Character panel to function as a leading override. I have no idea why they designed the software this way. It makes no sense to me.

Have just installed the 1.8.1 updates for the entire Affinity Suite. All of the Zoom controls appear to be broken. Double-clicking the Zoom Tool does not set the document zoom to 100% Double-clicking the View Tool does not set the document to zoom to fit. Selecting a zoom percentage from the contextual toolbar's Zoom pop-up menu does zoom the document, but the change is not accurately reflected in the Zoom slider. Selecting a zoom percentage from the contextual toolbar's Zoom slider does zoom the document, but the change is not accurately reflected in the Zoom pop-up.

UPDATE: Although I gained access to the install button by going to the "Purchased" tab of the MAS, and was able to download and install the 1.8.1 updates, the MAS interface continues to prompt me to install both Publisher and Designer (though not Photo). Very strange. I don't know whether this has to do with the way that Apple is handling the Affinity apps in the store, or that it has something to do with a broken behavior of the MAS for Macs still running High Sierra (OS 10.13.6) like mine.

@wonderings This approach worked for me. I went to the "Purchased" tab of the Mac App Store, was asked to log in again with my Apple ID, and voila, the updates were available for me to install. Thank you.

@R C-R Yes, I'm sure. I'll wait to see what develops by Monday.

@MEB Thanks. I'll wait to see whether or not the update appears by Monday.

@MEB I am signed in with the same Apple ID. For what it's worth, this is my situation: 2012 iMac running Mac OS High Sierra (10.13.6) Installed released versions of Affinity Suite 1.7.3 Installed Beta Affinity Suite 1.8.0 How many days would you recommend to wait for the updates to appear in the Mac App Store?

@MEB Thanks. I just checked the individual app pages in the Mac App Store. Unfortunately, I only see the option to purchase. Perhaps the update has not yet been rolled out to California?

@Patrick Connor Thursday, Feb. 27, 2020. I'm not seeing the 1.8.1 updates in the Mac App Store. Is it possible that my installed Betas are interfering, or do I just need to give it a few more days?

An old problem with units in the Guides Manager being rounded to a single decimal place persists even in the latest Affinity Beta apps. (See screenshots below.) For example, in User Interface Preferences, I've indicated three decimal places for "Inches", but when I go into Guides Manager and attempt to set a margin at 0.25", the displayed value is rounded to 0.3". And when I attempt to set a margin at 0.625", the displayed value is rounded to 0.6". The rounding errors also occur in the Column Guide Gutter field, as well as the Spread Origin fields, though not in the Horizontal or Vertical Guide fields. Please investigate and fix. Thank you.

Very glad to see the Affinity Apps import Adobe "Smart Objects" as equivalent "Embedded Document" layers. I have a few questions: In Adobe Photoshop, the primary usefulness of "Smart Object" layers is the ability to apply non-destructive distortions and transforms to the layer artwork. Do you plan for "Embedded Document" layers to share the same functional property? In Adobe Photoshop, one can right click on a layer and convert it into a "Smart Object" layer to be used in non-destructive distortions and transforms. Do you plan to add that functionality to Photo? Can one right click on a layer in Photo and convert it into an "Embedded Document / Smart Object" layer? Is there a plan to allow both the Perspective and Mesh Warp tools to be applied non-destructively to "Embedded Document / Smart Object" layers? This is relevant to those of us who build mockups of packaging and 3D objects, where the need is to convincingly shape and apply logos and other artwork to boxes and bottles, and still have the ability to replace the artwork in the "Embedded Document / Smart Object" layer. Is there any chance that Affinity "Embedded Document" layers can be exported out to PSD files as "Smart Object" layers rather than flattened raster layers?

@chippwalters No. Nothing new on this front.

Very happy to see the Photo Beta add the ability to preserve PSD Smart Objects. Just to clarify what current capabilities are: • Affinity Photo will preserve PSD Smart Objects by treating Smart Object layers as Embedded Documents? • The Embedded Document layers can be operated on non-destructively? • When exported back to PSD file format, the Embedded Document (Smart Object) layers will be flattened into regular PSD layers?

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

@MEB I tried once more, paying close attention to your recommendations. Here's what I found: When the document units are set to pixels, the width/height and X,Y coordinates of the rectangles are integer values, and they are they are aligned with the pixel grid, the gap between objects disappears. If I switch the document units back to points, the gap reappears. So, I guess the screen draw issue is connected to document units. Attached below is a sample AFdesign file, as well as a screenshot of my "Decimal Places for Unit Types". GapTestFile.afdesign

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.