Medical Officer Bones

Then you are lucky and privileged: because many pre-CS6 users have had no luck at all, even when they contacted Adobe. And you are proving my point: in the classic software business model older versions would continue to run (albeit on older operating systems and hardware). In any case this is only true for legacy pre-subscription Adobe users. Current subscribed users lose access to previous versions older than 2 releases.

I find some of these complaints in regard to update costs somewhat baffling. 8 years ago the first version of Affinity Designer was released. 7 years ago Photo. 3 years ago Publisher. Throughout that time customers received free updates and upgrades, and many new users purchased the software at a reduced special offer price. I am one of those. All the free updates actually made me feel I ought to ask Serif to charge me MORE, because the cost for V1 in relation to its functionality was always greatly in favour of its feature set. In short: very inexpensive for what was on offer. V2 is a new release of Affinity. It is offered again at small cost compared to other commercial alternatives. V1 continues to run and isn't 'taken away'. There is no subscription. Unlike companies such as Adobe, older versions are not removed from the user's installation options. Serif's business model is based on the "you pay for it, you have an unlimited license" approach, which is actively abandoned by most other software companies. Yet: like it or not, Serif has to generate revenue to cover development costs. They can't forever keep leaning on bringing in new users. The Affinity devs have always stated that free updates would be available for V1.xx. They stated unequivocally that V2.XX would become a paid upgrade. Now, I understand that if a user purchased the software in the last 3 months, having to pay for a full upgrade is understandably inconvenient, and it would have been perhaps preferable for Serif to handle those cases differently. But surely enough, at SOME point Serif has to make SOME money, otherwise business becomes untenable and they'll go bankrupt. Right? Or perhaps Serif has a good reason to go down the subscription route after all: even IF you try with your best intentions to provide professional-level design software at a very affordable price level, AND offer 50% off to everyone at release time, STILL people complain about it. If I were them, the subscription business model suddenly is beginning to look quite attractive. Because there is no use in trying to please everyone anyway. PS I do agree that a grace period of 1 year or so to fix critical bugs in V1 would have been good to have and alleviate part of the complaints made.

InkScape features a quite decent bitmap autotracer, and is free.

As others here have recommended: ClipStudio Paint is one of the best options out there for sketching, drawing, and animation. I'd also suggest Krita, which is also an excellent digital drawing/painting app with quite acceptable frame-by-frame traditional animation. It is quite amazing that Krita is open source and free. And consider OpenToonz as well: a production-proven 2d animation studio that was and is used in Japanese feature animations. Futurama was produced with the help of the older Toonz version. ClipStudio Paint exports animation sequences directly to OpenToonz for combining, compositing, and mastering all scenes into a final animation. While ClipStudio's animation options are good, the app itself is not meant to combine and master multiple scenes into a longer animation production. OpenToonz is meant for this job. OpenToonz is extremely capable (on par with Toonboom advanced and even Harmony in many respects), and amazingly enough free and open source. http://opentoonz.github.io/e/

I would love to see the developers and/or moderators chime in here. It is such a basic requirement in publishing, and I wonder if this is even on the (road) map for them.

You must be doing something wrong then: the above file placed in a blank document in InDesign 2023 and exported with printer's marks results in a 480kb file - which is still smaller than your test pdf with the incorrect converted 8bit file. PS Ah, I see: you saved without compression. Choose the default compression option for monochrome images in the PDF export settings. The only reason why I asked for those settings in my original post is that I hoped it would prevent Publisher from converting the 1bit image.

@tudor Many thanks for testing! 🙂 Oh my... It seems nothing has changed in R2. Which is a major personal disappointment, since 1bit image support is absolutely essential in the PDF output and must not be converted to a different image mode - it messes up the print, of course. These are commonly used in the publishing industry since the advent of desktop publishing. Such a crying shame. Unless there is a new setting in the PDF export options that allows us to keep these untouched, to me Publisher is still unusable. So close! Books, notes, ... But as long as this is not fixed investing in the new version makes no sense to me, because I cannot use it. This is what I had hoped to see instead:

Well, quick update: [5 book management] and end/foot notes were implemented in R2. It's looking great so far, as well as the expanded book TOC support. Before I make the purchase I just need to know if 1bit images are properly supported in the PDF export.

Simply stated: 1bit images are part of the core workflow in much of my work. I do not expect Photo to support these in R2 because the developers have unequivocally stated that Photo will never support a 1bit image mode. But that is fine: I can use PhotoLine and other software for that. But it is ABSOLUTELY essential that Publisher leaves placed 1bit images alone and retains these in the PDF export. Publisher R1 is incapable of doing this. Publisher finally adds book support and with the addition of 1bit image PDF export I can finally say InDesign farewell. But only if it actually works, and I cannot find this information anywhere in the new features list. Would anyone be so kind to place the following 1bit image file in Publisher R2 and export to a PDF with these options: downsample images turned OFF allow jpeg compression turned OFF And share the PDF with us here in this thread? 2017-10-01_inktober2017_swift_by-David-Revoy.tif [image source: https://www.peppercarrot.com/en/viewer/sketchbook-src__2017-10-01_inktober2017_swift_by-David-Revoy.html]

Yes, Publisher does that. And changes are visualized in real time while changes are made to word spacing, which speeds up the typographical design stage 🙂 Framemaker's modal dialogs look and feel old-fashioned in comparison. Spelling checking is nicely implemented via the Preflight panel. Additional dictionaries for different languages (excepting Chinese, Japanese, and Russian) may be downloaded from LibreOffice or OpenOffice and installed. Grammar checking is unsupported. Check my comments further below regarding my thoughts on Affinity and long documents. Nah, not possible in the current incarnation. See comments below again. Nope, not possible or supported. Of course it is possible to use a third-party math editor to create vector files for import and placing in Publisher. Even LibreOffice has a decent math editor built-in nowadays. Or use a free math editor such as https://sourceforge.net/projects/eqtype/ This is THE achilles' heel of Publisher for this type of work. Aside from a number of other rather essential missing features, I will not touch Publisher for ANY longer text-heavy document creation, because it just is a terrible idea to manage all chapters, sections, indexes, TOCs, etc. in one master document workflow. Not good. And therefore, in my book (pun intended ) Publisher is ill-equipped to even attempt a long structured document project. There are other glaring missing features that are deemed 'somewhat' essential: not possible to insert either foot notes or end notes. obviously missing: text styles management across chapters, sections, etc. text variables: does not compute! text editor (with longer texts spanning an entire chapter, editing text in text frames is at a minimum daunting and cumbersome, at most unusable. 1bit images remain unsupported and cannot be placed or exported without conversion to RGB. This is absolutely problematic and unacceptable in academic writing, CAD publications, and technical manual production environments. (Greyscale images are problematic as well with PDF export). Conditional text? Forget about it. Support for non-western languages typesetting such as Japanese, Chinese, Arabic, etc? Nope. Collaboration is also problematic, since the entire document would have to be managed in one huge file. At least with FrameMaker, InDesign, and Sphinx it is possible to utilize a Git (Github/Gitlab) workflow. And Adobe also provides in InDesign collaboration tools for larger projects and the publishing industry (also third-party support for various collaboration tools if you Google for it). In any case, Publisher R1 is wholly inadequate to fit in a long document workflow. Let's hope R2 does better. InDesign version 1 and 2 were lacking as well, and now it would be acceptable to use it for this type of document project. I prefer Sphinx with restructuredtext (markdown) or just plain old LibreOffice for technical writing & documentation. But that doesn't mean I am not open and hopeful to see Publisher take a stab at these and FrameMaker. Very curious to see if some of the above caveats have had any attention given by the devs tomorrow.

@EganSolo if you are talking about highly structured long documentation, such as manuals, text books, academic type setting and loads of 1bit bitmaps as they are used in these type of more technical documents: the simple answer is NO, definitely not. Even InDesign cannot compete with FrameMaker if highly structured and organized documentation with multi-platform publishing options is the goal. Let alone Publisher. I'd almost say it is preferable to work with Sphinx instead if you are looking to avoid FrameMaker. Almost.

Same with placed 1bit tiff files. Those are silently converted to 8bit RGB files, which is a critical issue. And it does not matter working in CMYK document colour mode or whichever PDF output settings. Let's hope R2 fixes this! Looking forward to tomorrow's presentation. I expect this to be solved in the next version.

That is not a solution. Nor a workable workaround. Not with comic work. The devs have stated they will never support a 1bit image mode in Photo, but as far as I am aware they never said they would not allow placing 1bit image files in Publisher for PDF export.

There is only one thing that Publisher lacks that prevents me from using it for my work. It is my only wish for R2. Place a 1bit tiff image. Export it to PDF without Publisher converting that image to RGB. It should leave it alone. I've given up on 1bit image support in Photo, but please allow for 1bit images to be used and exported AS-IS to a PDF with the background transparent - overprinting the black. That's all. 🙂

Screenshot from PhotoLine as comparison how to implement a good functional Select Sampled Color tool. With mask preview option to show marquee, coloured mask overlay just like Photoshop, and a really nice (optional) black-and-white mask preview. Perhaps in release 2? One can hope.

@Old Bruce Are you sure?

@RasterFarian I too agree with you and the others here. It is, plainly stated, a wrong and confusing use of DPI, and it should be changed to PPI. Although I am almost certain that the Affinity devs will never change this.

@RasterFarian Completely agree with you. When this conversation comes up, I bring up a simple question to explain that PPI and DPI are very different: Why do two images with different PPI attributes print at the same size on paper? One image is a multitone colour image at 300ppi. The other image a 1bit black and white image at 1200ppi. Both print at 5 by 5 inches. If PPI and DPI are treated as being identical, one cannot answer this question. DPI and LPI are part of that answer, as you also mention. Confusing the two is just a plain wrong and misguided use of the terminology. And no: that is not an opinion. That is how they are used in the print industry for decades.

Because the original had all those rounded corners applied with the corner tool, I just wanted to ensure Affinity is working with a pure curve and nothing else. The reasoning: when I zoomed in to edit the curve (on the right side) Designer still lagged terribly. Reversing the curve doesn't matter: the right side of the drawing responds very poorly when zoomed in on a section. The left side does not. The left side of the trunk also performs badly. I found the start and end points, and it doesn't matter. The odd thing is that when I zoom out to 100% or less, the lag disappears. The more I zoom in, the worse the lag becomes.

This file is... weird. I converted the tree curve with "convert to curves" and still got incredible lag. Then I decided to export to a SVG for testing in other apps and found no issues in InkScape, PhotoLine, Illustrator, or Blender. Just in case I re-imported the SVG version to ensure the curve would be an actual baked curve. At which point I discovered really odd behaviour: editing a few points on the left side of the tree, and it behaves smooth like butter. But the more I run along the curve clockwise, the worse the lag becomes! The zoom factor affects this as well. And it affects EVERTHING: even the screen updating. It takes an instant for the nodes to appear when panning the view - but only on the right-bottom side of the tree. Drawing a selection marquee slows down dramatically. On the far left, no issues at all. Here is a comparison between editing a few points on the LEFT side and on the right-bottom side: This counts like a bug in my book. My system: Windows 10, AMD 3900X, 64GB, 3080TI.

I kinda like Krita's start screen approach myself. I wouldn't mind if something similar (as an option) would be implemented. Photoshop offers a similar new start screen nowadays, which I actually find quite helpful to continue to work on projects. But it should be free from unwanted advertisements, of course.

Blender was mentioned here. Since text in a 3d app is "real" geometry, bevels behave like "real" bevels as well. And lighting and materials are of course completely controllable. The following example is a screenshot from the 3d viewport: it works in real-time. No waiting required for rendering to be finished. Although bevels in 3d can go horribly wrong too... Anyway, lettering with bevels is very simple to achieve in Blender.

Irfanview! The one piece of software that I have installed since Windows 95 times. Still use it every day, and it has excellent batch processing.

Krita is NOT a fork of GIMP. Quite the opposite, actually: back in 1998 Matthias Ettrich demonstrated how easy it was to hack a Qt GUI around an existing application, which happened to be GIMP. His patch was never published, and caused friction with the GIMP community at the time. So because the GIMP community was unable to work together towards a better image editor, people in the KDE project decided to start their own image editor, called KImage. That was the start of Krita. and initially named "KImageShop", meant to be a GUI shell around ImageMagick. The name was then changed to "Krayon" due to existing trademark issues related to "KImageShop", and finally renamed to Krita in 2002. All of which brings me to mention here that Krita 5.1 was just released. Krita is wonderful to work with for drawing and painting, in my opinion.

In the meantime the latest 5.1 release of Krita added extended Webp support with every option under the sun