Jump to content

Lorox

Members
  • Content Count

    102
  • Joined

  • Last visited

About Lorox

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. For me I wouldn't actually consider it a „KO criterium“ for not using Designer on the average design job but using the shapebuilder in AI is so much more convenient than the Pathfinder (or Geometry Tools in AD) that I'd feel much more at home with the program if there was one in AD. Same goes for some decent envelope distortion tool (and – finally – support for SVG fonts)... Of course, you can always tell yourself: Well, it‘s not even version 2 yet, but then these are features that aren't exactly fresh on the map, as vector graphics in general go...
  2. I totally agree. The way duplication of layers and groups is handled as of today is definitely not ergonomic and there are enough examples of how to do it better (e.g. Photoshop...). It's just so annoying when you finally want to leave Adobe for good and then you feel slowed down in your workflow by such unnecessarily complicated steps. I actually feel that the Affinity apps generally too often make you resort to a menu or a button when some alt/click or -drag or just hitting the "Enter"-key (instead of going to an ”Apply"-button at the other end of the screen) would intuitively feel like the right way to do the job.
  3. Absolutely so! This is just so intuitively right that I cannot see any sound reason why this hasn't been implemented right away. The people at Adobe are having this right for so many years now and it shouldn't be a shame learning from them every now and then...
  4. Thank you very much, but unfortunately that's close to what I was afraid of: applying more or less advanced math to calculate proper ratios of dash length (or stroke width) and gap for any given size of object isn't really cool... I'd think that's exactly what the computer (and well thought programming of applications) is for... The clever guys at Serif should have a look at this – IMHO – obvious problem. Let's hope for the best (and the next update)...
  5. I'm having difficulties getting my dots of a dotted stroke correctly distributed/aligned, on rectangles as well as on a circle (please see screenshot). Obviously the dots don't care a thing about sitting correctly on the corners of the rectangles as you'd most certainly like them to. How on earth can this be achieved for any given shape? With the circle you see that the first (or may the last? or the first and the last?) two circles (marked red) are noticeably closer to each other than the other circles of the stroke – once you've noticed it, you just can't unsee it... There really should be an algorithm or whatever that distributes the dots (as well as dashes) evenly between any two nodes – I'd really think this is what we want when we use a dotted or dashed stroke even if this means that the distances between the dots/dashes are slightly adjusted to fit any segment between two nodes. Or is there already a solution which I haven't discovered so far? O
  6. Hi Walt, I think I know what you mean, but but when – after I click "Revert Defaults" – I use a tool like the shapes tool and the shapes now have default appearance to me it's like I actually reset the tool as such because future "products" of the tool will have the default apperarance. But you possibly could argue about this view. More important: with my Publisher v. 1.8.3 it "Reverts Defaults" for ALL kinds of "future" objects even if only a single distinct object is selected when clicking the button. So for example, when a somewhat formatted circle is selected while clicking the button, all future text frames will also be reverted to the defaults, not only that circle. Naturally, any object already given in the document remains unaffected if it's not selected while clicking "Revert Defaults". This seems to contradict your statement, doesn't it? Or do I get something wrong?
  7. Oh man, this is brilliant – thanks a lot! I didn't even notice this buttons until now... And it's even got a companion button to "Synchronize defaults from Selection". The only downside I see so far, however, is that EVERY tool seems to get reverted to default, not just the type you're currently working with (say text frames) – shapes, typopgraphy, everything. I could imagine, that being able to do this separately for the various tools (e.g. via a button on their respective palettes) would be an interesting improvement.
  8. Maybe this could also be applied to other tools but I came across the topic when working with text frames: Currently, when you change any attribute of a text frame (like the number of columns, background or stroke colour or whatever), these new properties become the default for any new text frames created subsequently (until you make new changes to these). This can can be quite unnerving, especially when you've just set some special attributes for the "odd text frame", while you would really like to use another more standard type for most anything else. As of now it seems you have to manually reset all the special attributes to "normal" before you can get on with frames having your desired standard appearance. I think it would be really helpful to be able to choose (e.g. in Publisher's preferences) between this current behaviour and a behaviour where you once set a standard formatting (e.g. while no document is open) and this standard/default is then used for any new element you create later in any actual document (meaning any changes made to – say – a text frame in a live document remain with that very text frame only and do not automatically affect any other frame created afterwards). Or – maybe even better – keep the current behaviour but combine it with the option of setting an applicationwide standard beforehand which you can revert to any time you wish by just clicking on a button in the – with this example – Text Frame palette.
  9. Hi thomaso, I'm using Acrobat Pro 9.5.5: v183 black text & doc col space_embYES-convNO.pdf > all blacks are "rich" RGB black (and stay this way, regardless of what I set as the simulation profile in Acrobat Pro) – when I change the profile I see subtle changes in colours of the pics (as you'd expect) – I don't have the PSO Coated v3 profile, though (as I don't ever use it) v183 black text & doc col space_embNO-convYES.pdf > blacks behave as they should (100 K text stays that way, regardless of what I set as the simulation profile) – pics' colours change a bit (as expected) v183 black text & doc col space_embNO-convNO.pdf > blacks behave as they should (100 K text stays that way, regardless of what I set as the simulation profile) – pics' colours change a bit (as expected) This seems to correspond to your findings, doesn't it? As soon as I have time for it, I'll double check the PDFs I've exported myself to see if I can replicate this. But – be it as it may – it's certainly more than a bit unsettling that for the time being it seems so hard for Affinity Publisher to offer the easy and (most of the time) flawless PDF output which InDesign has been offering for years by now. With Publisher it still feels to me like you actually have to fight for your PDFs to come out right and that's definitely not good for an app used in a real life print production workflow... With one of my last jobs there still were RGB-elements in my PDF although the file's colour space was CMYK (ISO coated v2 profile) and the profile set for PDF export was CMYK. It took quite a bit of trial and error before the PDFs were finally OK... What I also miss dearly is the ability to actually convert RGB colours to CMYK within Publisher or (at least) to just globally replace an offending RGB colour with a specially created new CMYK swatch. Sometimes when you're using external elements (e.g. logos supplied by clients) these are not necessarily in CMYK colour mode and their RGB colours sort of "spam" your colour palette. Actually the whole colour swatches/palette thing is not actually convincing in the Affinity apps, I'd say... You cannot even – like in the Adobe apps – "add used" colours (or "colours in use"), can you? Meaning colours you mixed and just assigned to an object without creating a swatch – or colours from objects you pasted into your document. You can do this in InDesign easily and it's really annoying to me that you cannot in Publisher (unless I missed something here).
  10. Absolutely so – it took me quite a long time to finally grasp what "numbers" InDesign was referring to... To be perfectly clear "Keep Color Values of non-Image Objects" would be even better. I seem to differ from you here: I actually think that any colour translation should be default be applied ONLY to images as "normal" colours which you'd generally apply manually to any object (vector – or possibly – black & white or greyscale images) wouldn't hardly be the plus 300% coverage kind and should be left as set (see my example of a logo with clearly defined CMYK values). Maybe there could be an option(!) to convert these coulors as well, if one decidedly wants to.
  11. 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.
  12. 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.
  13. Yes, that is correct – I'm using the regular Magic Mouse that came with the 2019 iMac. The context menu from the right mousedown looks (maybe is) just like the one I get from Control-click and everything except the color options at the very bottom works as it should. It's a bit strange... As I've just verified: It's exactly the same in Designer – layer colours via right mouse click context menu don't work (but everything else) but colours can be assigned when going by Control key with regular mouse click. I don't really see where such a behaviour could possibly be set. Apart from that: Wouldn't it be convenient if double clicking on a layer would offer a dialogue with a few (very) basic settings for the layer (similar to Photoshop's behaviour) like quickly assigning a color or renaming the layer?
  14. I just found that assigning a colour to a layer in the ”Layers“ palette apparently can't be done via the context menu (right mouse click), although the little round colour swatches/dots show up at the bottom of the context menu. You cannot select any of them, though. When you hover above above them there's no feedback that your mouse pointer has even been detected. However: Normal (left) mouse click with Control key works, you also get immediate feedback to your action (by slightly enlarging the colour dot you're hovering over) and the chosen colour is actually assigned to the selected layer once you let go of the mouse button. In case this might be connected rather to the OS and not so much to AP: I'm on macOS Mojave 10.4.6
  15. 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...
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. 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.