Medical Officer Bones

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.

Depending on the source, Linux market share falls somewhere under the 2% margin. A checked a couple, and they tend to fall around %1.7-8? It is only part of the story: I think it is not enough to merely take OS market share percentages at face value: that is why I also mentioned that only a subset of Linux users would be interested in a commercial professional design application. Only a fairly small percentage of all users would be interested in investing the time and effort in learning a full-on professional level design application. Most users could not care less. The Mac platform is far more popular with graphic designers than Windows is, which explains why companies such as Adobe and Affinity invest in a platform which lingers around a deceptively small 10% desktop platform share. Windows is almost 90% of the desktop market, and while the relative percentage of graphic design users is probably far lower compared to Mac, the brute force of the numbers of users will more than balance out the difference. Linux has a far lower percentage of graphic design users than Windows AND a tiny market share. Is a market like that viable enough to jump in for Affinity or Adobe? I think both have done market research, checked the numbers, and their current Mac and Windows stats, and decided it is too much of a risk. I do think that if you are a game or app developer working on a development system that easily exports a Linux version, you would be daft not to cash in on that as long as you develop from the start on deploying on all platforms. But even in that case Linux fragmentation causes headaches to make sure your game / software runs on a broad enough range of Linux systems. And then there's the graphic driver issues between platforms, and Apple's OpenGL deprecation in favour of Metal. If Affinity code base could be directly converted to Linux, it might be worth it. But as it stands, the Mac and Windows versions use different GUI layers (as I understand it), and Linux would add a third one. Then to realize how long it took for the Affinity team to port to Windows... It is quite understandable why Serif is avoiding the fragemented Linux desktop platform. I wish it would not be so, but I myself wouldn't put myself in that risky business venture. Perhaps first focus on getting the Mac and Windows version up to version 2 or 3, and then take a second look at the market. Although at this point I tend to agree with the assertion that Linux is a failed desktop OS. Unless a miracle occurs, or MS and Apple pisses off their global user bases in a dramatic way, this will remain the case. Linux is extremely successful in other areas, of course. Civilization would come to a standstill if Linux would disappear overnight. But as a mainstream desktop platform for designers? Unfortunately not.

For you and me, yes. As I said earlier, I view myself (and, based on posts written by you and seeing your experience) you as exceptions. I haven't met many designers willing to be so open-minded about switching when certain software would be available on Linux. It generally isn't that simple.

@SrPx Your experience is identical to mine. I tried to switch friends and family to Linux, mainly because the only tasks involved were web browsing and a spot of text processing. Almost no-one liked it, and asked for Windows or Mac after a while. The sole exception is my wife, who works on a simple laptop which used to run WIndows 10, and now runs Linux Mint. But the only reason she continues to use it, is because I am always there to help her out with technical issues and updates. Without me, she wouldn't know, and prefer Windows (even though it runs much slower on that machine). The one thing I HAVE been successful in convincing others to switch to: LibreOffice, Blender, and Krita. I actually got an entire college to adopt Blender for general 3d work, and so far almost every friend or family member is no running LibreOffice, without issues. And Krita has been adopted by various students as well. But as I stated earlier, and SrPx points out as well, software is only a tiny factor in choosing a desktop platform, or a mobile platform It does indeed run deeper.

PS the Linux users here probably resolutely refuse to switch to either Mac or Windows just to gain access to Adobe or Affinity design software. Instead, like the Windows users before, they ask for a version for THEIR platform of choice. Which sort-of proves my previous point: software by itself generally does not drive users to leave their OS.

They wouldn't. And Linux HAS design software that is very good (like Krita). But barring David Revoy, I haven't seen masses of digital painters move to Linux. He is the exception to the rule. I have seen quite a few digital painters move to Krita, but stay with their OS. In my experience, the availability of (niche) software by itself is probably not a major or viable reason to switch to a different OS platform. Much more is needed than that to make the switch (whether from Mac to Windows, from Windows to Mac, or from those to any Linux variant). When Affinity Photo was released for the Mac, many Windows users lamented the fact that it wasn't available for their OS. How many of these users made the switch to the Mac platform just because Affinity was available? Right, a negligible number, if any worth mentioning. Instead, they waited until it became available for their Windows platform. Software doesn't seem to be a major driving factor to switch to a different OS for designers, or most mainstream users. If it were, graphic designer wouldn't care about the platform they work on, but reality tells us something very different: Mac is preferred. So other reasons take precedence. Thinking that the availability of Affinity would increase Linux adoption rates across mainstream desktop users or artists/designers is most probably an oversimplification of a much more complex set of real-world factors. I don't think it would make even a small dent.

This is anecdotal. In two decades of working with web/graphic/screen/game designers and developers (both Europe and North America) and teaching thousands of students from all over the globe, I perhaps saw a handful of Linux users. In the past five years I haven't encountered any student in a digital design related program using Linux. It's either Mac or Windows for the by far majority of these type of users, simple as that. Young design students just do not see Linux as an alternative. I have had trouble enough to get them to try open source alternatives like Krita! That's not saying I would not like to see Adobe and Affinity release their software on Linux, far from that. I think if they would, Linux would become a more attractive choice for a certain sub-set of designers. I would make the switch, for example. But the fact is, no-one I've ever met and worked with in graphic/screen/mobile/web design related fields worked with the Linux platform. And I myself am very much the exception: barring one or two people, I haven't spoken to any designers who would even consider the switch to Linux (most don't even know what "Linux" is!). I agree it's a bit of the chicken and the egg problem. But that doesn't take away the issue that the Linux desktop space is tiny compared to Windows and Mac, and the fact that the desktop/laptop design folks prefer Mac and Windows. Or that the Linux desktop space is so terribly fragmented. Even Linus admitted last year (more or less) that Linux as a desktop platform is its own worst enemy because of the fragmentation. As has been mentioned earlier in this thread, it would make more sense to invest in a ChromeOS version. Linux in various shapes and forms is super-wide adopted all over the world in many situations, far more than either Windows or Mac; except for mainstream desktop users and certainly not in the world of graphic/web/general design. Tiny adoption rate as a platform & tiny subset of target users = no hope in heck to earn back your investment over a semi-long term.

Based on the lastest Publisher beta, as far as I can tell no method to lock guides is available. Here is why the current guides and columns implementation is a rather misguided one (pun intended First, let's list @R C-R's objections to a guide lock feature: perform many different tasks with the move tool based on canvas position; accidents are more likely & this workflow requires more care, but works faster than otherwise would be possible; avoids the need to open a menu or click a button to lock guides (extra work), and vice versa no need to deactivate a guide lock (less work) and prevents me from being unable to work with existing guides. adds interface/workflow clutter, making goofs more likely what would prevent the user from accidentally push a lock guides button? A lock guides button is just as prone to accidental mistakes as, for example, the layer lock button. the current visual cues and hints are more than enough to warn the user and prevent the user from accidentally moving guides with the move tool adding this lock guides feature may result in endless amounts of 'goof proofing' (because preventing any sort of accidental change would require this: where does one stop?) the user is just as prone to accidentally move a canvas guide, as they are mistakenly clicking a lock guides button Next, let's assume we work with a simple magazine-type layout template, consisting of multiple grids (and I would like to emphasize that this is a very simple grid-based layout). As anyone even remotely familiar with layout design is aware of, good layout grid controls are a basic ingredient): Now, before I discuss @R C-R points, this already highlights one of the issues we encounter with Publisher's "innovative" new columns approach: only ONE (1) column grid may be defined per master page (or per page). In page layout design more often than not multiple page grids and sub-grids are defined on any one page and/or page template. I solved it here by first creating a 12-column grid, then placing guides, and then create a four-column grid. That's as far as I can go: if I want to create another 8-column grid at the top third of the page, or a sub-grid to define image positioning on the right of the text columns, and another one on the left, I encounter several challenges in Affinity Publisher: The space/layer in which guides live is a "special" guide layer. Only one (1) set of guides can be defined on this "guide plane". It is impossible to create multiple guide sets. It's either all guides, or none that are visible. [2] would be somewhat workable if guide presets could be saved. They cannot, so it is not possible to quickly switch between guide sets. Guides do not really behave like other objects. For example, it is not possible to select multiple guides, and move these simultaneously. These issues are prevented in other design applications (such as InDesign) by basically treating guides as more or less regular objects. Guides can be placed in any layer. Multiple guide sets can easily be managed with multiple layers. So what about that snazzy novel Column Guides approach in Publisher? As far as I can tell, it is a work-around to provide a solution for Affinity's limitation that only one set of guides can be defined on the "guide plane". At first glance, it seems like a pretty attractive solution: it is non-destructive, and separating the guides plane from this new grid plane solves the immediate "only one set of guides" limit. And those visually attractive solid columns provide for some nice eye candy in Affinity promotional videos! But examining this from a workflow point of view, it only exacerbates the entire page layout grid and guides workflow: still only one guide set possible at any time per page or master page still only one page grid possible at any time per page or page master to work with multiple page grids, the user must create additional master pages, a less than desirable and convoluted workflow taking much more time a quick temporary grid just can't be done without destroying either the guides or overriding the master page's column settings. it is not possible to create guide systems based on selections. In a sense, Affinity Publisher new Column Guides, being separated from the guides, are really sort-of attempting to find a solution for a problem that never existed, if multiple guide layer/sets would be possible on the same page or master page. To say that 1 guide set and 1 column/row page grid are enough in page layout design is... Well, it is madness, and displays a complete lack of understanding how layout (semi)professionals work, in my opinion. The sensible solution would be to either introduce groups in the layer guide manager, and allow these to be individually activated and deactivated on demand, or just drop the current approach, and implement guides as objects which can be used in layers. Anyway, let's return to the topic at hand: the option to lock guides and @R C-R's list of objections to having such an option. Even the above 12-column grid is a simple and commonly used one. Publications may go up to double that, btw, and introduce many subgrids in InDesign for various things. Users tend to move things by grabbing the center of the object. In particular when a cross is displayed (check the image objects) a user's eyes will be focused on the center, and they will start dragging from that point. Because two guides are positioned near the center of these images, it becomes exponentially more common for a user to accidentally drag one of the guides, instead of an image object. This immediately is a counter-argument to points [2], [6], and [8]: users will not carefully position their mouse cursors and wait for a visual cursor hint to pop up and then move the object. Users do not wish to or will not second-guess this type of drag and move action: it is kinetic memory at work here, and a user expects the object to move when they move the mouse cursor on top of an object. The focus of the action is the image boxes, not the guides. (within this context it is interesting to note that this is related to the selective attention test behaviour and the famous invisible gorilla experiment: humans focus on what is important to them, not on secondary fluff - in this case, guides are not important to think about or focus on). The result is predictable: users WILL grab those guides by accident OFTEN. They can't help themselves, and they are not to blame: that is just how users visual systems and cognition works. This is why a lock feature is absolutely essential, and why any other design application in the market includes one. It also means FAR more work to correct mistakes, and this is a counter-argument to point [2]'s assertion that without a guide lock option a user would work faster than otherwise possible. It depends on the situation, of course, but in complex page layouts with many guides this is obviously not true. Even handling a simple page layout with a couple of guides which happen to be close to the center of objects create many more accidental mistakes than expected. Points [4], [5], [8]: As long as the guide lock option is hidden in a meaningful place in the GUI, accidentally turning it on (or off) becomes nigh-on impossible. For example: To lock layers would take a number of conscious steps: Open the menu. Navigate to the Guides menu option. Click. Navigate to the Lock Layers option. Click. Close the window. Too many steps to "goof up" accidentally. Or at least, not very likely. That said, an unsuspecting novice user might find it troublesome to discover guides in a document sent to them cannot be re-positioned. My opinion is that this negative user scenario does not outweigh the positives of a guide lock option for the far majority of users and user scenarios, as proven by other design applications. As for [4]: We must distinguish between GUI clutter and workflow clutter/inefficiencies. Yes, it does add one more checkbox. Does it clutter the GUI in the above example? I don't think so. It feels like a logical addition. As for the workflow with guides, it would be improved, as already stated. Besides, novice and low-level users wouldn't even notice this option, because they would probably hardly open this dialog (excepting the user scenario mentioned earlier). Which means nothing essential is lost in either GUI or workflow, and important control over workflow is gained. [1] [perform many different tasks with the move tool based on canvas position]: nothing would change in this regard if a guide lock feature is implemented. Indeed, it would simplify working with this tool and having many layout elements with a large number of guides. Currently, the only option to prevent accidental guide repositioning in a document with many guides is to switch to the node tool. But the node tool hides text boxes, and cannot be used to move vector objects (other than the "live" vector objects, which is an inconsistency if you think about it). In short, without a guide lock option the user may actually be forced to use the node tool. [7] [adding this lock feature may result in endless goof proofing - where does one stop?] No-one in this discussion asked for more than a simple guide locking feature. And I think I have disproved your assertion that a guide lock option would be "goof proofing": instead, it is an expected and common useful addition to assist in complex layout design control. A layer lock option achieves the opposite: it improves the usability of Affinity as layout design software. Conclusion: a simple guide lock option solves many workflow issues related to Affinity's three apps when dealing with more complex and controlled layouts. Even in relatively simple layout design guides may be accidentally selected instead of the content, depending on the visual status of the document. It also wouldn't increase either GUI clutter or cause an inefficient or confused workflow - rather the opposite. Aside from this, in my opinion the Affinity Publisher devs are attempting to find a solution for a core issue in all their applications: the single-layered guide plane. The current columns solution works okay for simple layouting, but is merely a work-around for not having to deal with that core issue. My opinion, of course. I am sure many Publisher users will laud this as the most innovative thing ever to be seen in a publishing application. In the meantime InDesign runs circles around Publisher for complex page layout design controls. [apologies for this rather long piece :-) ]

If you are on Windows, Nitro PDF will extract all the images from a PDF for you. The 14 day pro trial is fully functional, although I am unsure if the current free reader version still allows the user to extract images for free (it used to be the case). Not the most inexpensive solution, though. A license is $200. But at least you will be "Adobe free".

I agree. I used the free version until a couple of months ago, when I needed to create PDF forms for a client. Until two years ago, I used Acrobat Pro for this, but no longer had access to that version, and the rental only Acrobat DC is just ridiculously over-priced.

If you are on Windows, the best alternative for PDF editing and creating forms that I have found is PDF Exchange Editor, which does almost everything Acrobat Professional does at a very low price. Even interactive forms with javascript are possible. Prepress flight checking is not included, though. It also presents the user with a much more focused GUI than Acrobat (which is a confused over-designed mess in Acrobat).

My favourite optimization tool remains Color Quantizer. Which, aside from Webp, also happens to output to TGA and BMP (two more missing file formats in Photo). http://x128.ho.ua/color-quantizer.html

If that is what they were/are thinking (which I very much doubt), than that is up-side down thinking indeed. In truth, the entire layer panel in Photo is in dire need of a redesign. Just that checkbox to hide and show layers, and placement of the checkbox to the far right of a layer thumbnail is quite bad GUI/UX design, and just needs to be fixed. I've discussed this in another thread a while ago, though, and it doesn't really need repeating here. Suffice to say, compared to the layer panel design in Affinity Photo (and Designer), almost any other image editor (commercial and free) provides the user with a (far) better user experience. And it is not only the Layer panel GUI design that is an issue, but also layer management, or lack thereof. Other applications allow for colour tagging of layers, searching for layers (and types of layers), seamless zooming in and out of layer thumbnails, clear indication whether advanced layer blending options were used, and more. I expect the Affinity developers are aware of the issues related to the current Layer panel implementation compared to the competition, and will improve things by version 2. Rome wasn't built in a day.

I don't believe an official feature request place exists, but you could try these: https://blender.community/c/rightclickselect/ https://lists.blender.org/mailman/listinfo/bf-funboard https://blenderartists.org/ The last one is visited by developers, but the first one is probably your best bet. PS Spitznamen sind oft ein Wirrwarr in verschiedene Sprachen. Als Kind habe ich immer Raumschiff Enterprise aufs Deutsch ferngesehen. Später musste ich mir dann an die Englische Version gewöhnen. War nicht leicht. Die Deutschen Stimmen von Doris Day und Quincy hören sich noch immer besser an.