Lorox

That's strange! I just tried PACKZVIEW with two of my recent PDFs meant for printing services (both exported from Publisher) and I had no problems whatsoever (10.14.6 Mojave on a mid 2019 iMac). What this viewer obviously offers is basically just what I was primarily looking for (and which so far had to be done on my older machine still having Acrobat Pro): a quick check on colour separations, ink coverage and overprinting. Nothing too fancy, really, but actually very useful! One might wonder why an app just providing these basic features hasn't been offered by Affinity/Serif – say: as a free giveaway on any purchase of Designer and Publisher – to give their users that little bit more peace of mind once they're going to actually send their PDFs to some printing service.

Is this related to the behaviour I've observed previously that everything(!) on the Publisher page gets rasterized in the PDF when an object with transparency (e.g. a drop shadows) happens to be somewhere(!) (on) the topmost layer? (meaning that this object doesn't necessarily have to overlap vector objects, especially type, on lower layers which got rasterized no less...) In InDesign flattening/rasterization always seemed to happen limited to the area where it was needed but with my first Publisher PDFs I was absolutely surprised that this happened actually pagewide to all objects on layers below an object with transparency no matter where the latter was positioned on the page or how much space it actually took.

Good reminder! I've really loved the features Scriptographer had to offer within Illustrator, especially when working a bit more experimentally than usual. I'm actually happy that I've still got a working version of Illustrator CS5 with Scriptographer installed. If such functionality could be added to Affinity Designer it would be truly amazing!

Which is exactly the basic functionality I'd generally need in my everyday workflow to check PDFs that are to be sent to a printing service...

I've checked this one with an Affinity generated production PDF (just CMYK) and at first glance it offered just what I generally(!) need when I check my PDFs for correct colour separation (e.g. the old 100% K Black problem, overprinting, accidental spot colours etc.). I was definitely surprised that it could offer me exactly the information I generally need to decide if that PDF seems fit for the printer or if there's something that should be corrected (e.g. by going back to Publisher make the corrections and exporting a new PDF). Even if you cannot make any of those advanced preprint corrections, conversions etc. within PDFTRON it certainly looks like this might actually be a very decent tool to quickly scan the PDF you want to send off to your Printing service and be sort of sure that at least the colours are set the way they are intended to. Just for this functionality (which is probably 95% [or even more] of what I normally do with my PDFs in Acrobat Pro) I'd probably be willing to buy it for a reasonable price as a standalone app... a very good find, Kal!

As far as I know this feature (at least as fills and strokes are concerned) has been added in version 1.8. Effects like those in Illustrator would be highly welcome, though!

I guess that's what happens when you design an otherwise powerful and comprehensive program more or less from scratch. You're bound to forget some little things here and there – or maybe you didn't ask actual designers and digital artists really all the proper questions beforehand... As we haven't even got to version 2 I tend to be optimistic, however, that these things will be addressed sooner (hopefully) or later. Same thing IMHO with dashed/dotted strokes, which so far – with closed shapes – don't automatically align at their beginning/end. Neither can they be made to "pay attention" to corners (e.g. put a dot of a dotted line exactly at each corner of a rectangle) like it's been possible in Illustrator and InDesign for years and years now. I keep hoping, though...

It depends on the circle's radius and on the stroke's width, whether the first and last dot will align. What you're basically trying to do is to (seamlessly) put objects of a given size (the dots) on a path of an (inpendently) given length (the circle's circumference). Obviously this will only succeed if there is a certain ratio between the width of those elements and the overall length of the path. With random values of the circles radius/diameter and of the stroke's weight it would be just pure chance if the first and last dot align (visually, at least). If you take your circle's diameter as given you have to tweak the stroke width to make it happen – or, if you take the stroke witdh as given you'll have to adjust the circle's size ever so slightly to make a whole number of dots (whose diameter equals the stroke width) to just fit in.

If I see it correctly you're basically estimating the length of the path here by trial and error (coming up with 23.74 [pt]). If the second value in the dashed strokes panel equals the length of the path [in pt] you're dealing with (and all other values are set to "0") you will get just one dot at each end of your path (one round cap ”pointing inward” and the other round cap pointing ”outward“ – between these points (whose caps do NOT count) you have the "gap" that you found out (the length of which happens to be equal to the length of your path). If you by some means could easily calculate the length of any given path even reshaping and readjusting wouldn't be too difficult – but alas... However, with sort of "perfect" closed paths like circles and squares it is considerably easier as the circumference of those (= length of the paths) can be calculated qickly using basic math.

Maybe if someone is still interested in this topic... I found that you can actually calculate quite precisely the value you have to set in the (Dashed) Stroke settings to achieve an exact beginning/end of the dotted line without any overlapping. This is for simple, evenly spaced dotted lines with dots in the form of perfect circles. Notice: You'll have to use a consistent unit for any values of lenght or width (e.g. pt throughout)! You will have to make some conversions, if you – e.g. – have millimeters as the general unit but points for stroke width! First you have to know (or calculate) the total length of the path you want to apply your dotted line to. Then you have to decide how many spaces you want to have in total between the dots (e.g. you'll want to have 12 even spaces when you want do a clock face with the dots at the usual positions). When you divide the total length of the path (circumference) by that number of spaces you'll get the length of a single space. (*) Then, be sure to choose the rounded caps In the stroke palette first. Down below where it says ”Dash:" you set "0" as the first value (this is the ”lenght“ of the dash – but we want to see only the round caps added(!) at either end of an otherwise "not existing" dash...). The second value, however, controls the width or lenght of the space (or gap) between the dots. It is actually a multiple of the stroke width you've set at the top. If you set it to "1" the space or gap between the dots is exactly as wide as the stroke width, which results in the dots just touching each other as the gap is filled by the two semicircles which are just the rounded caps of two consecutive dashes (of “zero“ lenght). Accordingly when you set that second value to "2" (meaning: 2 times the stroke width) the (visible) gap between to dots will be just as wide as the dots themselves are. The trick now is that you have to divide the single space (or gap) length you have calculated above (*) by the stroke width you want to apply. The resulting number is the value you'll have to enter in that second field mentioned just before. Then the gaps' length will be adjusted correctly to give you the number of even spaces between the dots that you defined at the start of these calculations. I'm aware that this works well when you can actually distribute spaces but it won't work well with a circle or path of a given(!) circumference an a given stroke width when you want the dots to just touch each other (as there is no space you can evenly distribute to achieve this). In this case you will have to adjust the lenght of the path instead just so that a whole number of dots (having the diameter given by the stroke width) will fit exactly within that lenght... It's a bit tedious, actually... (but you can make it work once you have certain measurements; with free form paths it gets close to impossible, however and you'l just have to use trial and error on that value controlling the gap width). I wonder, however, if anybody can follow my mathematical amifications here... (I beg your pardon). Ah, and well: I think these calculations should actually by made by the app/computer and not by the user...

I find it absolutely unnerving that when I copy an object that has been assigned the global colour à la "My Super Red" to a new document this color ist obviously lost as its occurence in the colour palette(s) is concerned.While the object seems to (visually) retain the colour assigned in the source document the corresponding swatch won't turn up in the palette(s) of the target document. Having worked in Illustrator or InDesign for years it just seemed so natural that objects sort of carry their colours' names with them as they are copied to other documents. This should be possible in Designer or Publisher as well. If refreshing the palette(s) should be required to have them listed so be it... Also something like "Add used" or "Delete unused" regarding to colour swatches should be added as it is so very helpful to streamline the colour palettes within a given document to show just ALL colours that are actually (globally) used and show ONLY the colours used in that document to have it all nice and tidy.

It's certainly dearly missed. But so (still) is the Blend Tool which I consider as at least as mandatory in a vector graphics app. It's been promised (in some earlier post on the forum) for a version before 2.x – I wonder how close we actually are...

Ah, sorry – I messed this up. But I guess what's irritating me is that when I press D for the default colours the top left circle (secondary colour) is placed in front of the bottom right (primary). Maybe I instinctively expect the primary colour being brought to the front... (wouldn't everybody?)

I just looked this up – seems to me that Flip PDF actually does not generate HTML5 but a Flash based version. As this is not current tech/coding it would also explain the outdated interface. Correct me if I'm wrong.

Thanks a lot! I was just about going crazy – thinking I did something wrong and not being able to figure it out... I do hope this will get corrected in the 1.9 Alpha, though, and Serif will be more user friendly than Adobe where certain bugs introduced with some update stayed with the programs ever after...

I guess it has to do with the concept of foreground and background colour (like it is in Photoshop) which to me seems so "natural": with an image or an empty canvas you have a background and – as the most basic operation – you take a brush and you can paint on it or fill areas with a colour. To me it makes a lot of sense it intuitively to perceive that colour I'm actively using in this sense as the ”foreground colour" or the "primary colour" as it is the one used to actually leave a mark on the canvas. Seeing the two colours as just equivalent ones to choose from as desired is certainly legit a way to perceive it. But: if there's nothing individually special about these two why stop at just 2 colours and not offer a small palette of – say – 3, 4 or five equivalent colours? In my perception just offering exactly two colours only makes "real sense" if these two have some associated "meaning" that makes it plausible that you decide just for one or the other. The concept of foreground colour and background colour exactly does that but discerning just between "primary" and "secondary" actually seems quite arbitrary comparatively as it is by no means clear that you shouldn't have a "tertiary" colour (or even more). Possibly it's just about how our brains work (or my brain, at least...). The same goes for the order of the two coloured circles signifying the primary resp. the secondary colour: personally I actually tend to perceive the bottom right circle (secondary colour in AP) as being a bit "closer" to me therefore I seem to intuitively identify it as the "primary colour" whereas I feel like the top left circle is slightly farther away from me and I'm therefore inclined to see it as "secondary"... Maybe it would be different if there was top right and a bottom left circle instead? Maybe, maybe not. But then this might be just me anyway...

Yeah, of course. But I just don't get logic behind it...

Hi Ray, you're right. I hadn't really noticed the switching of the colors once the brush is selected. But black remains the secondary(!) color as this is defined as such by the position at the top left (as it has been officially said elsewhere on the forum). I don't see why black isn't considered the default primary colour as it would seem "natural"... or why a brush should turn to the secondary color straight away...

I'm just finding that I obviously cannot fill a selection on any layer by using the keyboard shortcuts I've assigned (See screenshot: cmd/backspace for ”Fill with Primary Colour" and cmd/alt/backspace for "Fill with Secondary Colour“). In any case if the layer I'm on is just transparent nothing visible happens and when pixels are within the boundaries of my selection they just get deleted (as if I had just used backspace without cmd or alt/cmd). The selection just doesn't get filled by the Primary or the Secondary colour... Going just by the menu works and using the ”Fill"-palette/dialog (shift/F5) also works. The keyboard shortcuts I assigned don't (although the don't seem to conflict with other shortcuts). Am I missing something here?

Hi loukash, I'm 100% with you here. Exactly the same with me in every respect! As long as certain must have vector graphics features don't find their way into AD and Adobe is out of the question because of their subscription policy I highly value having Illustrator CS5 on a Mac running El Capitan... I'd so much like to fully switch to Designer but unfortunately there's still a couple of feature and tools I'd miss dearly if I did.

There's something that really confuses me: When I create a new file I get an empty space/canvas filled with white – just as I would expect (like a new sheet of papaer to paint on). I then hit the "D" key to set primary and secondary color to their defaults: now the circle bottom right (supposedly the primary color) is white, while the circle top left (secondary color) is black. Why on earth is this considered to be correct – or the proper default? Shouldn't actually black be the "real" primary color here as I start with a white background on which my current default primary color (white) won't leave any trace??? When I was working in Photoshop the behaviour has always been intuitively correct: create a new file (having a white background), set foreground and background colors to default (same "D" key shortcut), result: get black as foreground color (translates to AP's "primary" color, I'd say...) and get white as background ("secondary") color. Start painting: get black marks on white background. Nothing to crack your head about here... But in AP it seems to be just the other way round when you creats a new standard white canvas but also get white as the default primary color which won't leave a visible trace... I just don't get the logic! Can anyone explain?

As I used to have some issues with my PDFs for professional printing (mainly Black not being 100% K but some CMYK-mix) I just want to share my latest findings. Ah, and this applies to Publisher (only) as I haven't yet created any PDFs for print with Designer (and – neither having done so with Illustrator in the past – I don't think I will). Anyway, when fiddling around with Publisher (CMYK document) lately I noticed that some text I'd assigned „Black“ as the fill colour seemingly proved to be just 100% K (as intended) when looked up (double clicked) directly from the „Greys" (in "Swatches") panel but – strangely – being a mix of CMYK when looked (double clicked) up from the ”Colour" panel. (see screenshots) I couldn't make any sense of this and found myself completely confused after some clicking here or there just to find out what colour was actually assigned... I then decided to get rid of the default ”Greys" swatches (including "Black“) altogether as I felt I just couldn't trust them to be what I thought they should be (in a CMYK document, at least...). Instead I created a new application palette comprising of K-only Greys (including a 100K Black). Then I created the document attached here using the 100K Black from that palette and exported it to PDF with the export settings as seen in the screen shot. Checking the PDF with Acrobat Pro proved that everything was actually as it should be – on first try! I'll keep an eye on this – maybe there'll be no second and third exports needed anymore... (fingers crossed) ColourTest_AffinityPublisher_ISOcoatedv2_300.pdf ColourTest_AffinityPublisher_ISOcoatedv2_300.afpub

No, obviously (and sadly) there is no separation preview yet. I wish there was, as these "details" as you put it are quite annoying to me , too. I'm actually a bit tired to have to run my Affinity exported PDFs through Acrobat Pro (which I fortunately have, but many among us may not) several times to hunt down those spots where these separation issues occur (most of due to Black not overprinting as it should). As to your example screenshot: are you sure that "Global Colour 155" you apllied to your text is actually just 100 % K and nothing else? More often than not I find that the colour applied to text that I was quite sure I had chosen Black (from the swatches panel) for wasn't actually 100% K but some "rich" Black containing degrees of CMY. I suspect that when I convert to or assign a CMYK colour profile to my document the grayscale swatches (including Black) don't get by default converted to just 100 % K (for Black) or percentages thereof (other grayscale tints). Or maybe elements which had been made "Black“ before retain their "old" mix-of-CMYK Black as those Grayscale swatches don't seem to be global by default. This certainly is harming me an my joy of using the Affinity apps, too, as each and every time when I finally check my PDFs meant for printing there seems to be some issue of this kind – something that has been an absolute exception during 15+ years of working in InDesign...

@Jiorgos I'm actually trying not to rule out Publisher as a tool for productive use as I'm thoroughly fed up with Adobe's general policies. I do want the Affinity apps to stay on the the scene and successfully compete with the near-monopolist. That being said I think that what's happening here in the forum is important to make the Affinity team work even harder to finally and fully make the apps live up to their promises. I really hope these issues we're talking about will be resolved sooner or (rather not so much) later... I have to admit, though, that so far I tend to use Publisher productively only on small projects (the odd flyer or leaflet – completely new or maybe even migrated/converted from InDesign) where there's a good chance any glitches won't slip through unnoticed (and if they do nevertheless the actual damage will be quite limited). Right now, however, I'd in fact be very reluctant to use Publisher on any job where hundreds or thousands of euros/dollars in printing costs will be involved. But – exactly this will have to change: professional users must eventually be able to be confident straightaway that their designs for any project will be output in a correct state of the art way for commercial printing without having to worry what could have gone wrong again this time (colours, rasterization effects etc.). A truly ergonomic user experience and bulletproof reliability regarding its final output for me is what will really make a publishing app meant for professional and productive use actually "professional" in the end.

Exactly... For all of of us who do design for print this is so annoying. Each time when I'm finished with designing and I want to get proper PDFs for offset printing to my printers shop it gives me such a headache as from the Affinity apps' (especially Publisher) settings (document setup & export settings) I strongly feel like I've really set it all correctly but somewhere there must be some glitches in the underlying logic of the apps because more often than not I find the PDFs not to be what should have been expected considering the settings having been made (primarily "black" not turning out as just 100% K). With InDesign you just set up your general colour management once for your apps, choose the colour profile you need/want on export and everything will be fine in 99+% of the cases. You just don't have to worry about it – it's highly reliable. With my Affinity produced PDFs, however, I'm unfortunately dreading each time what Acrobat Pro will actually unveil... It doesn't feel good and doesn't match the good feeling I – admittedly – generally have when I'm still in the process of designing with Publisher (even though there are some things I wish were handled more ergonomically by or added to the app).