Medical Officer Bones

PS if you are looking for a reason for this behaviour in Photo: I believe all Affinity products use the same "viewport rendering" engine under the hood, and in applications such as Designer and Publisher decimal pixels make a lot of sense, because vector applications do not work with pixels. But Photo forces the viewport to be rendered into the pixel resolution we choose when the document is created, and MUST convert bitmap images placed at decimal positional values to that "native" resolution somehow. Which means an interpolated version of the original bitmap is generated in the view. Unless the Force Pixel Alignment option is turned on before working with bitmaps objects. This behaviour is confusing to Photoshop users (and not only Photoshop users).

I assume you turned on "Force Pixel Alignment"? If not, Photo will work with decimal pixel values, resulting in ugly anti-aliased copies when positioning to a half-pixel value, for example. The trouble is that if you already moved bitmap objects, turning on this setting does not fix the issue initially: first the object needs to be moved again, and then the setting kicks in. And when "Move by Whole Pixels" is active too, the blurred version will not "unblur". So turn off this option first, then turn on Force Pixel Alignment. Then move the bitmap, and it should clear up. The combination of these two settings can be a potential pixel art killer, so be aware of the effects.

Resampling becomes quite important when scaling down to a lower resolution and keeping the text crisp looking. In my experience CatmulRom works really well in these cases. It also helps to work at a much higher resolution, sharpen before scaling down, and sharpen a bit afterwards. Resampling also takes place in (4): the vectors must be rasterized to a bitmap representation on-screen.

The market already is saturated with both free and commercial production level animation software. Take your pick: Toonboom, TVPaint, OpenToonz, 3d animation software (Blender, Modo, Max, Maya, Lightwave), CelAction2D, Moho Pro, Flipbook, Spine, DragonBones, Krita, ClipStudio Paint EX, Animate CC, and the list goes on and on. Not to mention visual effects software which also includes very accomplished 2d (and 3d) animation features (Nuke, Fusion, HitFilm, etc.). So just pick one of the above, and import your work. I don't think Serif is going to attempt to compete in this market with a dedicated animation tool. That said, a simple Krita-like animation timeline would be nice to have in Affinity. Funny, the first time when I read this sentence I read "Adobe Perversion". :-) I never knew about that software, btw. In regards to presentation software: I create a lot of presentations/slides for my work, and I've completely given up on superfluous eye candy like transitions and animations years and years ago. I create my slides in design layout software, and export a simple PDF. Audiences are distracted and bored at the same time when faced with yet another PowerPoint-like slide collection. Nowadays I focus on the content and the content structure instead of useless slide animations and effects unless I have to show a complex topic or subject which requires animation to clarify the content. In that case I fire up a movie file. Otherwise I just stick with simple static slides which have a good clear readability and visual hierarchy. People grow bored quickly staring at that same old cross fade or wipe-in for the umpteenth time. Good presentation technique works FAR better than someone rattling off yet another boringly animated presentation slide. The less slides to bring the message across, the better. "Oh look, it's one of those presentations where the heading and text bullet points fly in sequentially from whichever direction" responses should be avoided. Have the audience focus on the presenter and the presented content, and avoid pointless animated effects. Avoid inserting graphics and images "just because" - there should be a valid reason. Stop brain-dumping all over your slides. Elucidate and engage and interact with your audience. Stupid pointless animation effects will just bore the audience. Clarify, use great typography, visual structure and presentation structure instead of relying on visual animated effects which no-one in your audience appreciates or cares about anyhow. If I do need to create something eye-catching, I create it in an animation and/or visual effects package with sound and so on. But that would become a running presentation for a booth at a convention, or something. Or a museum kiosk. In these cases I have control over the hardware used as well. And in such cases I avoid traditional presentation software like the plague and opt for different solutions. sso often have I seen presenters get into technical trouble because PowerPoint wouldn't run right, or slow, or the hardware was completely outdated and software wouldn't support their latest greatest presentation files. Or they would bring their own snazzy Mac notebook with Keynote, and forget about that RGB/HDMI regular connector. PDF always works no matter the OS, and I bring my own portable version of PDFExchange Editor, as well as export simple PNG files just in case when presenting in locations where I haven't presented before. If you are heck-bent on introducing slide transitions, why not export to a PDF, and assign page transitions with a PDF tool like PDFExchange Editor? Works fine.

Right, there seems to be a bit of confusion here. Before continuing, I think we should make it clear that there is a difference between: A) on-screen text rendering while working on a project, and B) text rendering quality when the file is rendered for final output. It is important to distinguish between the two when discussing text rendering and anti-aliasing quality, because even when (A) looks atrocious, the actual output (B) may be perfectly fine. @KirkS You mention that Affinity's text anti-aliasing looks ugly when zoomed in at 150%. This falls into category (A). And yes, you are correct, and the rough text rendering is due to the way Affinity needs to convert pixels to a view which renders half pixels: 150% is an awkward on-screen zoom factor which forces the application to render pixels to scaled up half pixels. This used to be an issue with all image editors, including Photoshop, and the situation improved when video cards were utilized with either OpenGL or DirectX rendering. When graphics acceleration (OpenGL based) in Photoshop is turned off (or is not supported on a flimsy GPU) the text rendering at 150% will look even worse than in Affinity. Other applications such as Krita also use graphics hardware acceleration to render the viewport, and zooming in will result in a (much) more acceptable view quality, albeit often with fuzzy edges. Looking at your posted Photoshop example, you will notice that the edges of the text look quite fuzzy, and OpenGL rendering is utilized to anti-alias the text rendering on the fly. Turning off the text's anti-aliasing looks terrible due to the awkward conversion to 150% zoom factor, and really has no bearing on this argument except to underscore the fact that zoom factors other than exact multipliers generally result in bad on-screen text rendering. Zoom in at 200%, and it will look pixel precise. In short, screen rendering of text in graphics software may or may not rely on the video card (GPU) to anti-alias the result on-screen. Some software is really good at this (Photoshop, Krita), but it will still produce fuzzy looking text when zoomed in, of course. Mind, the way your text looks on the screen is in no way guaranteed to be representative of your final output, in particular when zoomed in or out at a decimal zoom percentage. And then there is the impact of vector output or bitmap output. When we save the file as a PDF from Affinity Photo, the text will remain vector, and be rendered beautiful in any good PDF viewer and at any zoom factor (within limits, of course). Anyway, if the text rendering bothers you at 150% or other zoom factors like 125%, 109%, etc.) avoid previewing the work at those zoom levels. Only preview the text at 100%, 200%, 300%. Next, lets discuss (B): final output text rendering. The quality of the final text rendering output depends on a number of factors: the anti-aliasing settings (on/off, specific controls like the ones in PS or Fireworks) whether or not the design software allows for text to be positioned at decimal pixels whether or not the design software features pixel snapping, and whether this is turned on or off the font rendering engine behind the text rendering the resolution of the final file whether the text is output to vector (see above) or to bitmap For GUI designers (1), (3) and (4) are quite important. Some graphics software utilizes the OS's font screen rendering to render the text: for example, PhotoLine uses the Windows font rendering when pixel snapping is activated, which results in a 1:1 result compared to how Windows would render the text. GUI prototyping/design software will do the same, generally. This is of course the preferred method for GUI designers. And the font rendering looks arguably better than Photoshop's sharp setting in my opinion. Photoshop does NOT, as far as I am aware, make use of the OS text rendering, and the final rendered bitmap result will look different compared to OS rendered text (as is demonstrated in the example posted earlier in this thread). So how does Affinity Photo perform in the output (B) category? PDF output of text is perfect. No problems there. It depends on the PDF viewer's on-screen anti-aliasing and text rendering engine, of course. But Affinity is not to blame for any issues related to the PDF viewer's text rendering. If this is an issue, pick a different PDF reader. As for bitmap rendered text output, Affinity's anti-aliased small text rendering is indeed marginally fuzzy looking compared to other design applications. Personally, I feel the anti-aliased text looks good enough. It would be nice to have control presets for the anti-aliasing, but the coverage map is quite helpful, if a somewhat cumbersome method. But it does offer more fine control compared to fixed presets. Which is a plus in my book. That said, the major issue in Affinity Photo is the lack of an option to just plain turn off anti-aliasing for text (and vector objects in general). This is required for GUI work and often for very small text output. The Coverage Map won't cut it here. As long as (1) doesn't include a simple option to turn off anti-aliasing altogether, it will remain an issue for screen designers and pixel artists.

Few other alternatives for animation without a focus on visual effects? ToonBoom Harmony (essentials, Advanced, Premium) OpenToonz / Toonz Moho (Pro) TV Paint CelAction 2D Blender 2.8 + new 2d animation mode Other 3d apps (Max, Maya, Houdini, ...) Animate CC And many other options depending on your needs (Krita, ClipStudio Paint EX, ...) If anything this market is quite saturated with powerful options, both commercial and free. Unless I misunderstand you?

On Windows the answer is PDF-XChange editor. In the past I used to work with Acrobat Pro to create interactive fillable forms, but PDF-Xchange Editor is actually more usable than the "original" for this type of work. And full Javascript support. I am a firm believer in a two-step process: design the document in a dedicated design/publishing app, then add the interactivity and form fields in a dedicated PDF form builder. The reason is simple: even if the design app supports inserting form fields and the like, it could never hope to compete with a specialist PDF form editor. As for ePub export in Publisher: I hope for the best, but harbour no expectations at all. Besides, interactive FXL ePub files only work properly in Apple's ecosystem (iBooks reader), while on Windows, Linux, and Android such books break, because no good ePub reader exists which supports these. InDesign's FXL interactive ePub files are near to worthless to 90% of users. Flowing ePub 2 output is however quite useful to have. But that means the output would differ completely compared to what is seen in Publisher: flowing ePubs' contents flow and adjust according to the screen size and user settings. Therefore it is debatable how useful such output would be in Publisher. To be honest, I never used InDesign's non-FXL epub export and instead opted to export text and import into Jutoh or Sigil. (Far more controllable and reliable in my experience.) I would like to see plain old structured semantic html output from Publisher (no fancy CSS styling required but linked images would be with image quality export option), which is easily converted to flowing epubs with any of the above mentioned tools or even PanDoc. Epub FXL output would be interesting to have once the reader software situation on OS platforms outside of Apple is resolved. But I am not holding my breath: I have been waiting for years now, and it only got worse since the demise of Readium on Chrome due to Google's actions.

The devs have stated they will not implement a 1-bit mode. At most they are willing to add some sort of 1bit export and (hopefully) proper 1bit handling in Publisher PDF export.

It is not renting: it is a maintenance plan. You pay for a year of upgrades, and when maintenance runs out, you get to keep the last version as a perpetual license. The pdf-xchange pro version includes office integration which converts TOCs to clickable ones, links, etc. The Editor will also convert Office files if Office is installed. But I do not use MS Office (I am a LibreOffice user which already includes good PDF export by default), so I would suggest downloading the trial to see if it works for you.

If you are on Windows, and have no need for a prepress PDF toolset, then I recommend PDF-Xchange Editor. Great annotation/commenting/revewing tools, form creation, OCR, Scanning, and full PDF editing. The GUI is miles ahead of Acrobat (that horrible form properties dialog in Acrobat...). It also supports (as far as I have tested) all Acrobat Javascript. It even loads and displays 3d models embedded in a page. I found it to be an excellent Acrobat replacement. Only its prepress tools are missing, unfortunately.

The G'MIC filter set includes a Pixel Sort filter. To use it (free), download Krita, and import/copy-paste your image in Krita. https://krita.org/en/ Then apply the pixel sort filter: Filter-->Start G'MIC QT and search for the pixel sort filter. Change the settings to your liking. I wish the Affinity devs would include a version of G'MIC. It's a really nice set of effects.

Check your preferences/Performance View Quality setting: it should be set to "Bilinear (Best Quality)".

Support for interactive fixed layout epub books is still incredibly spotty on Windows, Linux, and Android. These type of epubs only work fine on iBooks for the most part. At this point in time I hesitate to call interactive FXL epub files "cross platform compatible". Animated books also won't work properly on Kindles either. Readium was pretty much the only good alternative on Windows, but Chrome put a stop to that when it deprecated Chrome apps. It is still being developed, but nothing yet. Sad state of affairs. Avoid interactive FXL epub unless your market is limited to iPads. Ref: https://www.boblevine.us/the-fixed-layout-epub-missing-piece-reliable-readers-for-windows-and-android/

Both companies also offer full perpetual licenses, aside from subs. Click on the perpetual links on their pricing pages.

I work with Justinmind and have worked with Axure. Both are professional level tools widely in use, and leave Adobe XD in their dust. I never understood why anyone views XD as a high-level prototyping tool, because it is very limited compared. Axure and Justinmind are off-line desktop tools, btw, and available for Windows and Mac. https://www.justinmind.com/ https://www.axure.com/

Add high pass effect as a live filter, then twirl down the layer live effect in the layer panel, and change the layer blend mode to Overlay. Adjust as needed.

Inking and drawing in Clip Studio is more than excellent. In my opinion nothing beats its pen and drawing 'feel'. Well worth the investment if you're doing comic and illustrative hand-drawn art. I use it almost on a daily basis for inking. PhotoLine works quite well too, in particular in the latest betas which improve the basic drawing engine. Not up to the standard of Krita, or even Photoshop or Affinity Photo, but it is hard to fault its 1bit image mode, and for 1bit inking all you need are basic brushes anyway for the most part (and its stroke smoothing is very good, which comes in handy for this work). It's even possible to work with multiple 1bit layers, and use a couple of blend modes. I use it mainly to composite my Clip Studio inks on top of colour work done in Krita, although depending on the complexity I may just do the colours in Clip. If you're looking for an one-in-all comic drawing/inking/colouring solution, with solid publication and comic page management features, than Clip Studio EX (the pro version) is more than up to the task. My only concern with Clip Studio is the lettering, which is more oriented towards Japanese text setting, and it does feel more limited. I tend to avoid CS for my text setting. I believe the developers are working on improving the text engine for western languages text setting. Clip Studio is also remarkably light on computing resources. It works fine on my 8 year old severely under-powered i5 4gb windows 7 tablet with wacom digitizer. That machine won't even run Affinity, and Photoshop was a trial in sluggish torture and frustration: forget about drawing a single stroke without severe lag. CS, however, provides a completely smooth drawing experience on a 10.000px by 5000 RGB canvas, or A4 @ 1200ppi 1bit. It just works. The on-screen anti-aliasing is also best-of-class, which is something I learned to appreciate after Photoshop and other art apps. Thin lines have a tendency to disappear on a zoomed out canvas in most art apps. Or be rendered badly, if at all. No such issues in CS. As for waiting for Affinity Photo to receive a 1bit mode: I wouldn't hold my breath. The Affinity devs have already stated that their current intention is to never implement it. It is unfortunate, but at least we know where they stand in this. Let's hope Affinity Publisher, at the very least, will properly support these for import and press output rather sooner than later, because it is such a basic and fundamental requirement for a wide variety of print jobs.

Of course you can import line art. The trouble is that for comic printing a high resolution 800-1200ppi 1bit bitmap (tiff) is generally used for line art which is then overprinted on the 300-400ppi colour work. Affinity Photo cannot deal with 1bit bitmaps at all at this point, while Publisher can import these, but during export they are converted to CMYK. Line art should not be greyscale continuous tone, because it just won't print well (actually looks dreadful).

I am going to be honest here. If your publishing targets include epub, apps and the web, this first version of Publisher is just not for you. It may take a while for Affinity Publisher to receive these targets, and I expect it will take at least one or two years based on Affinity's progress as a suite so far. If you are dying to get away from Adobe, and require these publishing targets NOW, QuarkXpress merits a look. More expensive, though (you do get a deal if you own InDesign, btw). And Affinity Photo and Publisher will still be nice replacements for Photoshop and Illy.

As long as you don't need crisp bitmap-based black 800-1200dpi printed line art (inks) for print, and you can work at 300-400dpi for print, you'll be fine with Affinity and comics. If your only output target is web, you'll be fine too.

Stick with Clip Studio for now: Photo does not, and will not ever (according to Andy Somerfield, Photo lead developer), support 1bit bitmaps - perhaps only export. And Publisher is unable to export 1bit bitmaps for high resolution line art, and converts these to CMYK or RGB files. In short, unusable for most comic book printing jobs. At least, Publisher will hopefully be able to support 1bit bitmap PDF export at some point. Photo will never be optimized for comic print workflows, sadly. If the comic art is full colour 'painterly' style without line art, however, Affinity will work just as well as other software. Or possibly create your digital inks using vectors only. Reference:

Yes, InDesign just identifies these files automatically. In both Scribus and PhotoLine setting the high ppi 1bit layer to multiply will work and keeps the original 1bit data in PDF1.4 onwards, with no conversion occurring. QuarkXpress also deals with 1bit obviously. Publisher is the odd duckling out.

The preliminary results are disappointing. I created a document with a 300ppi colour art layer, and imported a 1200ppi 1bit tiff image, set to multiply mode. On-screen it looks fine. When I export the document to a pdf, Publisher insists on converting the 1bit tiff to either an RGB or CMYK version (depending on the document and/or pdf export settings) while retaining the original resolution. That is very problematic: a too-high CMYK/RGB image will be sampled down by printing software / image setters before printing. I tried all sorts of settings, but Publisher simply refuses to maintain that 1bit TIFF during export. Unless I am missing a particular option or setting, Publisher seems incapable of achieving this quite basic task. Also, in this case the Photo link is useless: because Photo does not support 1bit images, it merely displays a downsampled greyscale version at 300ppi. But it does keep the original image data intact: returning to Publisher mode restores the original high resolution version. @Andy Somerfield Is it possible to retain the high resolution 1bit bitmap during PDF export and prevent Publisher from converting the image to a RGB or CMYK version? Am I merely overlooking a setting? This is absolutely essential for comic publishing work.

Affinity's developers would probably go insane after the Windows version.

I checked the PDFs today in a PDF editor, and it seems Publisher will convert those 1bit tiffs to four channel CMYK high resolution images in the PDF, unfortunately. I am unsure if that will print correctly, because the image setter software will probably just sample down the line art to 300 or 400ppi. Will investigate further tomorrow. I really hope there's a setting in Publisher that will leave the 1bit tiffs untouched during PDF export.