Medical Officer Bones

For comparison's sake, the new v4.2 preview of Krita introduces a nice small slider in the layers panel to control the thumbnail size on the fly in a seamless fashion. While the user had no control over thumbnail size in the pre-4.2 versions, a useful option exists: when the user hovers over a layer, a larger version is displayed in a pop-up, which also lists that layer's properties. I really do hope layer thumbnails in Affinity will have a similar 'zoom' function at some point. It has been discussed in another thread that Affinity's layer panel is hampered with other usability issues, and (in my opinion) is crying out for a 'make-over'. That check box is a usability abomination (sorry). It's been discussed in that other thread (can't find it right now).

Agreed. Up till this day I am still surprised (and somewhat shocked) to see the lack of webp export in Affinity. In my mind it makes very little sense NOT to have it, in particular keeping in mind that Affinity is a modern application. I had expected to see this supported in v1.7... Alas! It was not meant to be. What can one do? Let's hope it is implemented by the time v2.0 surfaces in a year or two. In the meantime we are reliant on external tools such as Color Quantizer to finish the job.

https://www.xnview.com/en/xnviewmp/ XnViewMP is another free 'Bridge' alternative (at least for personal use). @Sharkey Perhaps that will do the trick on your Mac?

This is not very widely known, nor advertised by Adobe, but Bridge is completely free and no license is needed. Might serve as a temporary solution for some. The file associations must be set in the preferences. And there are obviously a number of limitations related to not having Camera RAW installed. But is otherwise fully functional, and free. Even contact sheets can be prepared and output to PDF. And I just discovered it will even show a list of linked assets when inspecting InDesign files, which is pretty neat. https://www.adobe.com/products/bridge.html Direct links here: https://prodesigntools.com/adobe-cc-2018-direct-download-links.html The direct links download much faster than going via CC. The only issue is that Bridge requires around 1gb of space, which is a 'smite' overkill in my opinion.

As far as I am aware none of the Affinity products work well with 1bit bitmap files. For example, 1bit high resolution tiff files @1200ppi do not render properly at their original resolution when output as a PDF. Affinity Photo does not even support 1bit bitmap files. 1bit bitmap support is just not there yet in either Photo or Publisher. We will have to wait and see, but I have an inkling that this situation will not be resolved before version 2.0, or perhaps even later than that.

While I applaud the inclusion of a live non-destructive procedural texture filter, asking your users to write mathematical formulas "sort-of" hampers creativity and texture exploration while designing. It's not a very conductive approach to quick experimentation, and the way controls are implemented is kinda clunky as well. I remember asking the Photoshop devs to integrate some kind of procedural texture generator, and they never did (aside from the terrible uncontrollable clouds filter and a few simple noise generators). This is understandably a rough first version of the procedural texture generator, of course (I hope, at least). The Affinity dev team could take their cue from other applications how to take this to the next user friendliness level: Filter Forge uses a nodal system. This is, in my opinion, the most flexible and usable visual approach, although perhaps not the most intuitive one for designers. PhotoLine uses a more traditional dialog approach, and applies these as a texture fill with full visual control over placement with a nice fill widget to control transformation. The advantage of having these as a regular fill option is that procedural textures also become available in layer effects, for example. Substance Designer also opts for the nodal approach: Substance Designer does a quite nice job making this rather intuitive and relatively easy to use (in my opinion). Another example of nodal based procedural texture generation is Neo Textures: I would love to see Affinity's procedural texture filter to have simple node-based controls. I really think it is the best way to go, in combination with the level of control that PhotoLine has to control these textures with an on-canvas control widget. Perhaps separate the colour controls from the texture controls as well? Not sure. And allow the procedural textures to be used as a Fill too. The Affinity dev team probably wanted to get something working, and might be expecting the community to come up with new presets. Which is a half-way solution in my opinion. I regularly open FilterForges node editor to make some additions and adjustments to existing filters, and I expect that presets will only satisfy a subset of user cases. As its stands, you can't really expect the average designer to dive into math to experiment visually with the new procedural texture filter. It's not very intuitive or open to visual experimentation in its current state, and is in dire need of GUI exposure. Even G'MIC's procedural patters expose all the controls and only provide a list of pre-made patterns, and I think that is preferable, with its built-in limits in regards to presets, to a math editor. To cut a long story short, I hope the Affinity devs will be exposing the internal math to some kind of GUI controls, without the need for typing math expressions, and to open this up for quick visual experimentation and creative control. Because its creative potential is there.

I checked all your photos, and aside from the very first one (the box), all more than suffice in regards to pixel resolution (4032x3024px). What you would have to do is change the ppi resolution parameter to 300 or 600ppi without resampling the images (the current set ppi is 112ppi). At 300ppi and no editing they would print at approx. 34 by 25cm, and at 600ppi they'd print at approx. 17 by 13 cm. Which means in terms of pixel resolution it is more than enough. Steps: open your image, document-->Resize Document, turn off "resample", change DPI to 300 (or 600 depending on your needs), and click "Resize". Export a new JPG (File-->Export). The trouble with these photos is the rather fuzzy and compressed image quality, but that is to be expected when taking pictures with a cell. And the lighting conditions are less than ideal, of course. Things could be improved a tad with standard image corrections, but only up to a point. The book, for example, is photographed from a poor angle. The outdoor evening shot shows a lot of noise, and wouldn't print very well. Details are lost here. That said, you'd get quite reasonable greyscale print quality with some processing for the other ones. A bit of denoising and unsharp masking goes a long way to improve the overall look. After that you could scale them down 50%, sharpen a bit more, and apply some tonemapping, lift the shadows, and use a s-curve to improve the overall quality more. And finally use the Black and White adjustment to convert to a good looking contrast rich greyscale version. Ideally use the free NIK Silver Efex 2 for a good conversion. Then do a print test on high-quality paper. But as far as resolution goes, these should do. I wouldn't want to print these at 600ppi, but at 300ppi and scaled down by 50%, they'd be quite acceptable after some processing. Example image: this will print at 17cm by 12.8 cm at 300ppi. PS don't forget, PPI merely tells a layout application and the printer at what dimensions the photo would be printed relative to the pixel count.

In more general terms, I think this would be (FXL) EPUB 3 export? I whole-heartedly support this. Apple's *.ibook format should NOT be explicitely supported, because it breaks the epub v3 standard, and is Apple's proprietary undocumented version of epub. Whether epub export will be supported by the Publisher devs is very doubtful, since they already stated they do not intend to support html export (and since epub is based on the html and css standard...). But if Publisher WOULD support both fixed layout (FXL) and flowing epub export, and integrate video, sound, links, state objects, and animation options, then I think they would hit the road running. But I doubt Publisher will have this export option - perhaps in 5 or 6 years?

Last week I worked with LibreOffice's diagramming tools for the first time, and those were actually pretty good. Nice auto-connect arrows too, with the option for automatic linear or curved arrow paths. And free! When I was done I exported as SVG and imported for some polishing up. Worked fine. So I second v_kyr's suggestion to look into that.

True, it looks clunky, but at least it is functional and is very understandable. Affinity Photo's layer stack doesn't really look much better, though. And is not as readable. Compare the layer stack below, and I think that's pretty clunky looking as well as completely unreadable. I have no idea what is going on in that list. I certainly hope v1.7 will introduce a thumbnail size setting. But you are correct that adding all layer parameters in the layer stack creates its own set of issues. So what do we go for? Form over function, or function over form? Or a good balance between the two? Myself I would prefer these things to be optional in a layer stack preference tab. It really depends on the complexity of the project. Perhaps a bit more like Krita's layer stack (the newest beta release has a seamless thumbnail size slider) where the user is able to quickly hover over layers and an overlay is displayed (see the right screenshot)? It almost looks like a hybrid between Affinity Photo and PhotoLine. Designing a good looking and easy to use/understand layer stack is quite a user experience design task. Perhaps a completely new and novel approach is required.

@hifred Here is an example screenshot. One could argue that it looks a bit clunky and different, but aside from that, once you get used to the icons, it works really, really well. Everything that's going on that is important to know about is directly exposed: image blend modes are indicated, opacity percentages, the layer type, the adjustment layer type is indicated with an icon, curve adjustments are shown as a thumbnail (love this myself!), which layers are editable, select-able, and or locked, whether an advanced layer blend is applied (fourth layer small icon), which layers have transparency locked, which groups are drawn isolated (asterisk)... and of course layer effects (here indicated with an 'S'). Instead of having to click on each layer to inspect what is going on under the hood, here we just glance over the layer stack, and understand what is happening in this file. I find other image editors' layer panels to be very awkward and inefficient to work with compared - even the "industry standard" Photoshop layer panel (aside from the missing drag option). For those who are wondering about the checkboxes: these serve as a visual indicator for multiple layers selected, but also as a way to use the mouse only to select multiple layers: something that would require a modifier shortcut key on most other image editors. It's quite handy when working with the Wacom tablet. What is missing compared to Photoshop: it is not possible to drag-select layer visibility, unfortunately. For the rest I prefer this layer panel over Photoshop and other image editors/painting tools. (on a side note: PhotoLine's painting tools are however not in the same league as Affinity Photo, let alone compared to the ones in Krita.) What is also nice is that Corel users can adjust layer navigation options to use the cursor keys to navigate the layer panel. I like the configuration options related to the use of the layer panel as well. And the fact that the user can zoom in and out of thumbnails on the fly by holding down the ctrl and scroll wheel.

@hifred I believe Sparkle saves single project files, and the now defunct Adobe Muse shares that same approach. As you mentioned, Xara saves the pages as one file too. The question you would have to ask yourself is whether this is a good approach or not. Html, CSS, Javascript: these are all open human readable files, and the entire point of the web is open technologies. When relying on a closed file format like Xara, Muse, or Sparkle you become entirely (or mostly) dependent on that software to manage the site, and all three write rather abysmal code that cannot be handed over to a programmer in good conscience: they would have to start all over, because it is entirely human unreadable. I suppose it is fine when dealing with simple sites with a simple structure, one-pagers, or flashy portfolio sites. But if the design must be integrated with a content management system (CMS) and/or database driven content with a server back-end, or even be converted to a mobile app... Well, let's just close with this: it is a Very Bad Idea to rely on pure visual web page building tools that 1) are unable to work directly with (existing) html files, 2) rely on a proprietary file format, and 2) output code that is only machine readable and a mess. Tools such as Muse, WebPlus, and Xara all work with a separate design layer which must be converted to web code. This is hard to maintain (by the developers), hard to keep the design layer updated with the latest web technologies (which often change on a yearly basis or more often), and that custom design layer cannot hope to emulate an actual web browser output, so the so-called WYSIWYG view is only an approximation of the real thing (can't test javascript right in the view, for example). No wonder Adobe and Serif had to throw in the towel with Muse and WebPlus: the web goes too fast to keep up with such a proprietary tool with an abstracted design layer. It's unmaintainable in the long run. Muse had become an obese dragon of an application. Not to mention the hardships related to designing and testing responsive layouts in these kind of tools. And I am not even mentioning the trouble and frustration related to one-file file corruption issues, and thereby losing the entire site. That is to say, a versioning/file backup feature should be either integrated and/or it should be compatible with the tools you use for web site creation. A single-file approach for web development is (sorry) just a really bad idea, and adds one more unnecessary layer between the output and yourself. That is not how web pages work. and it is a severely limiting workflow anyway. These tools cannot be integrated well in a team environment at all. So, unless simple static web work is what you do, and you are not involved in a team (you're working on your own), and you don't mind running the risks of depending on a proprietary design app and file format, then one of these tools might fit the bill. Anyway, long explanation to tell you that I think, that unless you are making very simple static sites, it is better to stay well away from such tools, and only choose tools that work directly with the html, css, js, less, sass, etc. files themselves. You should be able to open an existing web page or site in these tools, and be able to edit the code in a visual environment which is based on an actual web browser view. And this workflow is compatible with a team, as well as a file versioning workflow (like Git(hub)). Pinegrow keeps an automatic local file history, and all changes are recorded. For me that means Xara, Muse, Sparkle, online solution like WebFlow and the like, and WebPlus are always going to limit you in some way. Wappler is better, but doesn't allow for CSS frameworks outside the ones they support directly, and that leaves Pinegrow for me and my frontend development work. But it is possible to combine both Wappler and Pinegrow in your workflow, because in the end they both work directly with the actual web files. And in a good human readable way, so anyone with a bit of html and css skill will be able to open the code in a code editor and make changes. I can open a Wappler website directly in Pinegrow, and continue to edit it. Can't do that in Muse, Sparkle, WebPlus, Xara, etc. In short, even if Pinegrow would met its demise in the future, those Pinegrow-built sites are fully editable with other open tools. Compare that to Muse or WebPlus users.

Most of those are related to the lack of database/server connectivity. Pinegrow does have a similar project manager as Wappler, although Wappler can use FTP to connect with your webhost folder. I did try out Wappler, and the GUI is still very VERY behind compared to Pinegrow. For example, in Pinegrow the same page or different pages can be viewed for various devices simultaneously, side by side. The interface in Wappler is almost completely static, and panels cannot be moved around. The styling controls in Pinegrow are far more user friendly and better exposed for CSS than the ones in Wappler. It is one thing to compare and cherry pick base features between applications, but an altogether different thing to actually experience how these are implemented, and how the overall workflow and GUI respect the user's preferences. Pinegrow is light years ahead of Wappler in terms of configuration. And supports a live connection with Atom and MS Visual Studio Code for code editing. And many more things related to front-end development which are unavailable in Wappler. The main difference between the two is that Wappler can connect to live data in a database, which Pinegrow cannot. However, Pinegrow does support direct WordPress theming in the WP edition, which allows for quick WP theming, and via WordPress data does become live. Wappler does not support WordPress. Via WordPress a tremendous library of free and commercial plugins for just about any requirement opens up. While Wappler allows the user to create their own custom database functionality, in comparison the WP ecosystem delivers just about any database functionality you would ever need. And WordPress delivers a user-friendly back-end interface out of the box, while in Wappler you would have to develop it yourself (and you'd never be able to match it on your own). Pinegrow's WP edition supports custom data bindings through the Advanced Custom Fields WordPress plugin (which then pretty much delivers what Wappler delivers). But getting this far with the WP edition requires a good understanding of how WP theming works. Wappler is much easier to understand and learn in this respect. So it really depends on what your needs are. Pinegrow is a much more mature application, in particular for front end development and its interface and workflow is quite flexible and adaptable to users' preferences, and Wappler offers custom database connectivity, but as an application still needs a lot of growing up in my opinion. In short, don't rely on those cherry-picked feature comparison lists from either side. Test for yourself, and allow for a week of testing for each product.

You have several options open to you, with (1) being the closest to WebPlus in regards to workflow, to (6) being the least similar: Xara Designer Pro or Xara Web Designer (Premium). These offer a way of working that is closest to Webplus: completely visual, and pretty much a regular Publisher type layout application, which converts directly to a working website. Responsive pages are also possible. Sparkle. Not as flexible as either WebPlus or Xara, but no code in sight. And generates quite acceptable code. Around $99 for the pro version. Mac only. https://sparkleapp.com/ Wappler. Still completely visual, although works with blocks. Also supports full database-driven websites. Free version, up to 49 euros per month for the full version. Service based, no full license, unfortunately. https://wappler.io/index Pinegrow. The next step "up" from a typical visual design tool which actually works directly with html and css code, and outputs human readable code that actually is quite clean. The workflow is different though. It is column and row based, and the html and css code is accessible and directly exposed to the user through its interface. Basic knowledge of html and css is preferred. $99 for the pro version, which is really needed for multi-page sites. https://pinegrow.com/ WordPress. The upcoming v5 version will include the new Gutenberg editor, and introduce easier visual editing of content. Or download a visual editor plugin such as Elementor. Free for the most part. Learn to code html and css properly, in combination with a grid framework such as Bootstrap or Foundation. Free! Xara Designer Pro was up for grabs for $15 a while ago through a Humble Bundle, but that deal is sadly over. $99 for the Web Designer Premium version, or $299 for Xara Designer Pro. Personally, I feel Pinegrow is THE best visual WYSIWYG web page editor on the market today, but it does require some html and css knowledge. If the prospect of coding puts you completely off, then try option (1), (2), or (3). All have free versions or a trial (Xara). WordPress doesn't require coding either, but you do need either online hosting, or a local webserver to run it on. PS many online visual website editors have vied for attention since the demise of Adobe Muse. All of these only work online in a browser and require a subscription/monthly rent. I would avoid these myself

The lack of a custom layer thumbnail size has been discussed to death before. It is only one of several GUI interaction design issues related to the Layer panel. Here is what happens with longer layer labels: As anyone can see, this is a less than desirable situation, and things will only get worse when a custom layer thumbnail size is introduced in the Affinity range. And I agree with your @hifred observation that a checkbox is the wrong indicator for layer visibility. There are a number of other design problems, and I again agree the entire panel should be scrapped, and rethought. For example, changing the blending range, changing the opacity, or coverage map: none of these are indicated in any way in the layer panel to show the user that a specific layer happens to have other settings applied to. Layers cannot be tagged with a colour either, nor is a search option provided to filter layers. And it is not possible to drag-select like in Photoshop. But in this respect Photoshop is lacking as well. With both apps the user must select a layer first before it becomes clear which opacity and blend mode settings are applied. The only application that I know of that does include this information for each layer is PhotoLine, and that works very, very well. Looking at a layer comp in the layer panel immediately tells you how things work. I wish other image editors would allow for this, or at least include an option. Anyway, the way the layer visibility controls are handled in Affinity reminds me of how a programmer would solve it. But it is only one of a whole list of layer panel issues and limitations. I do hope the developers are working to solve and improve these, but I was hoping to see some much-need improvements in the beta of Affinity Publisher, and noticed how little has changed. Publisher is presumably the v1.7 version of the Affinity range? If so, we may be disappointed when V1.7 is released.

Having the layer visibility control on the far right is a usability problem, and plain bad user experience design. I agree with the OP: it's really frustrating to work with. The positioning of the checkmark breaks a fundamental interaction design law (Fitts's law) because the user identifies a layer by its thumbnail and/or label, and is then forced to follow the row to the right with their eyes to finally uncheck the visibility. But since the distance between layer identifier and the checkbox is relatively large, the eye will often re-check whether the thumbnail is the correct one in a document with multiple layers. I started noticing my eyes' behaviour even with just 5 or 6 layers, or so. The visual grouping of the control is all wacky. Aside from the distance, the tiny checkmark target exacerbates this usability issue even further. It really is quite terrible UI design on display here. Beautiful example of how not to implement this basic task. This design decision would be understandable if the task were a hardly-used one, but controlling the layer visibility is quite a fundamental action, and used all the time during work. I am unsure what the developers were thinking when they decided to put this action so far away from the layer's visual and textual identifier. This really is basic 101 interaction design theory. Having said this, perhaps Adobe has a copyright on this particular interface design? Refer to this simple explanation of Fitts's Law: https://lawsofux.com/fittss-law

Currently picture frames in Publisher have no option to display invisible boundaries when the content is being edited (but from forcing matters by applying an actual stroke), nor is it possible to see the cropped parts of image content when dragging. Very awkward indeed compared to InDesign. I do hope they will add these features. In my opinion the trouble with the Affinity line is that many features, while good looking on the surface, fall a bit flat after the user digs a bit deeper in terms of basic workflow efficiency. Then again, the competition has had decades of user input to guide them, so it's a bit unfair to compare too much. Still, I'd like them to focus more on the small things, the foundation. And pay attention to the needs of higher level usage more: a fair number of rather essential things are severely lacking or completely missing. Well, I have patience.

Btw, a secondary issue is that the picture frame hides the cropped content while dragging the image. That is very problematic under circumstances: suppose I'd be importing a set of architectural drawings/views that are laid out on the same canvas in various spots. I need to re-arrange these views in my Publisher document, and therefore import the same file multiple times in my document to crop each view independently. Now, here we discover that when the content is scaled and moved around, the picture frames obscure the rest of the drawings, making it incredibly inconvenient to place and crop these properly. That is not the case with InDesign: dragging and repositioning a picture frame's content displays a semi-transparent version of the cropped content, and cropping a set of drawing is easy-peasy. Now, that is, unless I am completely dense, and I have missed an obvious setting or option in Publisher.

Because double-clicking it would be an invisible action in the screen recording? It does the same thing. Single-click: select picture frame. Double-click: select contents of the picture frame. Same behaviour as InDesign. What IS different is that the pictureframe has no visible bounding box. Other shapes used as picture frames neither do, making it very fuzzy and finicky to work with. In this case a visible bounding box is kinda a necessary ingredient for a smooth workflow.

Create a picture frame, place a cut-out image (PNG) in it with a transparent background. Double-click the image to decide on a crop. Result: invisible frame borders make it impossible to move the subject in relation to the borders without trial and error. If this is intended behaviour and no option exists to display the invisible bounding box other than forcing matters by applying an actual border stroke, I would tag this as missing functionality, and possibly a workflow killer. Let's hope the developers realize that this is a 'somewhat' odd missing option, and will see the error of their ways, or perhaps they just haven't gotten around to add this view option. We're still talking beta here, so...

For comic work it is absolutely essential to have the option in a layout application to overprint a 1bit 600ppi up to 1200ppi black ink layer over a 300ppi colour one. I tested this today for the first time in Publisher. While it imports 1bit bitmaps fine, I could not get it to output to a PDF that retains the high resolution black ink layer nor have it overprint a 300ppi colour one. It will either downsample and rasterize the 1bit bitmap to a 300ppi greyscale one, or just display a grey rectangle when I force it not to rasterize anything. It might be that I am missing a setting, though. So how do I output a PDF with the 1bit 1200ppi ink bitmap overprinting the 300ppi colour work? PS InDesign automatically treats 1bit TIFF bitmaps as overprinting objects, and will retain the original's resolution. In both PhotoLine and Scribus I turn on Multiply blend mode for the 1bit bitmap tiff, and it will overprint and retain the original resolution. But this does not work in Publisher, which downsamples the ink work.

May I ask why not? Will it be implemented in v1.7? Since you support webp import, adding export ought to be rather trivial. I use it all the time for preparing game assets in Godot Engine.

With shirt illustrations semi-transparency may not work as expected - and not supported with screen printing, as far as I am aware. It's better to work with halftones (convert your transparencies/transparent gradients), although direct to garment printing (DTG) is much less limited in this regard compared to screen printing. But even with DTG the transparency effect may look completely off when coloured transparencies are used on non-white textiles - white and black aren't that problematic. But even those could turn out different than expected depending. It is still considered good/preferred practice to convert your transparent values and gradients to halftones for the best result, no matter the printing method. Anyway, it means that for textile printing soft subtle transitions at edges between artwork and textile are rather unwanted, and sharp selections are preferred.

I think our memories often deceive us into thinking that things were 'better' or 'easier' in the past. This seems to be part of the 'human condition' with vast swathes of the population pretending the world was preferable to live in only 50 years ago. Software from the 80s and 90s was, let's agree, much more limited in regards to functionality, and thus easier to master. And hardware capabilities were quite limited as well at the time. I recall being limited to 32 colours from a palette of 4096 and working on a 320x256 screen resolution. I also remember feeling mightily impressed by the sheer graphical power of the Amiga. The first time my eyes feasted on Defender of the Crown? In my memory nothing tops that. From a nostalgic point of view the Amiga will always be my first true computing 'love', with the C64 and Amstrad CPC sharing the second spot. One application I often see mentioned here and other forums is Freehand, and the assertion that Freehand is still better than current vector drawing software. I worked with and taught Freehand a long time ago. It was good at the time, but certainly not better than current software - the GUI alone is old-fashioned and clunky. Functionality is okay. But again nostalgia plays an important role. That, and animosity towards Adobe for killing the software. When I compare drawing/painting software from back then (Deluxe Paint anyone? ) with the current Krita or ClipStudio... No competition, of course. Not even in terms of usability. Deluxe Paint or Superpaint didn't even have layers. I can't imagine working without layers nowadays. Some ancient tech never grows old, tough: I always carry pencils and a notepad around with me for a quick sketch on the road. I tried tablets for a while, but they're awkward, run out of battery, and break when dropped. The screens don't work well in a sunny environment. Drawing on glass felt completely wrong (I even wrap paper around my large Wacom). So after a couple of weeks I returned to ye old pencil and notepad. The 'screen' is always on, the memory never fails (drawings cannot fade away into digital oblivion). Works great even in sun light. Drop it from a ten storey building, and it still works.