Jump to content


  • Content count

  • Joined

  • Last visited

About A_B_C

  • Rank
    Dedicated User

Profile Information

  • Gender
  • Location
    : Germany

Recent Profile Visitors

2,460 profile views
  1. The font in your screenshot is definitely not Optima, but rather Candara, I would guess …
  2. Don’t get me wrong … I perfectly understand your intention, and I would wholeheartedly subscribe to the principles of usability and avoidance of clutter you are advocating so vigorously. I just don’t see why a simple menu option, as it was available in Pagemaker in the 1980s – and is, to repeat myself, available in every other professional graphic design app I am aware of –, should “clutter” the interface of the Affinity apps. I really don’t care for a button on the main toolbar. The developers could hide the guide lock option in a submenu, should it prove too difficult to create a layer-based guide system at the moment, but nonetheless, it would be a huge relief and a great improvement for my workflow, if I could just lock my guides. I think you have to acknowledge that the option of locking guides is present in these other apps for a purpose, and it is present there for over thirty years now. It is needed, it is simple and effective. I don’t see how the current approach could provide the same qualities.
  3. No offence, R C-R, but I give up at this point. I put my trust in the developers that they will understand that having a guide lock option is a legitimate request.
  4. C’mon guys, this discussion is getting a bit strange. There is no single professional graphic design, font design, or DTP application I am aware of that would not allow to lock guides. Some of us might still remember even these days: Source: Desktop Publishing with Pagemaker, 1987 So as long as I can grab a guide on the canvas and move it, regardless of the currently implemented behaviour, the system will be prone to accidental changes of any sort. Just have a look at my video below. It’s not a really long way to go from rotating a shape to moving a guide. Personally, I am in favour of a guide system that would allow to attach guides to a layer, such that we can have different sets of guide systems in the same document that can be toggled on and off. But at the very least, I fear I cannot do without a button or a menu option that would simply allow to lock my guides. I can’t see why adding such a button or menu option would be an annoyance for people who don’t want to use it. I bet there are several other options that are never used by some people. Alex Guides.mov
  5. Is that really true, Miguel? Is this the last word? And will it be like that forever? Well, then I have to say the developers should spend a second thought on this decision. It’s not that I wouldn’t be careful with my own documents … that’s for sure …, but just imagine there might be other people I may want to share my Affinity documents with. Can I really trust that they won’t accidentally move my guides, even if I just ask them to add a missing bit of copy text? Sharing documents without the ability of locking guides will be a nightmare … Please bring this button back! It’s so important! Alex
  6. Hmm … seems I cannot reproduce this … neither from MAS to Beta nor from Beta to Beta …
  7. Has there ever been a pencil tool in Affinity Publisher? I don’t believe so …
  8. But … and please don’t forget this when creating a book … all text flow between text frames will be cut when re-opening a file from PDF.
  9. Thank you for adding hyperlinks. As for suggestions, I think it would be important, as other users already said, to offer the option of directly assigning a name or a custom label to a link on creation, not only afterwards in the Hyperlink Panel. Please spare us this additional step. I would wholeheartedly support what @fde101 said and demonstrated here for Quark. As for bugs, my version of Publisher currently becomes totally unresponsive, as soon as I double-click a hyperlink name in the Hyperlink Panel to add a name. See my video. Cheers, Alex Unresponsive.mov
  10. That sounds like a great solution!
  11. So, Manu, you don’t need the option of replacing an existing crop area with a new one from scratch? You basically only want to adjust the crop area, when returning to an already made crop? That’s fine with me. I believe don’t need the option of creating an entirely new crop area either. But I was under the impression that the developers are reluctant to give up that option. Just to clarify, by “creating a new crop area” I mean what happens in my video below. You can see that the existing crop area is not moved when I click inside, but a new crop area which replaces the existing one is created. New.mov
  12. Hi Chris, as for suggestions, I would like to make these comments: Regarding the Darken mode, I would suggest that there should be a slider in the preferences that allows the user to adjust the opacity of the area outside the crop area to arbitrary degrees. I still find the current area outside the crop area too bright. Regarding the question of Moving the crop area vs. Creating a new crop area, I believe these two options should be available to the user, whether they choose to reveal the canvas or not. Though I believe it natural that a user who reselects the Crop Tool intends to adjust the given crop (by moving the area or the like) rather than creating a new crop from scratch, I would nonetheless say that the two options should be decoupled from the Reveal option. Unfortunately, I fear there is no modifier key left for toggling between these options. And the context toolbar is already overburdened. On a 13" notebook screen, not even all of the present options will be available other than by an additional fly-out menu. So I guess you won’t be overly enthusiastic about adding a radio button selector to the context toolbar similar to the one available for the pixel selection tools. So if none of these solutions is acceptable (modifier key, radio button), you could still differentiate between Moving the crop frame vs. Creating a new crop frame on the basis of the mouse pointer location. What if dragging the frame of the crop area (but not on one of the handles) would allow the user to reposition the crop area, while dragging inside the crop area would create a new crop area from scratch? Dragging outside the crop area could still be used for rotating. If you allowed a generous pixel tolerance for catching the frame this solution could be as convenient as the current one. Hmm.