Medical Officer Bones

The reason why Adobe dropped Muse is quite simple: Muse's design view was decoupled from the actual html/css/js output. When the development team had to implement support for responsive page designs, it became quite clear how difficult such an approach is to maintain as developers while keeping up with the quickly evolving and changing web tech landscape. Simply stated, Muse became a bear of an application to maintain and develop. This is one of the main reasons why applications like WebPlus, Muse, and many others over the past decade have tried and utterly failed. Muse and its older brethren also tend to save to their custom proprietary file formats, rather than directly working with html, css, and js files (which is just plain silly, because those are open, human readable standards!). This made is pretty much impossible to work with a developer or in a team. A static Muse site's code is a horror, and utterly incompatible and unworkable for a developer to integrate with server-side code or convert to a CMS like WordPress theme (for example). And it isn't even possible to open existing sites in Muse (again because of that decoupling mentioned earlier)! Designers without an inkling about web coding couldn't care less about the code Muse, Xara, or WebPlus generates. They just want snazzy eye candy effects, and that was another reason why Muse tanked. Browsers are an ever-changing live target, and scripts/effects that may have worked two years ago, may cause issues in a newer browser. And let's not talk about the ridiculous size (file size) of some of those Muse sites. In short, Muse was (is) a disastrous approach for proper web development. Great for the odd static eye-catching website or portfolio/online business card and for quick prototyping. For anything else just a Very Bad Idea. And an elephant of an application to maintain for its developers. Always running after the facts. To my knowledge, the only surviving still developed purely visual off-line web page editors are Xara and Sparkle. And both rely on a proprietary file format. Which makes no sense to me: after all, the web is an open standard. Work with those standards, rather than against it. The only reason for a proprietary file format is to lock the customer into their own software ecosystem. Sparkle is a good example how NOT to create output code: they proudly proclaim their home page is created with its home-grown software. Well, the code is atrocious. Designer may not care, but if you plan to work together with a developer, the code is unusable. In contrast, an editor such as Pinegrow actually works WITH the html/css/js files, and will open any standard web page. The drawback is that basic knowledge of html and css is required to make the most out of it. Can't have your cake and eat it too.

Adobe had a good attempt with Muse, but here's the problem: the web and its tech evolves too fast for any tool that decouples the design view from the underlying html/cs/js. Muse had its own design view, as had Webplus. So does Xara. All of them work up to a certain extent, but for the developers it is a constant race to keep up, even if they care. As for Xara Web Designer's reviews: you can tell people's expectations and skill sets are all over the place where web page development/building is concerned. Some except simple templates, others full visual design control over the page elements similar to a DTP app. It is difficult to please this crowd. Also, Xara Designer Pro (as opposed to Xara Web Designer) not only includes all the web export stuff, but is also similar to Affinity Designer as a vector illustration app with page support. I recall users of Muse (for example) kept asking for more features they'd seen used on 'forward thinking designed snazzy looking' web pages, and at some point Muse just became an elephant. Impossible to maintain by the developers. That is why so many web page builders now rely on a design view based on html/css/js. Pinegrow is a good example. Or look at WordPress and the variety of visual web page builders like Elementor or PageBuilder. With Elementor there is no need to deal with posts at all, and just work with pages the way you envision. But usually this comes at at a cost of design flexibility/freedom. The other product you may like is Sparkle, which comes close to those visual web builders of old. But it is Mac only. And uses a proprietary format, so again a de-coupling from the web And visual web building tools are generally meant for small static web presences only anyway.

Not entirely true: Xara Designer Pro / Xara Web Designer exists, and does exactly that. But for the sake of a web developer's sanity I'd say Pinegrow would be a much better choice with good human readable code output. Not quite as much freedom as drag and drop, but close enough.

I tested this file in various applications: Affinity Publisher, PDF Exchange Editor, Xara Designer Pro, Affinity Photo, PhotoLine, InkScape,... I don't have a license of Designer myself (yet?). The file chokes up all apps. Some take ages to open it, others (Xara) once opened each move takes forever. Xara is one of the fastest vector rendering engines on the market, but while the file will load, every change takes a long time and Xara chokes. And Xara works absolutely smooth with some very heavy vector files. PDF Exchange Editor is the fastest of the lot and works reasonably well. But that's only for viewing. Still takes a couple of seconds to render those dots when zoomed in. With this many vector objects I don't see how ANY software is going to be able to work in a smooth manner. This file is NOT meant to be edited, but meant for output only. Those dot patterns are usually created at print/output time, and not meant for editing. I think no hardware in the world is going to give you a smooth vector editing experience when dealing with files like these. Perhaps reconsider your workflow.

Yes, as long as 1bit support is lacking, we will have to deal with work-arounds, or just rely on alternative software. A bit frustrating, because when I open your PDF in PhotoLine it takes two clicks to create the proper 1bit layer and overprint it. Two more clicks to assign a spot colour. InDesign treats these type of 1bit tiffs automatically as overprinting. Let's hope the Affinity devs will add this support before 1.7 is released. I think, because of the lack of 1bit support in the other Affinity apps, this may take longer for them to implement, however. I suspect it's just not part of the core functionality of Affinity, and will take more effort on their part. Thanks for all your testing!

Here is an infographic explaining the comic printing process. If printing on high quality glossy paper, a ppi resolution of 800ppi for the 1bit tiff file is a good idea, but it might be higher than that depending on the quality of the printer. The colour may be printed at 400ppi for high quality prints. Publisher is unable to achieve this workflow and retain the resolution of the black line art.

You are missing the point. Do you understand how halftones and LPI (lines per inch) work in print tech? If not, look it up. Printing black and white line art at 300dpi is too low for a quality print. Refer to @Fixx answer about terrible looking comic strips and lettering when printed at 300dpi in a news paper, or in black and white print.

Yet, there is. 1bit prints without being rasterized to half tones. 8bit is always rasterized and converted to halftones. A grayscale 8bit image contains 0-255 shades of gray, and even black will be printed at 300dpi (dots!). A 1200ppi 1bit black line will, however, be printed at that resolution (barring the quality of the paper, and the subsequent dot gain).

You explained it more succinct than I did. Indeed! Here is an example of the wanted PDF output. The black line art is 1200ppi and set to overprint, and the colours are 300ppi. Notice the difference in pixel size. The colour work will be halftones, while the 1bit line art will retain its sharpness when printed - just like black text, or black vector art. No halftones there. Absolutely essential for all sorts of print work. Without this option, Publisher is going to be handicapped from the very start. Just like Affinity Photo is with the lack of 1bit support.

As I explained, the black-and-white line art is printed at a much higher resolution than the colour work. Same as with black vector and text: those are printed at the image setter's / printer's native print resolution (this is a gross oversimplification) not needing any dot patterns (halftones) thus printed much sharper than grayscale or colour art. It needs to be 1-bit because of that. Because it prints at the native print density of an image setter or printer. You can't have any anti-aliasing, because dot patterns are not allowed - or at least, you can control your own dot patterns (halftones). I checked your PDF, and yes the left circle overprints. But all shapes are anti-aliased, which is also unwanted behaviour when doing this type of work. And all shapes are 300ppi, which is useless. We want to retain 1bit high resolution art, and overprint that.

@thomaso The problem is that 1bit tiffs lose their original high resolution when exported to PDF, and cannot (as far as I am aware) keep their original resolution and overprint. For example: I create 1200ppi 1bit ink drawings, which are then overprinted on top of 300ppi full colour renderings. InDesign and PhotoLine have no issues with this. Publisher cannot handle 1200ppi 1bit TIFF files and when exporting to PDF downsamples the ink drawing to whatever document ppi is set (max 400). Which is useless for comic work. We need at least 600ppi 1bit line art for acceptable print quality. Same problem with 1bit 800-1200ppi artwork that must be printed in other circumstances, such as printing on metal (example above). It won't work in Publisher, and always downsample and convert to 8bit art and lose the actual resolution.

Gimp's "animation" options are (sorry) extremely limited and awkward. Use either Krita or OpenToonz instead. Editing gif animations in OpenToonz is very effective and easy in my experience - and extremely powerful. OpenToonz imports and export gif animations if the ffmpeg executable is set up in the preferences. A joy to animate with. The timeline supports layers, of course, although the way they work is different compared to image editors. Krita's timeline is also quite good for animation, and works with layers (in this case just like Affinity).

PDF might be an option. At least for regular and rotated text. Most editors import PDF with text intact. Or perhaps use transparent PDF form fields for your map text with text already filled out, and center text aligned. But curved and distorted text will always be converted to a graphic object, and no longer be text. Alternatively, provide your maps not only as a PSD, but also other native formats (Inkscape, Affinity, ...) And if you do need to provide PSDs with full text editing functionality, you may have to invest in renting Photoshop or get an older CS6 version, or something. Perhaps even the CS2 version will suffice? I mean, if this is important to make a living, I don't think it is a good idea to ignore what your users use as software. Better to accommodate them. I still use an older version of CS6 of Photoshop to deal with these cases myself.

Had a quick look at the 1.7 beta today, because one of my pet peeves of Photo are the small layer thumbnails in pre 1.7. When I first saw this mentioned as an improvement, my spirits skyrocketed...! ...only to crash and fizzle out. Three fixed thumbnail sizes? Even Photoshop offers up to 80px. (which is still too small a max) I hate to be a party pooper, but... Why limit the software to only three fixed layer thumbnails sizes, of which the largest one is still too small (62x62px) for many users, screens, and use cases? Why not introduce a seamless slider and a minimum of 5 presets, and an upper limit of at least 192px or even 256px? Well, I suppose it's an improvement. It is better than before, and usable as opposed to pre 1.6. A bit of a missed opportunity.

Following the reasoning of the OP, ink colours on paper are subtractive, while colours on the screen (RGB) are additive. 100% CMY on paper produces a muddy brown. 100% RGB produces white. So I assume the OP expects that working in CMYK mode should be behaving likewise. But blend modes always work in screen colour space, as far as I am aware. One solution is to turn on overprint for those objects in Designer, for example.