Jump to content


  • Posts

  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You're perfectly right! Although I'm happy to have left the A****-universe behind and to have found a very decent alternative with the Affinity apps I find myself despairing over the Affinity UI (and the workflow implied by it) times and times again. The handling of colours is certainly not the only but a prime example. Having worked in InDesign for many years I do know from that experience that you obviously can get colour handling right. Swapping a global CMYK colour to Spot (PANTONE or self assigned) couldn't be much easier – also InDesign’s feature to just pick a replacement colour when you delete a colour swatch is so helpful and intuitive. Unfortunately I have often got the impression that the guys at Affinity/Serif wanted to make certain things different from the A****-apps for the sake of just being different while not really caring for a smooth and intuitive user experience, which, however, should be the very foremost objective when designing a professional app. Which designer would object if Publisher's handling of colours were actually similar or even identical to InDesign‘s? It's a proven concept that WORKS and I cannot really imagine that a general way of doing things like this can actually copyrighted...
  2. I tried to verify this via their website but I honestly could not find actual proof for this. As you can obviously check overprinting by activating the proper kind of view mode one would have thought that being able to inspect colour separations would have been a point worth mentioning in the features list...
  3. I, too, just encountered problems with pinned objects: in my case the pinned objects were just snippets of "artistic text“ (a simple "www" and an opening quotation mark set in 60 pt and 120pt respectively). No problems at first: the pinned objects flowed with the text correctly – no matter if I added or deleted the odd line or a chunk of text for testing. Just as it should. Then, however, after having decided to set my text to align with the baseline grid I had to adjust the height of my textframes and as a result my "floating" (as opposed to "inline") pinned objects became visibly distorted. As these objects definitely float outside the text frame – while pinned, however, to some character inside – I find this quite surprising (and annoying, actually). Why do they become affected in terms of scaling, when another object which they are only connected to in terms of position is modified? Any ideas about how to understand /avoid this behaviour? _ Affinity Publisher 1.9.3 on Mac (Mojave 10.14.6)
  4. I do acknowledge this. However, I do also think that being able later to identifify the „original“ brush used on/with a vector path can be beneficial in many cases. And as I wrote earlier, one could think of some sort of mark in the brushes palette when a path/curve is selected whose properties have been modifified so it's no longer the default version of that brush. But you would still know that the stroke you see on that vector element is based on e.g. „Oil 3“ and not on ”Acrylics 5“. As of now you don't have almost ANY idea where to start when – especially after some time – you want to recreate or make variations of a given design using such strokes.
  5. I wasn't thinking of raster brushes leaving (pixel) marks on a pixel layer – once applied they are indeed just pixels as any other one on that layer. I'm talking about those so called (albeit falsely) "vector brushes" that you actually do assign to a path (or curve) as the stroke's appearance and at any time can change as to its colour and thickness and which will be transformed accordingly when you manipulate the the curve's nodes (including their handles). Although these brushes, especially those meant to look like natural media marks, unfortunately are not real vector brushes (like those you have in Illustrator or VectorStyler) but are made from pixel images (and thus regrettably are not resolution independent) they nevertheless can be assigned as strokes to vector curves. They are not happening on a pixel layer but on a vector layer as part of a vector curve.
  6. Exactly! I find this very annoying, too and it's long overdue for correction/implementation!
  7. That's actually too bad. I don't really think it would amount to something like rocket science to implement this. If I have assigned a certain oil paint brush (or whatever) to a stroke I don't see why this information doesn't remain connected to the object it has been expressively assigned to (like e.g. its colour which obviously isn't that "volatile"...). Even if modifications have been done to the brush via the Properties panel this doesn't alter the fact that the basis is still a certain individual brush (which even had a name). It could even be indicated by some symbol (red dot or whatever) added to the brush in the brushes panel, that this brush with the object selected has been modified.
  8. This is an important observation and I really wonder why there hasn't been an answer in almost 2 years! I found myself in exactly the same situation today and I feel it's really annoying not to be able to identify a brush used for some curve after the fact. Even if there possibly have been some modifications done via the Properties panel the brush used should still be highlighted in the brushes panel (and possibly its name should be indicated somewhere in its properties panel, too). If there have been modifications (except from stroke weight) this could be indicated by some symbol (like a red dot after its name).
  9. Sorry, I didn't pay enough attention... That having been said, I completely agree to your initial post. I actually think that it's generally a bad thing when the inclusion of basic features like these is handled differently for an app if there is a Desktop version and an iPad version. Especially as a feature like this doesn't really seem to depend on device specific peculiarities...
  10. Which kind of palettes do you mean? It's obviously been possible to import palettes (and export) from or to any Affinity app using the .afpalette file type for some time now.
  11. I guess you're right – and I think it's the same with any stroke around any curve/path. The bad thing is that corners will obviously be completely ignored by default. Accordingly they all look different as to how they are hit (or not) by a dash or dot. The only way a dotted or dashed line can be applied to an angular curve in an aesthetically satisfying way would be to draw it separately from one corner point/node to the next while putting an equal amount of the stroke length to each side of the corner. Then on the section between two corner points/nodes a calculation should happen which equalizes the gaps in a way that an overall even appearance is achieved. This should be possible with any reasonable ratio of stroke weight and section length. As I wrote before: this nothing but pure and rather elementary mathematics and should by no means be an impossible task for a modern and aptly programmed app. I even did that kind of calculation myself when a dashed stroke wouldn't "close" satisfyingly on a circle (though I have to admit it's relatively easy with a circle only because the precise length of the circles's circumference (2 times pi times radius[=half of width]) is always known).
  12. @ firstdefence: Using (small) square or round bullets is an interesting idea as a line of those can be finetuned quite easily regarding their size and spacing. When they form a separate line (of text, actually) that line can also be adjusted vertically by setting its line height or baseline shift. I tried another workaround (see screenshot) by pasting a curve into the text frame (this should be quite convenient as you can still modify it according to your wishes afterwards). While this generally works with "normal“ shapes (see the yellow triangles; one of them shifted down via baseline shift) I had some unexpected difficulties pasting that straight dotted line into the top (empty) line of text. It didn't show up at all first! When I added another node before copying & pasting to make it temporarily triangular it worked, however. I even could delete the excess node afterwards to make it straight again. But it seems to be a bit unpredictable what's exactly happening there – Publisher even freezed once while I was trying this...
  13. @Ken Hjulstrom: The top row of the decoration is visible outside (over the top of) the text frame because of its negative top indent. This is just a vertical shift and it doesn't have anything to do (at least as far as I see) with the left or right alignment.
  14. Ah thanks, firstdefence! I've actually tried to do so, but it's quite fiddly – you have to try out really small variations in the numbers you enter for the indents. Although it may eventually produce something more or less acceptable I found it really unnnerving... As this – to me at least – seems to be exactly the sort of problem computers are here for to solve for us in the first place (it looks like pure math to me, anyway) it actually appears to be quite anachronistic when we are forced to manually enter those miniscule decimals in various input fields to finally approximate a halfway decent result...
  15. This is actually quite a nuisance – you can fiddle around a bit with the „Phase“ setting to influence where the dots/dashes begin, but it's not much use, actually... As this is Publisher 1.9.3 I wonder if this issue has been addressed in v 1.10 or if it's just tha same there. It's obviously related to the issue of dashed/dotted strokes not aligning correctly with a rectangle's (or any angular object's) corners. They just meet those corners randomly with some part of dash or gap... This hasn't been a problem anymore in Illustrator or InDesign for ages now and I'm really disappointed that the Affinity apps don't seem to be able to get it right.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.