Medical Officer Bones

Ah, I see you are into textile printing! Yes, that would be problematic. I checked out your example file. My solution to your problem is to export to a PDF, and open it in PhotoLine. Then turn off global anti-aliasing. Done. Export to a bitmap. The only issue is the pattern at the bottom. Affinity does not support vector patterns yet, so you would have to replace that pattern in PhotoLine with a pattern that consists of vector layers which must be set to aliased in the layer properties (PhotoLine allows for easy per-layer anti-aliasing control and for aliased vector patterns the layers themselves must be set to aliased before the pattern is defined.).

@Bones_the_Bones The simple answer is "No". Unfortunately none of the Affinity products feature a global option to turn anti-aliasing on or off. Other software often does, and with a simple switch anti-aliasing is removed (both on-screen while working, as well as during output): Ideally Affinity would allow the user to turn off anti-aliasing globally on the fly while working, but the only option available to sort-of work around this missing option is to set a custom coverage map like so: But there are still several issues with this approach: for one, it must be applied to each and every layer individually, which is a workflow breaker and very inconvenient to keep track of, and secondly, this approach will break under circumstances. For example, the star object does have the coverage map set correctly, but still is anti-aliased in places. The reason: the stroke setting is set to an outside stroke, which breaks that work around method. Worse, when the circle's stroke is set to "align to inside", the yellow bleeds into areas outside the stroke! I use custom stroke alignment all the time to achieve certain effects, and this coverage map is incompatible with that workflow. Others have already mentioned in other threads that this is really problematic for work like pixel art or textile printing. There are other issues with this coverage map approach and the way strokes work in Affinity: Left is Affinity with the thinnest possible stroke applied and the coverage map method. Right is illustration software with global anti-aliasing turned off, and a 1px stroke. I probably don't have to explain the issue here: right is what we want, but left is what we get in Affinity. In short: far from an ideal situation. I do hope the Affinity devs will fix this in an upcoming release, because for any aliased artwork Affinity is in a really bad place as it stands and the workflow is just not there in my opinion. My suggestion would be to look elsewhere if this is important for your work.

@Fixx I agree: InDesign is very quick to work with. @NauticalMile I must have misunderstood you in some way: zooming and panning documents in all Affinity products is very fast: just use a mouse with middle mouse button and scroll wheel. Much more effective than any buttons. I am always frustrated with Adobe products than none of those allow panning the view with the middle mouse button, and force the user to press and hold down the space bar, which is very inefficient. Also, I use keyboard shortcuts for most commonly and often used commands in any software, which thoroughly speeds up workflow in any application. Much faster than any GUI. CTRL-S (win) or COMMAND-S (mac): save done. Faster than moving the mouse to a save button, and it works in any application with a save function. A save button just takes up unnecessary space and clutters the view in my opinion. Same for undoing things: ctrl-Z, done. Having said this, I do agree with both you and @Fixx that Affinity Publisher and Photo in particular have a number of basic workflow issues at this point. These do indeed stunt the workflow, and I hope the kinks will be ironed out by version 2. I mean, I recall the first couple of versions of InDesign, which had some very rough edges as well. As it is said: Rome wasn't built in a day.

Did you try to enter your serial number on the page I linked to? If the number includes the letter OEM it will not work, but otherwise it should. I have read several accounts of users with OEM 32bit WIN7 machines succesfully installing the 64bit version with their OEM serial, though. You will need a genuine Windows 7 pro 64bit ISO image, which can be downloaded with this tool: https://www.heidoc.net/joomla/technology-science/microsoft/67-microsoft-windows-iso-download-tool Then choose the correct Windows 7 OEM 64bit version that mirrors your 32bit version, and backup your machine. Clean your hard drive, and reinstall WIndows with this new version and when asked enter your serial number. It will work, because a product key works for either the 32-bit or 64-bit version. Just make sure to uninstall the 32bit version completely, because you are only allowed to run one version with one product key.

If you have a Window 7 PRO 32bit product key, you should be able to download the ISO image for the 64bit version, and install that version instead at no extra cost. Problem solved: Affinity will run. Your 32bit Illustrator will run as well. https://www.microsoft.com/en-ca/software-download/windows7 https://answers.microsoft.com/en-us/windows/forum/windows_7-windows_install/is-a-windows-7-license-key-valid-for-both-32-bit/70d546cd-b6e3-44d8-a6c8-fd7feb7d1915

In competing page layout software it is possible to right-mouse click an image (vector or bitmap) and open that asset in an external editor of the user's choice. InDesign, for example, offers this option, and I often make use of it. I looked and looked, and it seems Publisher lacks this rather basic functionality. I understand that Photo will become part of Publisher as a Persona, but that still will not solve this issue, since not everyone will be interested in purchasing Photo and/or Designer, and may prefer to edit their assets in other software. My request would be then: please add a simple "Edit With..." option to allow Publisher users to open any asset in any custom editor of their own choice.

It serves up most of the Internet? It runs every Android based phone and hardware, dominating the the smart phone market? It runs Facebook, Wikipedia, etc. It drives a huge amount of hardware (including those large Tesla car displays, Kindles, Kobos, drones, and much more) and most of the internet of things (fridges, thermostats, etcetera)? Heck, it's the only OS running on the entire planet Mars (Mars Rover) and it runs the systems on ISS. It runs China's Social Credit System, controlling many aspects of their population's lives from 2020 onward. Self-driving cars will be running on Linux when they hit the main consumer market. Linux dominates in the world throughout, with the exception of graphic design and production and a number of other minor areas such as consumer and office desktops/notebooks where mainly Windows and some Macs are in use. Macs and iOS serve as terminals through which consumers connect to a by and large Linux world with a measure of Windows. Otherwise it is Linux, Linux, Linux. A lot of embedded Linux too. Linux will probably drive all the upcoming technology and artificial intelligence that will replace much manual labour and related jobs: on farms, in shopping (already happening with all those automated check-outs), in transportation at large (including automated transport ships, planes and drones), sex bots, the servicing and support industry (chatbots), and so on, and so forth. Most office jobs will disappear, replaced by AIs running on some kind of Linux derived OS and software. Linux drives by far most of the IT world as we know it. And it will only become MORE. Linux will replace most humans' low level jobs, probably - it's already happening. Big brother runs and loves Linux. Linux: welcome to humankind's future. And the future is now. Or perhaps your question's scope is to be limited to the prepress print industry only and partly to print graphic design? Well, disregard the previous lines of text in that case. [Written with a hefty dose of sarcasm and irony. Or is it?]

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?