Medical Officer Bones

PDF might be an option. At least for regular and rotated text. Most editors import PDF with text intact. Or perhaps use transparent PDF form fields for your map text with text already filled out, and center text aligned. But curved and distorted text will always be converted to a graphic object, and no longer be text. Alternatively, provide your maps not only as a PSD, but also other native formats (Inkscape, Affinity, ...) And if you do need to provide PSDs with full text editing functionality, you may have to invest in renting Photoshop or get an older CS6 version, or something. Perhaps even the CS2 version will suffice? I mean, if this is important to make a living, I don't think it is a good idea to ignore what your users use as software. Better to accommodate them. I still use an older version of CS6 of Photoshop to deal with these cases myself.

Had a quick look at the 1.7 beta today, because one of my pet peeves of Photo are the small layer thumbnails in pre 1.7. When I first saw this mentioned as an improvement, my spirits skyrocketed...! ...only to crash and fizzle out. Three fixed thumbnail sizes? Even Photoshop offers up to 80px. (which is still too small a max) I hate to be a party pooper, but... Why limit the software to only three fixed layer thumbnails sizes, of which the largest one is still too small (62x62px) for many users, screens, and use cases? Why not introduce a seamless slider and a minimum of 5 presets, and an upper limit of at least 192px or even 256px? Well, I suppose it's an improvement. It is better than before, and usable as opposed to pre 1.6. A bit of a missed opportunity.

Following the reasoning of the OP, ink colours on paper are subtractive, while colours on the screen (RGB) are additive. 100% CMY on paper produces a muddy brown. 100% RGB produces white. So I assume the OP expects that working in CMYK mode should be behaving likewise. But blend modes always work in screen colour space, as far as I am aware. One solution is to turn on overprint for those objects in Designer, for example.

Photoshop's 3d functionality is terribly outdated, and the rendering almost completely useless. Those haven't seen any core updates since their first introduction. Don't bother with those, excepting perhaps the odd 3d text effect. But even then a quick round-trip into Blender will yield a hundred times better and faster result. Affinity Photo is far better served by introducing improved support for rendering compositing pipelines, rather than the team spending any development on 3d functionality that is already available and proven in many existing 3d tools, both free and commercial. "Cobbler, stick to your last", as the expression goes.

The market is saturated with excellent animation applications. Just a few production-ready alternatives for Animate CC (in no particular order): OpenToonz, CelAction2D, Moho Pro, ToonBoom Harmony, TVPaint, After Effects, Fusion/Nuke, Blender (with Grease Pencil animation)... And these are only the start, with many lower-level apps out there, as well as 3d animation software which can also be used for 2d animation (Maya, etc.). Tough market to compete and survive in. Serif probably feels the same, and is not planning a dedicated animation app.

I would consider this a bug, not a feature request. Windows version is also affected. Imagine this situation: the file dialog is smaller than one of the GUI panels. The user attempts to save the file, mis-clicks, and the file dialog is hidden beneath that panel. Unless the user is aware of what just occurred, the user may assume that the app no longer responds. Showstopper! This can be categorized as a user interface BUG, not a feature request. I have NEVER experienced similar behaviour before in any Windows or Mac app. This is a first! Very interesting oversight on the part of the developers. Definitely should be categorized and labelled as a bug. ...and I am going to use this as another clear example in my UX design classes of "How Not To Design A User Interface". I've got a couple of other great Affinity GUI examples which are already part of that list.

I need 1-bit support for my comics and illustrations. Currently I use PhotoLine for this, which surprisingly has perfect support for this, even better than Photoshop or any other image editor out there: works with layers(!) Meaning, unlike Photoshop it's no problem to combine multiple 1bit layers. can be combined in a single document with RGB or CMYK 300ppi layers and create a top 1bit 1200ppi layer PDF output in PhotoLine keeps it all intact, and outputs a proper PDF file. The 1bit 1200ppi layer is retained, and the colour work maintains a 300ppi output. InDesign also works well with this, but I no longer rent that software. The only other software I found so far (other than QuarkXPress) that supports a good 1-bit workflow is PhotoLine. And I know of no other image editor that supports a layer-based workflow with 1-bit graphics. I am hoping that Affinity Publisher will support this workflow as well, but so far no cigar. I think all Affinity products ought to support a 1-bit workflow to make this work out properly anyway. (And an 8-bit indexed colour mode is missing in action as well in Affinity Photo, btw!)

The .NET framework is the cause for this limit, which only allows for a maximum object size of 2Gb . Windows itself can handle larger PNG files just fine without issues; it's just that Affinity for Windows is built with .NET framework, and "inherits" this limitation. For example, I can export a 33.000 x 33.000 large image to PNG in PhotoLine. I can open this in IfranView for viewing. ImageMagick works fine too with these images. Attempting to load a 33.000x33.000 PNG image in Affinity crashes it, probably due to that .NET 2GB heap size limitation. Anyway, most image editors will put a limit on max canvas size as well: Affinity can handle up to 256000x256000 pixels, while Photoshop goes a bit higher by supporting 300000x300000 pixels. PhotoLine doesn't seem to have a limit, and will happily output a million pixels (which does seem to become problematic for Windows at that point to generate a thumbnail, and Irfanview refuses to open that file). I've worked with very large images for academic purposes in the past, and Photoshop's max px dimensions were causing us headaches at the time. I am actually a little surprised to discover today that Affinity Photo's dimensions 'only' goes up to a 256000 px size: I would have expected more. But it is of course more than enough for 99.9% of users.

Use X-Mouse to remap your right mouse button to behave like the middle mouse button. Tested in Photo, and works like a charm. I use the portable version. https://www.highrez.co.uk/downloads/XMouseButtonControl.htm I remapped the side buttons on my mouse to behave like the middle mouse buttons. X-Mouse allows you to remap the mouse buttons for each individual app you use, if required.

Ha! You think Tinypng does a good job? Colour Quantizer produces even smaller PNG files, AND at a (much) better quality. The problem with Tinypng is that the user has little or no control over the conversion, while CQ includes a simple to use quality mask brush to indicate areas that must be retained in regards to quality and colours. And a slider option to favour gradients versus colours and a threshold for rare colours. Also complete control over the indexed colour palette, including the option to load up your own custom palette. Did I mention the fine dithering controls? Nothing else comes close to the level of quality control and compression of PNG files possible with CQ. No need for the web, because CQ is a portable 1.32mb small executable. http://x128.ho.ua/color-quantizer.html

With Atom and Pinegrow you do get the 2-sided workflow: select an item in the visual view, and Atom highlights the code part. Vice versa, in Atom place the cursor in an element, and hit CMD+ALT+P, and it highlights the element in Pinegrow. Type in the code, and it updates the visual views in Pinegrow. Change something in Pinegrow, and the code updates in Atom. Server-side PHP, ASP works as well, but must be activated in the library and component manager. The support is okayish for front-end work, but indeed needs more work. Changing one's core workflow and tool pipeline is always a hassle, I agree.

You haven't looked at Pinegrow + Atom or Visual Studio then. https://pinegrow.com Pinegrow is a full WYSIWYG editor, with support for Bootstrap, Foundation, Google Materialize and regular html. Drag components into the view, create template components, live javascript testing in the view, multiple views of breakpoints, visual CSS editing... The list goes on and on. And with the live connection with Atom or Visual Studio anything you edit in either the visual view in Pinegrow or the code editor both update in real-time without having to save. Dreamweaver is quite limited, compared. Best of all: Pinegrow is quite inexpensive, and is a full license! No rental crap. Atom or Visual Studio (or both) are free. https://atom.io/

Unfortunately, Affinity "remembers" tool or colour settings for each separate document, and will not use your colour settings between documents. That is just how Affinity seems to work. As a work-around, save the colour as a colour swatch, and select the colour swatch when switching between documents. A new document or image that is opened will always reset the colours to black and white. Frustrating, I agree. As far as I can recall, Affinity is the only design software which displays this behaviour. I wouldn't really know why this workflow would be preferable: to me it also makes little sense. Resetting to the default colours seems more like how a developer would solve this, rather than an artist or designer.

Click the crop tool button, and the entire canvas is selected. Drag anywhere in the image to create a new crop. No need to adjust those four existing corners. That said, it *IS* a bit of a hidden affordance: it looks as if the crop must be adjusted using the initial full-canvas crop handles, but this crop is cancelled the instant the user starts dragging a new crop. PS I noticed it is not possible to start a new crop by dragging outside the existing canvas: Affinity assumes that the user wants to rotate the existing full canvas one in this case, which is frustrating when attempting to increase the canvas size to add a border white space. Unless I am missing a shortcut option here, or something. And it doesn't seem possible to drag one of the handles and have the crop proportionally scale from the center outwards. It is also not possible to perspective distort the crop marquee.

Yes, of course, I was merely quoting Krita as an example to explain that even if Affinity would become available on Linux, it wouldn't convince many users to Linux. Only a handful compared. People like SrPx and myself, perhaps, but of all the designers and students who I encountered throughout the years? Hardly anyone. That would probably include myself The question is whether this tiny fragment of users would be sufficient to make it worthwhile for Affinity or Adobe? No. Of course it is subjective! And that very subjectivity prevented other "better" or more advanced technologies to gain the upper hand in the market before. Mac is the preferred choice, for many historical reasons, subjective reasons, and emotional reasons, and so on, and so forth. Unless something dramatic occurs, humans are incredibly inert to overall change, self-oriented, and tend to be (very) short-term bi-polar minded thinkers. To the point of destroying their fragile little planet. Which explains why Mac, Windows, and Linux users often find themselves in a scuffle over something so inane as which OS is "the best". Utter waste of time and energy, of course, but that seems to be the human condition rearing its ugly head again and again, to the detriment of humanity. Perhaps. I think it is more complicated than that, and far more factors are involved, and not a black-and-white situation (nothing ever is: it is human nature to turn things into a yes-no thing). I highly doubt the impact of releasing Affinity on Linux would make even a noticeable dent on Linux as an OS of choice for designers. Like @SrPx stated in an earlier post, the issues run deeper than that. This is not a matter of simple "chicken or the egg". If that were so, someone would have released a successful high level design application on Linux by now.