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.

text ruler still missing in 1.8.2.260


Recommended Posts

1 minute ago, LondonSquirrel said:

How are you testing this?

I am simply comparing how the 2 apps (AD & AP) perform using original vs. BBEdit modified versions. I do not care if the checksums are the same or not. All I care about is how the apps work with vs. without using the text ruler & the only difference is with the modified file it works exactly like it does in APub.

Besides, like you mentioned from the plist man page, binary property lists and XML property lists are generally interchangeable, so it does not seem to matter which format the file is using in real world use.

10 minutes ago, LondonSquirrel said:

But, for the third time, I would still use the tool designed for the job.

So you have said. But it does not mean that everybody needs to do that.

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

3 minutes ago, Old Bruce said:

If "editing" means changing one instance of false to true then the 2 byte difference is most likely of no consequence.

Oddly enough, for me the difference is 4 bytes, & the modified version is the smaller of the two.

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, R C-R said:

So then is it fair to assume that at least for this hack, it does not matter if the data in the property list is using XML or binary format?

For the later it doesn't matter under MacOS, namely if an apps property list file is provided as an textual XML file, or instead as an encoded binary one, since contents wise they should be same. The later, the binary one, is usually more compact and faster to load/read in by apps and further not as easy to alter as a plain text based XML file. So the binary one prevents to some degree more unwanted changes, manipulations or the like!

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

3 minutes ago, R C-R said:

I do not care if the checksums are the same or not.

I would consider the version edited by plutil to be the standard to measure against, as that is the tool designed for the job. It's easy to test. I don't have BBEdit. Perhaps you can check for us.

I saw @Old Bruce's comment just now, and it's not just the 2 byte difference (or any size) that is important. It is the file format itself. I don't doubt that BBEdit can handle text files, but binary files are different.

Link to comment
Share on other sites

22 minutes ago, LondonSquirrel said:

BBEdit can handle text files, but binary files are different.

Exactly. 

If I open a file and see the text gibberish as in screen shot on page one (?) then I know it is a binary file.

Mac Pro (Late 2013) Mac OS 11.7.1 
Affinity Designer 2.0.0 | Affinity Photo 2.0.0 | Affinity Publisher 2.0.0 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

19 minutes ago, LondonSquirrel said:

I would consider the version edited by plutil to be the standard to measure against...

I do not know how to make this any clearer: the only standard I care about is how the apps perform with the modified file vs. the original one. Since there is no difference at all, other than with the modified version the text ruler behaves exactly like it does in APUb, I do not see any point in testing with plutil or anything else.

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 minute ago, Old Bruce said:

Exactly. 

If I open a file and see the text gibberish as in screen shot on page one (?) then I know it is a binary file.

Haven't we already established from what @v_kyr here on page 2 that my BBEdit altered file is a binary one?

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

General NOTE:  There are several infos & docs on Apple's website and MacOS about their property list format and how to use it.

 

Related to BBedit, they (Bare Bones) know how to handle Apple property list files and so the format. They do use plist files a lot themselves for their editor modules and enhancements too, like for example for their syntax highlighters etc. (see: Codeless Language Modules, BBEditLanguageMods, etc.)

 

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

1 minute ago, v_kyr said:

Related to BBedit, they (Bare Bones) know how to handle Apple property list files and so the format. They do use plist files a lot themselves for their editor modules and enhancements too, like for example for their syntax highlighters etc.

Thanks for the confirmation about BBEdit's ability to handle plist files. I only use a tiny fraction of its free mode features but (so far) it has not caused any problems with anything I have used it for. 

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 hour ago, LondonSquirrel said:

I would consider the version edited by plutil to be the standard to measure against, as that is the tool designed for the job.

That's right, since this tool is sort of Apple's reference implementation for their property list format handling, beside Xcode which may reuses the one or other code part from the plutil, or at least from Apple's related API routines for their plist format.

Most MacOS related third party tools, which deal with the creation/reading/writing/editing etc. of plists under MacOS, do either way (re)use Apple MacOS API functions, or implemented own routines for handling Apple's plist format.

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

7 minutes ago, v_kyr said:

Most MacOS related third party tools, which deal with the creation/reading/writing/editing etc. of plists under MacOS, do either way (re)use Apple MacOS API functions, or implemented own routines for handling Apple's plist format.

So basically, they may or may not use the same API calls that plutil uses? Either way, when all is said & done does it matter as long as they deal with them properly?

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

27 minutes ago, R C-R said:

So basically, they may or may not use the same API calls that plutil uses?

It depends, for pure MacOS only apps & tools sure, why should they reinvent the wheel and not reuse Apple's APIs. - Other third party tools, those who have to support multiple platforms, may instead reuse for their MacOS support calls to "plutil" instead then. - See for example ...

27 minutes ago, R C-R said:

Either way, when all is said & done does it matter as long as they deal with them properly?

If any tool does what it should and finally generates what one needs, namely valid & correct working plist-files, then it doesn't matter at all what/which tool you use. You then just take what is the most comfortable or practicle for you.

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

It seems I've forgotten above to mention and point to an "plutil"-independent plugin-solution for creating/modifing/altering plist-files. 

Another very popular, powerfull and fast operating multi-platform available editor is "Sublime Text". There is a nice add-on BinaryPlist package available for Sublime, which works without the need of "plutil", since it's Python based (Sublime comes with a build-in Python for extending the editor) and thus has cross platform support for plists. - See:

sublime-plist.png.858ac3b1568c2cdb120b133ddee1986c.png

 

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

Ok so far we discussed more what MacOS binary PLIST based Affinity app related prefs settings are, how they look like, where those are stored and how we can change values for certain keys in those etc.

Now it's time to make things slightly easier here for MacOS users, in order to list and change such app related prefs settings then. Thus we will now use instead the MacOS defaults system (see in a terminal window also: > man defaults) to alter the specific "ShowFrameTextRuler = YES | NO" plist key/value pair. - I will in the following only briefly describe the steps to do here, the rest can be seen by reading the defaults man pages or some internet articles about the MacOS defaults system.

  1. To read out all the Affinity Designer prefs settings (the contents & settings of it's binary plist file) we can inside a terminal call ...
    Quote

    > defaults read -app "Affinity Designer"

    ... this will list ALL the ADe prefs settings inside the terminal window.

  2. Since we are only interested to see the actual "ShowFrameTextRuler" key/value pair assigned setting, we call defaults instead this way ...
     

    Quote

    > defaults read -app "Affinity Designer" ShowFrameTextRuler
    0

    ... the returned 0 indicates that the value (a boolean for ShowFrameTextRuler) is 0 = False|No, so this option isn't enabled yet.

  3. Now we will change the ShowFrameTextRuler option to True/Yes = 1, in order to enable it for ADe ...
     

    Quote

    > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool TRUE
          ... or altenatively ...
    > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool YES
        ... or as another altenative ...
    > defaults write -app "Affinity Designer" ShowFrameTextRuler '<true/>'

     

  4. And in order to set it back again to ShowFrameTextRuler option to False/No = 0, disabling it again then ...

    Quote

    > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool FALSE
          ... or altenatively ...
    > defaults write -app "Affinity Designer" ShowFrameTextRuler -bool NO
        ... or as another altenative ...
    > defaults write -app "Affinity Designer" ShowFrameTextRuler '<false/>'

 

This way the whole enabling/disabling of that ShowFrameTextRuler option value can be eased. - Of course this way it can also be used in shell scripts or applescripts, in order to automate and toggeling the switching here then.

ONE final NOTE: the corresponding Affinity app has of course to be closed (not running), when altering the settings via the Apple default system here!

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

As this is being discussed in two topics, I thought it might be worthwhile to point to a posting in the other one by @Patrick Connor, as it's equally relevant here :)

 

-- Walt

Desktop:  Windows 11 Home, version 21H2 (22000.613) 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 
Laptop:  Windows 10 Home, version 21H2 (19044.1706) 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
        Affinity Photo 1.10.5 (.1342) and 2.0.0 / Affinity Designer 1.10.5 (.1342)  and 2.0.0 / Affinity Publisher 1.10.5 (.1342)  and 2.0.0
iPad Pro M1, 12.9", iPadOS 16.1, Apple Pencil 2, Magic Keyboard

      Affinity Photo 1.10.5 (.280) and 2.0.2 / Affinity Designer 1.10.5 (.21) and 2.0.2 / Affinity Publisher 2.0.2

Link to comment
Share on other sites

Yes, usage is on an users own risk here and nothing which is supported by Serif at all then. - People should be aware of that, especially unexperienced Mac users and the like!

☛ Affinity Designer 1.10.5 ◆ Affinity Photo 1.10.5 ◆ OSX El Capitan

Link to comment
Share on other sites

3 hours ago, v_kyr said:

Of course this way it can also be used in shell scripts or applescripts, in order to automate and toggeling the switching here then.

ONE final NOTE: the corresponding Affinity app has of course to be closed (not running), when altering the settings via the Apple default system here!

I am not going to do this myself since should I want to enable this 'try-at-your-own-risk' hack as I have mentioned earlier I will just do it using BBEdit, but for those interested in the script method it should be relatively easy to create an AppleScript app that first reports the current setting for showing or hiding the Frame Text ruler, if set to the app default warns that changing it is entirely at the user's risk & invalidates Serif's support, & then if the user elects to go ahead & change it to show the ruler then makes sure the Affinity app is not running before continuing & warns that it should be quit before continuing.

This could also have an option to apply to both AD & AP or to just one or the other.

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • 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.