Medical Officer Bones

Not having a book function is going to make Publisher almost impossible to to manage more complex documentation and books with. In short, not worth the time or effort. Aside from team work, it is indeed hardly practical to work with hundreds, if not thousands, of pages divided in many chapters and/or sections. Word can manage this (urghh!), and if Publisher is ever going to be taken seriously as a layout tool, it will NEED far better complex structured document tools. Tools which are now not available. But even before adding book functionality and structured document features, Publisher's handling of pages, master pages, multi-spreads/foldouts and simple sectioning needs a LOT of love first. No-one said this first version was going to be the end-and-all of layout software: it is much too early in the game as of yet. I am patient. I will wait. I did so with InDesign during Quark times, and I will do so again. Time will tell.

I agree with you, @mac_heibu ! For a first version it seems remarkably feature-complete. Although I've only played with it for a couple of minutes, things that stand out in comparison to InDesign: Optical Alignment is not only included, but is also a text style property! Hurrah! And way better control options. The text ruler sticks with its text box! I hate the InDesign (tabs) text ruler with a vengeance. Seemingly feature-complete typography and text flow options Fast. Navigating pages in Publisher feels faster compared to InDesign on my machine. The GUI reacts in a smooth way in Publisher, while InDesign is quite laggy. For example, dragging the pages panel to increase the width updates the entire screen smoothly and instantaneously. In InDesign it's a lag-fest. Very smooth viewport dragging with hand tool compared to InDesign way more parametric shapes to play with! instant feedback when browsing drop-down lists. Overall, Publisher feels less clicky in most regards. the translucent rulers are actually a really good idea grid options are light-years ahead of InDesign. Isometric grids in a DTP layout app? Gold! And the grid window is non-modal! nice snapping options All in all, pretty usable so far. Things that are missing for me or in need of drastic improvement compared to InDesign: master pages cannot be based on other master pages, it seems. the pages and master pages functionality is extremely basic compared to InDesign. no option to set up alternative layouts. section manager is awkward, awkward, awkward. multi-page spreads and fold-outs seem impossible? That would be VERY problematic. Spread Setup dialog is terrible in Publisher. This really needs to be integrated in the page panel more. And the dialog is modal? no cross-referencing, running headers/footers, etc. not possible to paste graphic/image/object in a text so that it flows with the text. having various page-sizes and spreads in the same document seems either very difficult or very awkward. place tools not very refined no spine awareness for various features no epub export: fixed or flowing. No animation or interactive epub layout options. no html export or online publishing no flight checking tools. no links panel to check a place image's properties and effective and true ppi. The resource manager is too awkward in use. Can't even use the scroll wheel to navigate the list. no built-in article editor. InDesign's article editor is sort-of essential to deal with large copy. guides won't work in layers, so it is impossible to create multiple guide systems. no change tracking no footnotes no visual measurement feedback when dragging stuff. no scripting, no plugin architecture. InDesign's Gap tool is very nice. Publisher needs something similar. no way to zoom into the pages thumbnails. Same with the layers. many panels very messy looking (the paragraph panel, for example). Looks thrown together, rather than well thought-out. Lack of breathing space. So, still a lot of scope for improvements. I don't care too much about epub and html export, but the pages panel and how pages are handled need a lot of love before I decide to commit to Publisher. Features related to automation within a document (running headers, cross-referencing, links, footnotes, automatic table of figures, figure numbering, text variables, and so on, and so forth) are almost completely missing for now, and I use these quite a bit too. I wouldn't want to layout a technical manual in Publisher as it stands now. A good start. Hopefully the pages panel, master pages and page management in general will see drastic improvements before the end of the beta phase.

*EDIT* Finally figured it out. I checked the installation log, and it failed with the "The type initializer for 'System.Windows.Media.FontFamily' threw an exception." error. I uninstalled all non-essential fonts, and it installs now.

*EDIT* Finally figured it out. I checked the installation log, and it failed with the "The type initializer for 'System.Windows.Media.FontFamily' threw an exception." error. I uninstalled all non-essential fonts, and it installs now.

Same problem here. Removed all registry entries, removed old version of Affinity Photo, manually removed all Affinity registry entries and files on the WIndows boot drive, and nothing works. Both Photo and Publisher refuse to be installed. I check the processes in Process Explorer, and both installers start up, and after a few seconds exit. I installed two other applications today, and no problems there. So something must be wrong with the Affinity installers, or at the very least these installers are checking something that others don't.

Here as well. I cleaned up the registry, used the MS installation fix tool, (which couldn't fix anything),... It did notice an old Photo Trial installation, which I removed. I then rebooted the machine. Just downloaded the update for ClipStudio 1.8, and that one installs without any issues. Another application installed without a hitch too. Affinity Photo 1.6.4.104 is installed, and any attempts to install the latest 1.6.5 version fails as well without any warning. With Process Explorer I notice the process starts, then quits after a couple of seconds. Finally, I uninstalled Affinity Photo. Affinity Photo installer will not install the latest version either. So, I checked the MS installation tool again, and all Affinity products are removed (not listed). I removed all traces of Affinity from the Windows boot drive. I again deleted all traces of registry entries related to Affinity products. I closed all non-essential services and apps. Attempted to install Affinity Photo once again, with and without Admin. No go. Attempted to install Affinity Publisher trial. No go. I am now left without Photo, and both apps refuse to install. Surely I cannot be the only one faced with this issue.

To amend SrPx's answer, a number of applications allow for saving to a PSD as well as their native format simultaneously. Krita will do this, as will PhotoLine. The latter has an option which, when activated, will even ask you if you wish to open the native version if it discovers a PLD with the same name in the same folder. Which means opening a jpg will open the source layered version with all the bells and whistles. Saving the "jpg" will then save a new flattened JPG as well as the source PLD file. This is very, very handy, since saving and opening a PSD (or any other export file format) will save or open the native source format instead, in effect handling this file conversion automatically for the user in the background without having to worry about the actual conversion. Of course, one has to be careful not to overwrite the same PSD with another application. Affinity Photo, unfortunately, has no such option (yet?), and insists on separating the save and export functions at all times. For interoperability reasons it would be preferable if a similar option is implemented in the future in Affinity. ... In my opinion an open intermediate file format spec is long overdue. Ideally this open format includes layers, layer masks, bitmap, text, and vector layer handling, common adjustment layers, colour management, and so on. PSD might have been a candidate, but the trouble is that Adobe stopped updating the PSD specs years and years ago to protect their own interests. That, and the fact that it is an entirely proprietary file format owned by Adobe.

Developing support for native file formats like Krita's *.kra and Gimp's *.xcf files is very time intensive and will never be perfect, because each application supports different native functions, and these have to be mapped to equivalent ones in Affinity Photo. In short, unless the native file format is regarded as an industry standard one, it is just not worth the hassle, time, and money. And Krita, Gimp, and Affinity all support Photoshop PSD files, so why not use that as an intermediate file format? Not quite perfect results, but good enough in most cases. At any rate, a native Gimp and Krita importer wouldn't be perfect either. Things like layer groups, layer blend mode, and opacity are all retained. PS I have no major issues with exporting Krita files as PSD files into Affinity, Photoshop, or PhotoLine. In terms of PSD compatibility and feature support it's #1 Photoshop (obviously), #2 PhotoLine (import is better, but export not as good as Affinity), #3 Affinity Photo (export better than PhotoLine), #4 Krita.

I ran into the same issue (in my case it's 1bit line art @ 1200ppi which I need to process), and outside of Photoshop I found that PhotoLine supports this very well: even supports 1bit layers, unlike Photoshop. But PhotoLine doesn't work with indexed colour modes, so for that I am working with ProMotion NG. Which also supports full layers, unlike Photoshop. Sigh. Can't have it all in one app, it seems.

Or OpenToonz. OpenToonz outperforms Adobe Animate for animation in most areas. Also open source and free! Latest development release here: https://github.com/opentoonz/opentoonz_nightlies/releases Latest official "stable" release here: https://opentoonz.github.io/e/ A portable version with the very latest new raster level enabled Mypaint brushes here: https://github.com/turtletooth/OpenToonzPortable/releases/tag/0.0.0.1 Being able to work with mypaint brushes on OT raster levels is a huge improvement for production. (What it means is that the colours you paint with are saved in a fixed colour palette, and this means again that a colour may be changed at any time later and adjusted.) Before we couldn't use the nice MyPaint brush engine in Toons raster levels, only in standard bitmap levels. And these toonz raster level colours can be animated, which is not possible with regular bitmap raster colours!

And those professionals are doing some high level stuff with Blender. Blender is used more and more in production by AAA studios such as BarnstormVFX: Man in the High Castle, The Good Wife, Silicon Valley and many others. And high-end character animation: Tangent Animation's newest feature animation, "Next Gen", is the studio's second animated film. Produced and rendered 100% using Blender. Interestingly enough Netflix paid 30 million to pick it up for Western audiences: https://www.cartoonbrew.com/feature-film/why-did-netflix-pay-30-million-at-cannes-for-the-chinese-animated-film-next-gen-158348.html

One of the most efficient ways of colouring your line art and scanned drawings requires Krita, but since it is free and open source, you can prepare your work in Krita and then import as a layered PSD into Affinity. (Or finish colouring in Krita). Krita is sort-of specialized for this type of work. I mention this because Krita has this nice colorize mask tool that makes it a doddle to colour the artwork, and split it up into layers automatically for you. It saves a LOT of time, and is very efficient, and saves you from having to perform many manual steps. Get it at www.krita.org Nice tutorial:

PS I get the best anti-aliasing quality at 2416x2416px when I export the initial 3333px version as a PNG and scale it down to 2416px using Catmul-Rom in Color Quantizer. Most software will not allow for Catmul-Rom as a downsampling algorithm, though. The file size is increased which is a sign of more (useful) information, which is again a sign of that particular downsampling algorithm preserving details better than a straight vector to bitmap conversion at 2416px. In particular the red lines of Tomas Road look much less jagged, and details stand out more (check the red dot at "such and such is located here").

All four PNG files have vastly different resolutions! The first one is 800x800 (no transparency), the second one is twice as high at 1600x1600 and has a transparent background, the third one (Graphics) is 2416x2414px without transparency... Nothing can be compared here. They all look good to me on a white background, but obviously the second AD version looks not as crisp as the third one, since that third one was exported at a much higher resolution. And the second one (AD with a transparent background) might not look as good DUE to the transparency when viewed interpolated zoomed out. Depends on the viewing software (in my experience some viewing software doesn't do transparency justice in regards to quality). So be sure to export with a white background. Viewing the second one at the same scale as the third one on a retina screen will result in a more blurred version in the case of #2, of course. Not a fair comparison either. Here is your eps file exported from Affinity Photo at 2416x2416px. I really can't notice any difference compared with your #3. Affinity's version is also smaller in file size. Are you sure you have a firm grasp of the concepts of DPI, print size and (true) pixel resolution, and how these relate to each-other? I mean this in the best way, so if you do, forget I asked. Anyway, DPI is completely irrelevant in this discussion: only pixels count. You MUST export all variants from all applications at IDENTICAL pixel resolutions (and I do NOT mean DPI!).

Here is a better example of PNG export comparison issues popping up when comparing the PNG output of these applications. P_Dinosaurs.svg I exported this SVG file in Photo, Photoshop, and PhotoLine as a 'pure' 24bit PNG file @ 800x720px. Result: Photo: 396kb Photoshop: 286kb PhotoLine: 423kb You'd think "Well, Photoshop is the clear winner!", right? Not so fast. As it turns out, Photoshop's version contains 2063 unique colours, while Photo has 3829 colours, and PhotoLine's version tops out at 4285 colours. So that means PhotoLine's version arguably retains the most fidelity (or uses softer anti-aliasing), but in practice the user won't be able to discern any visual differences between these three versions. All of these were saved as 24bit +alpha, so why the large differences? Depends on the algorithm each app uses to decide which colours to keep, and which to throw away. I have no idea. No clue. Up to the developers. If we'd be discussing a source bitmap the differences would probably be negligible. But in this case a vector file is to be processed, and each image editor's built-in conversion routines will have an impact on the final conversion. In short, "losless" loses its meaning when dealing with vector file conversion. It depends on the software used and the routines at work. The compression/processing algorithm can have a tremendous impact on final file size on top of that first vector to bitmap conversion. That same 4285 colours version was reduced to 281kb after processing it with Color Quantizer, and saving it as true color. CQ will create a palettized version of 4285 colours, resulting in no quality loss, yet a significantly smaller file size while maintaining more colours than either the Photo or Photoshop version. It's all about the compression and processing stage at this point. @SrPx Indeed, dithering may have a large impact on palettized images too. in this case I refrained from converting to a 8bit version, because it will open a whole new can of worms, in particular seeing that so many different dithering patterns may be used. A regular pattern compresses better than a stochastic one. The results can be inspected down below. I didn't check for meta data, but I turned it off for all, I believe. Visually no-one will be able to see the difference. Affinity: Photoshop: PhotoLine: Color Quantizer based on PhotoLine's high-colour version:

@haakoo Ah, right, sorry about that. SrPx is correct: too many unknown variables at work here, and until we have an actual sample file that demonstrates the problem unequivocally, nothing can be solved or anything useful stated. I did a quick comparison between Affinity Photo, Photoshop, and PhotoLine, and 24bit exports are pretty much similar in export size and quality, barring the included meta data. With Color Quantizer I obviously am able to achieve smaller file sizes at 24bit, as it is a specialized PNG optimization tool, but no surprising results. When I saved as 8bit palettized files, I was a bit surprised to see that Affinity Photo did not reach the same low file size as the other two, though. A rather large discrepancy which I can't explain yet, so I will investigate further.

@haakoo PDF retains all the vectors, and this would blow the file up (depending on the complexity of the graphic), so it should never be compared to a bitmap file format such as PNG. It's just not useful in any way. And depending on the settings, a non-compressed bitmap may be saved in a PDF as well. Too many variables at work there for reliable comparisons. Comparing the SVG output to a PNG output would be more practical, since depending on the graphic it would yield lower file sizes for one or the other format, and also SVG is obviously resolution independent for web page and app development. An informed decision can then be made which file to use. By the way, 300dpi tells us nothing: 1 pixel can be saved as 300 dpi, and it is merely a parameter used in print to decide how a pixel should be treated when printed. Always mention pixel dimensions when comparing.

Comparing a PDF with a PNG is like comparing apples and oranges. If the vector file is very complex, it will create a large PDF file (because the vectors remain vector, and all the original path data is retained) and a 800x800px PNG file could result in a very small file size. But it all depends on the complexity of the original file. You should not base any file size assumptions on such basis. It makes no sense. Are you exporting the PNG file at the same pixel size? What is the pixel size? Is it 800x800px? Are the PNG files you exported from Affinity and the lower grade tool you mentioned equal pixel size? Are they both 24bit?

@owenr Thanks! I had tried it with another file, and assumed the fill command worked differently. Thanks for the help.

@firstdefence Yes, that seems to be the case. It's quite a basic function, so I hope the devs will implement it at some point in the future. For those who need an example, here's a file that demonstrates the problem: When the transparency/alpha is transferred to a layer mask (or removed) this image pops up: If someone happens to stumble on a method to accomplish this in Affinity Photo, I'd be grateful. ps just noticed that in PhotoLine the brush tool can work directly with the alpha channel, and I can undelete the hidden parts of the image by painting over the transparent areas as well.

That was one of the things I tried, but to no avail: the original layer's transparency/alpha is maintained. But your answer did motivate me to look once again, and I found a method/workaround: 1) switch to the channels panel, and right-click on the Pixel Alpha to create a new mask layer. 2) select the original layer and use the pixel alpha's Fill command to fill the alpha with pixels. However, it is only a partial solution: I'd like to display the original pixel data.

Does anyone happen to know of an equivalent of Photoshop's "Layer Mask from Transparency" function in Affinity Photo? It converts the transparency of a layer to a layer mask, and removes the transparency from the original layer. In PhotoLine this is achieved by creating a new layer mask based on alpha. In Gimp there's the option to transfer a layer's alpha channel to a layer mask when a new layer mask is added to a layer with transparency. To be clear, this function removes the transparency from the original layer, and transfers the alpha channel data to a layer mask. It's a very basic option, and ought to be possible somehow in Affinity Photo, but so far I haven't been able to figure out how to accomplish this. Help is very much appreciated: I've been fiddling around for an hour now, and it's probably so obvious that I am looking past it.

Weird. In other image editors with advanced layer blending options the simple solution in this case is just to target the gray channel and slide the gray top slider to the left to remove the anti-aliased edge pixels until the edges become aliased. Quick and easy. But in Photo the Blend options work differently, and won't allow me to do this. I am somewhat surprised (not in a good way!) that this won't work in Photo. A gray channel target ought to be added in Photo too.

PS one thing Affinity's export persona should do, is a real-time preview. Come on, guys! Without a preview it's trial and error. Anyway, one of the major peeves I have with Photo at the moment, and why I just export to full quality PNG before processing further in other image editors and optimization tools. I just don't bother with Photo's export persona because of this.

I would agree that for specific purposes the PNG export could be much improved, but let's get down to Earth: no general-purpose image editor can beat specialized treatment via a dedicated image optimization tool such as Color Quantizer, and nor should that be an issue. If that level of control is required, the user will have access to that level of knowledge as well. Affinity's PNG export is fine compared to, for example, Photoshop. Photoshop doesn't even have a palletized option available to it compared to Affinity. As for JPG: not sure. Didn't do enough testing myself, but then again, I tend to stay away from jpg nowadays for my work, excepting the odd web dev job. Otherwise I'll just use either heavily optimized PNG or Webp files. And now that I mentioned Webp: i find it quite concerning that Affinity won't let me export to Webp. It's a great format for game and mobile development (I guess on Windows and Linux at least, because Apple seems to boycott the file format), and to me it's a crying shame a modern image editor like Photo won't support it. Worse, it DOES import Webp file, but won't allow me to save the same file as Webp? Silly. And very short-sighted, in my opinion. As short-sighted as Adobe in this case. Luckily PhotoLine has no such problem, and exports via its visual web export to Webp.