Jump to content
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.


  • Posts

  • Joined

  • Last visited

Everything posted by Lorox

  1. Choosing the settings from your screenshot doesn't make a difference: 100 K black is converted to 70C/60M/58Y/84K when the profile used for PDF output differs from the document' s profile. Yes, sure, I did intentionally use another profile for output as the the original document's profile as this is what definitely should be possible using colour management: being able to deliver PDFs with fitting profiles for various printing environments from ONE and the same document (without changing the original colour profile of the document itself). The necessary conversion is – in my opinion – the key feature when you have to deliver to different printers / printing processes and this conversion process MUST honour essential settings as 100 K for black text and the keeping of values/"Numbers" for non-image (i.e. vector) content (just think of a client's logo having fixed/defined CMYK settings). So this – somewhat oddly named – "keep numbers" feature of InDesign is something that has to be implemented in Affinity Publisher as soon as possible.
  2. Coming from Adobe InDesign and actually being highly motivated to finally switch to Affinity for good, I find the way Affinity Publisher handles these things very irrtitating. From the start it has been the desired effect of efficient colour management that you could design your document in a certain colour space (say: the one appropriate for offset printing on coated paper – using the corresponding colour profile as your file's colour space) but NOT being confined to that colour space chosen in the beginning as you could choose another colour profile later for outputting to PDF, should the necessity arise to have your design printed in another way than originally intended – e.g. on newspaper stock where different printing colours behave totally different on different paper. This has hardly ever been a problem in InDesign as during output colour spaces have been converted quite reliably from the document's colour space to the colour space of any special printing process for which you'd need a PDF equipped with the corresponding colour profile. However, with Affinity Publisher, it somehow doesn't work this way: I have done some testing today in Affinity Publisher 1.8.3 with 2 afpub-files – one setup with general European standard "ISO Coated v2" and one setup with "ISO Coated v2 300%" which is pretty much the same profile but with a reduced ink coverage of 300% (which is preferred by many online print services due to shorter drying time of the prints). I was especially concerned about black text (100% K) being unadvertedly converted to mixed CMYK values as this is something you really just DON'T want. Checking the created PDF-files with Acrobat Pro showed that 100% K text had only been preserved in the PDFs if the document colour space was exactly the same colour space that you had chosen in the settings for PDF output (here PDF/1-a:2003). Meaning: document (ISO Coated v2) > PDF (ISO Coated v2) and document (ISO Coated v2 300%) > PDF (ISO Coated v2 300%) both kept black text just in 100 K as intended – no matter if just the »standard« black colour swatch from Publisher was used or a new, specially created 0/0/0/100 global colour in the »Document« palette. So far so good... However, going "crosswise" by document (ISO Coated v2) > PDF (ISO Coated v2 300%) or document (ISO Coated v2 300%) > PDF (ISO Coated v2) both ways of profiles not matching for document and PDF output got the previously 100 K text converted to that "rich black" of various CMYK values that you get when you convert RGB Black to CMYK. You don't want this EVER. To me this behaviour seems to completely ignore the intended use of colour profiles for being able to create PDFs with different colour profiles for different printing scenarios from the SAME original document, which most professionals have used succesfully for years with Adobe InDesign. Why does it get so complicated with Affinity now? BTW: Changing the Colour Profile used by Adobe Acrobat Pro while examining the PDFs between the 2 profiles mentioned resp. used in the files doesn't change anything about the values that are given for the black text elements.
  3. Regardless of what script language might possibly be the "best" (due to lack of knowledge I'm regrettably far from voicing a sound opinion on that) I have to say, though, that I'd VERY much like to have scripting support in the Affinity apps. From a practical point as a designer/user I'd really love to have the sort of possibilities I had (or still have) with the Adobe apps (especially Illustrator) that rely on the use of customizeable scripts leading to special visual "effects" which the app by default doesn't offer.. From this point of view I'd think the actual script language to choose would be the one which best supports creation, distribution and (non-techie)user-friendly usage of interesting scripts...
  4. Thanks a lot! I had that very same question (possibly after having accidentally turned on that option while creating a preset for snapping...)
  5. As this post is (again) half a year old by now I'd really like to renew the question. We're in 2020 now and SVG Fonts (coloured or not) are being offered everywhere by quite a lot of type designers. I'd wish Affinity would take the chance to acknowledge this development head on by making their apps capable of using these fonts as soon as possible. Why send all those designers who want to create with this not (anymore) so new font technology straight (back) into Adobe's hands again? I certainly understand when you don't want to include too many (probably exotic) features into an app in order to to avoid it becoming bloated and slow. But then again I personally find the thought of specialized plugins quite intriguing which might offer special features to interested users who then could fine tune their basic app(s) to their respective creative needs.
  6. I'd REALLY like to have the opportunity set an axis for flipping, too! Maybe by just holding the ALT key when clicking on the "Flip" button and thus being offered to set a point (and perhaps an angle, too) for the axis to go through first and then actually flipping as a second step. A bit like in Illustrator (it wasn't ALL bad with the Adobe apps – you gotta learn from your enemies, anyway...). The solution by firstdefence shown above is quite ingenious, though, as a workaround. I really wouldn't have thought of that way to do it.
  7. Possibly, I haven't really thought of it this way... Personally, I think that Adobe has it adressed quite satisfactory: in InDesign all handles firsthand affect only the container as such and the content stays as it is (except from text flowing differently by forming longer or shorter lines according to the changes in the size of a text frame). But when you press the command key while dragging the handles the frame's content gets scaled along. You learn this once and you've got it, I'd say.
  8. As I in fact like the dark UI style because it generally shifts the visual focus clearly to the artwork, I do, however, wish there would be more options than just chosing wholesale between a light or dark UI. My main concern here is the Brushes Palette, where I'd really like to see the brushes (or brush marks) dark on a light background – even if the UI in general ist set to dark mode. Although I do know that today many well established graphic applications/programs do it likewise (for instance Procreate on the iPad) I'm rather convinced that most users would find it a lot more natural in look and feel if the Brushes/brushtips/brush marks were displayed by default as dark on a light/white background. This corresponds jus so much more to everyday experience with natural media and thus helps a lot when deciding which one to use. We all know that flipping dark and light in a visual medium is more than just a formal decision. Our whole culture of visual communication has so far relied mainly on leaving darker marks on a lighter background and I feel that this experience is a strong influence on our perception of what is seen as "natural" and it really shouldn't be neglected. This said I think it is actually quite problematic to just switch dark and light rather indiscriminately within an graphic interface without paying attention to details where it just doesn't make much sense. Also there are factors directly related to physics/optics: many of us will know that for instance in well designed signage font weights are in fact altered when a sign has to be switched from dark on light to light on dark – not because it should look different but, on the contrary, to be perceived as identical in terms of balanced weight although some parameters have actually been changed. So I'd highly appreciate an option to have Brushes displayed dark on light background in all Affinity Apps regardless of the chosen general mode of the UI.
  9. Yeah, totally supported by me. It's such a super useful tool for intuitively combining shapes and speeding up the design process! So please give us an equivalent of the Shapebuilder Tool in AD version 1.9 (at latest...). Would highly appreciated!
  10. I totally agree with this request. Something like the Shapebuilder Tool would be a HUGE addition to Affinity Designer in terms of ergonomy and speed of workflow. I actually ignored the tool in Illustrator for some time as I already had other established ways (Pathfinder etc.) of combining shapes, but when I finally took up using the tool I was amazed how easy and intuitive it made the process. Even though I try to use Affinity Designer ever more and really want to prefer it to Illustrator I always find myself missing that super helpful tool every so often! So please, please give AD version 1.9 an equivalent to the Shapebuilder Tool.
  11. You mean the paragraph decoration? Check scale with object there. Yeah, I guess it's actually called that way (maybe I came up with "embellishment" by mistake). I hadn't noticed that "scale with object" option there and I'll check later – thank you, though!
  12. Before I forget: Two things I noticed when scaling text frames via the scale handle 1. Why do we only have ONE scale handle (at the bottom right corner)? Regarding the position of a text frame on the page it may well be more convenient to scale from another corner, I'd say. As all corners are otherwise basically equal in terms of handling an object/element it seems only natural to request Affinity to add scale handles to ALL 4 corners of a text frame with a coming update. Doesn't it? 2. When scaling a text frame with the scale handle the text and its attributes are seemingly scaled wholesale (as desired). But as this seems to be the case with most inline formatting and text styles as well (font size, line height, indents etc.) I noticed that an underline within my text (being in fact a paragraph "embellishment") remained at its original line thickness and had to be adjusted separately afterwards. Is this by any means intended or is it just a minor bug?
  13. Hi Dominik, this actually sort of (but not quite) does what I need, although I'd prefer (maybe by habit...) to first set the page/document to the new size and then adjust the elements or building blocks separately and – for precision – numerically. Sometimes there are certain elements on the page that for some reason or other I actually don't want to scale exactly like the majority of the other elements – so having the page/document size right as a start and then being able to scale numerically feels a lot better for me (especially when I – e.g. – want type within a text frame go from 12pt [before] to exactly 24 pt [after] and not to 23,87 or so – which might well happen if just adjust the dimensions in Spread Setup and let this compute the scaling percentage...) However, you can get pretty close (as to my example) by first dialling in exactly double measurements in Spread Setup and let it do the automatic and exact 200% scaling of all elements and then adjusting single special elements manually. When you have that sort of document where the bleed is actually included beforehand within the page size (as most online print services like to have it) you may have to adjust the overall Spread Setup a second time to correct the included bleed which often stays at acertain value (say 3mm) regardless of the document/page size being A3 or A2. Furthermore I find that when doing the scaling (of a text frame) manually (because you cannot do it manually for the reasons discussed here) it may by helpful to use some dummy element which CAN be scaled numerically instead, though, and use this to snap some guides to it which then again can be used to snap the text frame to them when doing the manual scaling. This seemed a lot more relaxed to me than moving my hand/mouse/pen in those microscopic increments when trying to exactly hit that certain scaling percentage you're aiming at.
  14. But what can I do if I want to scale numerically to an exact percentage? Always having to do it manually doesn't seem quite satisfactory as sometimes it's actually a bit hard to move the handles exactly by small very small increments to achieve a certain exact scaling percentage.
  15. I think being able to choose between the two sorts of handles (thus deciding how the scaling should be done) is basically a good idea. I wonder, though, how do we use this when transforming numerically via the Transform panel? My recent problem was like this: I had completed an A5 sized flyer layout and then the client also wanted a version in A3 size (meaning just a scaling of exactly 200%) as a "mini poster". As all the proportions of the elements on the page – including textframes ond their content – should remain the same I'd find it the easiest way if I could just select ALL the elements on the page, set a scaling of 200% in the Transform panel and press "Enter". This, however, doesn't work as doing it this way only scales the text frames as containers but not the contents (text size etc.). Obviously you cannot discern between the 2 sorts of handles when doing it this way – but on the other hand, if you do it manually using the handles it's sometimes hard to move the handles really precise enough to get the scaling percentage absolutely right... I sort of seem to rememer that when doing such a thing in InDesign it helped when you just grouped all the elements before applying the numeric scaling – this way the apperance of the elements (including any text formatting) was scaled keeping all the original relations (as if it were an image or like when you set a scaling factor for printing). Is there really no way to do this in Publisher but the manual one using the outward "Scale" handle?
  16. I see – I faintly remember that "resetting" the bounding box of previously rotated objects by a similar method proved useful sometimes in Adobe Illustrator, too. What I do not understand, though, is why this empty "ghost space" is not taken into account when I select all those elements altogether WITHOUT grouping them. It's there when I select a single one of these two (the diagonal red stripes on the right; or the the group or the layer containing them) but it immediately disappears when I select any single or multiple other with it (even if it's just the second one giving us this effect). Is there any logic behind this?
  17. Sorry if I recently haven't quite kept up with new posts here. Having read all your friendly contributions by now, it seems to me that the behaviour I observed and made me start this topic is actually most likely an issue of how macOS handles temporary storage of data used by the apps. I don't really think by now any more that it is linked predominantly to the Affinity apps the use of which triggered my observations, nevertheless. Obviously the apps themselves DO use/need their respective disk space of about 1.7 GB on machines other than mine as well. Having been along when state of the art (at that time) graphic design apps used to be installed from a small number of 1.4 MB(!) floppy disks I wasn't really prepared to see a size of 1.7 GB as something not really out of the normal. My latest version of InDesign (10 years old...) takes only about 400 MB on disk. (I just noticed, however, that Acrobat 9 Pro, which is an old app, too, uses about 1 GB of disk space and has most likely done so for all those years! ) I also learned something about Time Machine that I didn't know before ("local snapshots"), even though I had been using it for about 10 years... Thanks for that! Anyway, I'll keep an eye on the issue, nevertheless and maybe come back to it later, if I encounter something that possibly deserves clearing or discussing. Meanwhile I've (mostly) shifted all Affinity apps work to my other, faster and newer iMac, where there's more available disk space, anyway. It's nice though to have that fallback option to the older machine with the Affinity apps as moderately older versions of macOS are still being supported – I highly appreciate that! When you have a system that's running smoothly (and is still safe enough) in general I find it extremely annyoing when you're sort of forced to have an OS update just because an update of some your main apps suddenly won't run anymore (or start being unreliable) on your favoured system. Eventually that's inevitable at some time – I know – but especially Adobe generally didn't care very much about backwards compatability. So it's good to see Affinity hasn't been so demanding in that respect so far...
  18. Yeah, exactly. The diagonal "cross" of the thinner red lines actually isn't a cross in a strict geometric sense. If you made all of the 4 thin red lines run diagonally all over the flag you'd get a real diagonal cross of double line thickness.
  19. Hi Garry, I created a new set of screenshots, where all relevant panels are visible. (They seem to be very large in the post - maybe that's due to the retina screen...) The document (100 mm x 50 mm) itself is entirely empty except for those elements/layers you see in the screenshots. So it's quite a mystery to me where that "ghost space" is coming from that's added top and right when the group or the layer is selected instead of the individual elements.
  20. Hi John, as a matter of fact I didn't create that flag myself.. If I were to I'd probably do it different, too. But as the "problem" I noticed seemed somewhat bizarre and I have no clue yet why that is so, I just took it as it was/is.
  21. I just ran into some strange behaviour in Designer (which transports into Publisher): I've got a simple graphic of a Union Jack flag consisting of 13 individual curves and one underlying rectangle as a background. These are the only elements on their layer. When I select all those parts individually (and simultaneously) the transformation panel shows a size of – say – 100 mm (width) and 50 mm (height). However, if I group these elements (or just select the layer they're on) the measurements shown in the transformation panel change to 101 mm (width) and 52 mm (height). Accordingly the selection marquee grows a bit on top and on one side to match the new measurements – while the elements making the flag remain exactly as before. Does anyone know how this might be reasonably explained?
  22. As it happens I actually thought that nearly 2 Gigabytes really IS quite a crazy amount of disk space being unexpectedly taken/used while working on a simple single page (almost) text only document in Publisher... Having worked with the Adobe apps for decades I'm probably not used to a behaviour like this, while I, of course, do know that disk space and RAM usage by most apps has gone up significantly over time. On my startup disk I have usually a bit less than 20 GB of free space and seeing that shrink comparatively fast and/or unexpectedly I get sort of nervous – can't help it, as it seems... You're right: I guess it would be of great help to understand what's going on here if I could actually locate where those 1,7 GB go and thus identify the underlying routine. Maybe there's nothing to worry about after all. But so far I'm still at a loss at how to find out. As you will know with Spotlight you can actually search for files e.g. "last modified today" AND "file size bigger than..." but that didn't turn up any suitable results. So I'm just keeping an eye on it...
  23. Thomaso, that's an interesting thought – thanks for pointing this out, I'll check on that one for sure. I would have thought, however, that any temp or swap files would be cleared once I quit the app that's responible. In my case free space actually remained the same after quitting Publisher and Designer. It took a reboot to have free space back (though I'm not completely sure if it sums up precisely). As of today I notice that since first waking the iMac (which has 12 GB of RAM BTW) from sleep this morning and working a bit (about 3 hours but not using any Affinity apps) free space on my startup disk has dropped by just 180 MB (including maybe 60 MB of Firefox cache). According to Activity Monitor no swap is being used. So today about (only) 120 MB are more or less unaccounted for which is not that much but might add up eventually if I don't reboot for some longer time. Anyway I'll check on another machine soon where all the Affinity apps are also installed. Thanks to all of you who so far contributed freely!
  • 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.