Jump to content
You must now use your email address to sign in [click for more info] ×

Search the Community

Showing results for tags 'unclear function'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Affinity Support
    • News and Information
    • Frequently Asked Questions
    • Affinity Support & Questions
    • Feedback & Suggestions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • V2 Bugs found on macOS
    • V2 Bugs found on Windows
    • V2 Bugs found on iPad
    • Reports of Bugs in Affinity Version 1 applications
  • Beta Software Forums
    • 2.3 New Features and Improvements
    • Other New Bugs and Issues in the Betas
    • Beta Software Program Members Area
    • [ARCHIVE] Reports from earlier Affinity betas

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



Member Title

Found 2 results

  1. My inability to grasp concepts has been successfully demonstrated here before. I hope this will not be another reiteration of that. This time, I am failing to grasp Text Frame's Baseline Grid (BG), 'Relative to' setting. I have searched Help, alas no help was found. So, dear fellow humanoids, et al. help me please. (play file attached) Document BG is OFF. Text Frame's Ignore BG is OFF. Text frame's independent BG are ON. Text aligns to BG. Publisher help states: Start Position — specify the offset of the first grid line from the origin at Relative To. Relative To — specify what the baseline grid's starting position is in relation to. Alright, let's go to Text frame's BG panel and play with 'Relative to' setting: Top of Page Expectation: As stated, BG starting position is defined in relation to Top of Page... Top of Page becomes BG's fixed origin. I.e. Text frame's BG' first line would be anchored in relation to Top of Page and offset by 'start position' value. Moving text frame would 'appear' like a frame on an otherwise static baseline grid. This behavior would be very useful for maintaining baseline consistency overall in layouts with more than one BG system. Neat! Observed: Instead, it seems that BG is anchored to Text frame's top and it seems it behaves just like 'Top Inset' setting. 🤔 It seems that this setting is applied only when Text frame is created. Later it does not apply anymore. 🤨 Why? Top Margin Expectation: The same as above but page's Top Margin becomes BG's fixed origin.. I.e. Text frame's BG would be fixed in relation to Top margin. Increasing top margin by 1mm would make all relevant text frames' BG to move downwards 1mm. Observed: BG is again anchored to Text Frame's top. 🤔 But, I cannot find how this setting relates to anything pagey-top-margin-y, at all. Help. Top of Artboard Expectation: Not explored. I guess this applies to editing graphics from Designer? If so, IMHO, it should not be present in GUI if it does not apply to paged document. Observed: Seems to behave like 'Top of Frame' setting. Top Artboard Margin Expectation: Not explored. Again, I guess linked to editing graphics coming from Designer. Also, if so, IMHO, it should not be present in GUI if it does not apply to paged document. Observed: 🤨 Moving a text frame up/down with this setting produces a funky effect. (Multiply by -1 error?) Top of Frame Expectation: The first BG line is defined relative to Top of text frame. Observed: Behaves as expected. Top Inset Expectation: The first BG line is defined relative to Text frame's top inset. Observed: Behaves as expected. (Theme song: The Beatles: Help) Text frame baselines.afpub
  2. In Preferences/Keyboard shortcuts in all Affinity apps there is 'Ignore Modifier' checkbox. What does it actually do? Help documentation defines it: Ignore Modifier—Lets you create shortcuts using a single letter designation instead of using keyboard modifiers. A mystery. So, I tried to discern it's effect on one of the commands. In orange are marked results I find unexpected. With 'Ignore Modifier' ON 'P' is assigned as 'P'. (that is uppercase 'P'; why unexpected? Please see the reference below to @walt.farrell's experiment), 'shift+P' is assigned as '⇧P' (again, refer to Mr. Walt's experiment; furhermore, here, 'shift' is not considered a modifier?), '⌘+P' is assigned as 'P' (I guess ⌘ is ignored somehow, but to what purpose?), 'alt+P' is assigned as 'π' (I guess 'alt' is ignored, resulting in conventional π), 'ctrl+P' is assigned as empty (!) but with an option to remove it. (see image below, is this normal?). With 'Ignore Modifier' OFF 'P' is assigned as 'P'. (I understand this is something 'Ignore Modifier' should make possible but here it is, working fine with 'Ignore Modifier' OFF), 'shift+P' is assigned as '⇧P', '⌘+P' is assigned as '⌘P', 'alt+P' is assigned as '⌥P', 'ctrl+P' is assigned as '⌃P'. 'Fn' key is skipped here since I own Logitech keyboard, not Apple. Now, referring to Mr. @walt.farrell 's experiment where pressing key labelled 'P' with 'Ignore Modifier' ON assigns 'p' (lowercase P), while 'shift+P' assigns 'P' (uppercase P): In all things 'Affinity' I trust Mr. Walt first... So, is it possible that my shortcuts preferences file is borked? Or is there a finer idea underpinning 'Ignore Modifier' checkbox that my measly braincells fail to grasp? Am I alone in this?
  • Create New...

Important Information

Terms of Use | 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.