Jump to content

hifred

Members
  • Content count

    143
  • Joined

  • Last visited

About hifred

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Germany

Recent Profile Visitors

446 profile views
  1. Thanks. If one modified the dimension boxes in unconstrained mode, so that they don't just display the dimensions of the rectangle drawn in the viewpoint but also allowed Input one btw. could get rid of the absolute dimensions mode. Coming from Photoshop I would not look for that separate mode - unconstrained means unconstrained, regardless of input method chosen. Now I'm waiting what R C-R has to say :o).
  2. Sorry - what I meant indeed would require a second set of input boxes. One defines the ratio, the second would allow dialing in one edge-lenght - without having to previously know the second value. I had wondered if that was already possible.
  3. Thank you! Is it also somehow possible to type dimensions (just one if the one has a preset ratio active)? Example: Active preset = 4:3, User types in 800 in the first box, Affinity crops to 800x600.
  4. Something else: Is there a good reason that one can not change the canvas size with numerial (pixel) input from within the Crop Tool? I do this all of the time in Photoshop. In Affinity there's pixel fields (when Crop is set to unconstrained) but it unfortunately read-only (marked in screenshot) Why isn't there a way to enter pixel dimensions in every mode where this made sense (should be all modes, except those presets which are already supposed to set the crop to some exact pixel dimensions).
  5. Nah, too far away :o) Seems that Flow should be rather simple to add, as the whole number based limbo is already in place for opacity. Now another event had to get supported, using the exact same system, just with an additional modifier-key pressed and every Photoshop convert was a lot happier.
  6. What about Brush Flow? An equally important and often needed setting. In Photoshop one sets the opacity using the scheme from your quote, and does the same thing with Shift held down for Flow. Seems not to work inside Affinity so far. What you describe is setting the Size and Falloff in Photoshop. Works beautifully. Huh?
  7. I don't deny any of this. Hence I prefer the best solution to the problem: Serving a bitmap version of the formatted text which retains the appearance and a text version, which retains the text, so it doesn't need to get rewritten from scratch I don't want to continue this fruitless discussion, have a nice day.
  8. 1) Sounds mighty impressive, but doesn't add anything new to the discussion. We have all understood that text appearance can't always get retained when importing a proprietary file format. 2) Seems like an odd corner case, merely made to up keep up this discussion - talking about drama. How hard would it to turn off one or a few text layers here and then? What you resist to understand is that the user always loses something important with the current implementation. Either text appearance or editable text. You will not convince me that needlessly lossy makes more sense for a file format which will predominantly get used in file exchange contexts with Adobe users :o) Let's move on.
  9. I suggest you to re-read my last post. I suggested what should happen if Affinity isn't able to display the text in the style and font it was saved in the psd file. If you prefer having an unnecessary complication in place, I'm afraid I can't hinder you :o)
  10. That's at least something.
  11. Well, I can't discover the drama here. My point is that when I choose .psd I want maximum file integrity. Having the default set to bitmap sure is the source of unnecessary questions + frustration, such as expressed by the thread opener. While you guys seem to share the same opinion I'm still convinced that Affinity could handle this whole thing smarter. Importer checks whether font is available – if not, it should create a bitmap version of the text and a text layer with a replacement font. All cases covered.
  12. I can't follow this line of argumentation. A preference is superflous when one could serve all scenarios without that setting. That is the case. If retaining the appearance by all means is the goal Serif could always insert a rasterized text version of that composition in the imported file (as other programs do*). No need for a preference box then. What's a far more realistic setting is that those who choose the psd format to import want to have an editable file, else they could opt for any static file format. In a file which has text rasterized to the background subject, all retained adjustment-layers are pretty much rendered usess, as any changes on them will affect the complete composition – including the text. *psd w. max compatibily checked in Photoshop
  13. This preference item is superfluous (but has the wrong default setting checked). It's save to say that 99,9% of users want to always keep their text as text at import time. If the user really has the need to rasterize text, it can be done with one click at any time later (but one will very likely again keep a backup layer of editable text inside the file). So one still had all options left, when text always came in as text. This preference item does not serve a good purpose. It does not save time or make things easier. It / its wrongly chosen default value is only a source of frustration and support requests like this one. Everyone would profit if it got removed.
  14. You might be correct Walt – but while I'm aware that I'd bark at the wrong tree – I'd hate Windows for doing that as well. If one uses a suite of programs and dozens of file formats (I now see it also for every RAW format i have on disk) one usually will have made up his mind what should happen with files by default. And there's still "Open with" for all exceptions. It's a lot of superflous Popups one needs to deal with... Right now, while I own Photo and Designer don't actually work with Affinity – I want zero system integration.
×