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

text ruler still missing in 1.8.2.260


Recommended Posts

5 minutes ago, thomaso said:

Many years ago I used the Plist Editor  https://www.fatcatsoftware.com/plisteditpro/

AFAIK that's still in active developed and one of the oldest such tools to handle plists. - Some other tools are also named here ...

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

49 minutes ago, R C-R said:

I can't say for sure if it resaves the plist file in binary format ...

You can easily find out when you reopen that by BBedit saved file then with some other plain texteditor/hexeditor (... you can use TextEdit or vim, which are already part of MacOS for inspection).

49 minutes ago, R C-R said:

FWIW, BBEdit has extensive AppleScript support. I have not tested it for this but it looks like it might offer a quick automated way to toggle the boolean, among other things.

I know, I've once read and looked over most editor reviews & comparisons for MacOS plain and developer related editors, also tried some interesting dev editors out. Though I didn't tried BBedit. - On MacOS for GUI editors I mostly use Sublime Text & TextMate and in terminals mostly Vim & Emacs. The good about the later (except TextMate) is, they support multiple platforms and thus you can use them equally under MacOS/Windows/Linux.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

10 minutes ago, v_kyr said:

Some other tools are also named here ...

I wonder why BBEdit isn't mentioned there. The full feature version is $50 US but the free version is still very capable, including such things as support for find & replace using GREP, presets, & tons of other text related features.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

5 minutes ago, v_kyr said:

You can easily find out when you reopen that by BBedit saved file then with some other plain texteditor/hexeditor (... you can use TextEdit or vim, which are already part of MacOS for inspection).

What should it look like in TextEdit? What I get is a combination of human readable text & text strings like "ÄÅÇÉÑÖÜáàâäãåçéèêëíìîïñóòôöõúùûü†."

It is the same in TextEdit for the original unmodified or for any other .plist file, so that tells me nothing obvious.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

52 minutes ago, R C-R said:

What should it look like in TextEdit? What I get is a combination of human readable text & text strings like "ÄÅÇÉÑÖÜáàâäãåçéèêëíìîïñóòôöõúùûü†."

If the by BBedit altered and saved plist-file looks contents wise in TextEdit like in the above shown screenshot from Old Bruce, then it's not a binary XML format. - Or the other way round, if you look with TextEdit inside one of your previously backuped up original Affinity binary plist-files, you should then recognize how that looks in contrast then.

textedit_plist.png.e2d8db8d9d067506517332d12cd72992.png

Here's how things look then in Sublime Text, which tells bottom right that it is a binary file.

subl_plist.thumb.png.1191481004cdd0658c6c945ff5be508f.png

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

8 minutes ago, thomaso said:

Maybe there are just too many around for a complete list? He mentions BBEdit and two more: https://eclecticlight.co/2015/08/18/qa-which-text-editor-for-os-x-configuration-files/

The info for BBEdit there is a bit out of date -- I am not so sure BBEdit is still considered an industry standard & of course Text Wrangler doesn't exist as an independent app anymore -- but in its free mode it still seems to be a very powerful & feature rich way to view & edit plist files. In particular, the Search menu's two Find Differences items provide a very good way to compare two versions.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

5 minutes ago, v_kyr said:

If the by BBedit altered and saved plist-file looks contents wise in TextEdit like in the above shown screenshot from Old Bruce, then it's not a binary XML format.

But isn't it possible (if unlikely) for ordinary plain text file to look almost exactly like in that screenshot by Old Bruce even though it is not actually in binary format, like in this fake binary.plist example?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

Why not use plutil that comes with macOS? It will also check that the file's syntax is still ok, i.e. after you modify it:

[xxx@yyy:00:33:45:~/tmp] (524) % plutil com.seriflabs.affinityphoto.plist 
com.seriflabs.affinityphoto.plist: OK

[xxx@yyy:00:34:19:~/tmp] (525) % plutil -p com.seriflabs.affinityphoto.plist | grep -i showframetextruler
  "ShowFrameTextRuler" => 0

[xxx@yyy:00:34:25:~/tmp] (526) % plutil -replace ShowFrameTextRuler -bool true com.seriflabs.affinityphoto.plist

[xxx@yyy:00:34:39:~/tmp] (527) % plutil -p com.seriflabs.affinityphoto.plist | grep -i showframetextruler
  "ShowFrameTextRuler" => 1

[xxx@yyy:00:34:46:~/tmp] (528) % plutil com.seriflabs.affinityphoto.plist 
com.seriflabs.affinityphoto.plist: OK

 

I did see @v_kyr's post above mentioning plutil. So I'm not sure why anyone would start using something else which is not designed to handle plist files. Sure, I know they can. But why bother when there is a tool for the purpose?

Edited by LondonSquirrel
Added note about v_kyr's post.
Link to comment
Share on other sites

16 minutes ago, LondonSquirrel said:

Why not use plutil that comes with macOS? It will also check that the file's syntax is still ok, i.e. after you modify it

But is not all that clear to every user that "OK" means it is still binary or will work as expected in Affinity. For example, try plutil with my fake binary.plist file that I just posted. plutil says it is OK but it isn't even a real plist file, just some text copied from the real binary file into a plain text file with the file extension changed from txt to plist.

Aside from that, some users are just uncomfortable using Terminal.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

4 minutes ago, R C-R said:

But is not all that clear to every user that "OK" means it is still binary or will work as expected in Affinity.

plutil checks the syntax, that is all. I'm not sure why editing a plist file in a text or hex editor is better than a tool meant for the job. 

7 minutes ago, R C-R said:

Aside from that, some users are just uncomfortable using Terminal.

Then perhaps they should not edit plist files at all.

Link to comment
Share on other sites

24 minutes ago, R C-R said:

But isn't it possible (if unlikely) for ordinary plain text file to look almost exactly like in that screenshot by Old Bruce even though it is not actually in binary format, like in this fake binary.plist example?

Not sure what you mean concrete here with "ordinary plain text file" and the reference to the none binary XML format Old Bruce showed (?). - What Old Bruce showed was the textual XML representation of an binary plist-file, so if you want to call it that way, a plain text XML file with some key & value and key & data pair fields.

You should make yourself clear how a well formated PropertyList XML file is structured and looks like. All in all it's element wise similar structured like HTML/SVG files. For example ...

xml-structure.png.99ccb2a9676c526a7c3dab70fec09d89.png

 

... it too always has element & attribute definitions which follow a defined document type definition (dtd).

The <data> part you showed in that fake file is just one element portion, which for PropertyLists forms only the value part (as hex data) of a key = value pair. That alone in that form is no valid XML properties file.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

56 minutes ago, LondonSquirrel said:

Why not use plutil that comes with macOS? It will also check that the file's syntax is still ok, i.e. after you modify it:

Yes, plutil is the way to deal with Apple MacOS based property list files from inside the console/terminal. Though it's lint/syntax checking probably only checks for correct pairing tags and not something more sophisticated here at all.

Aka things like ...

<plist version="1.0"> ... </plist>
<dict> ... >/dict>
<key>...</key>
<integer>...>/integer>
<data>...>/data>
<true/> | <false/>
...
etc.

However, since most mere mortal MacOS users seem to fear the more powerful console, or have forgotten how to do anything other than clicking around in GUIs, only few people will be aware of it.

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

3 hours ago, LondonSquirrel said:

I'm not sure why editing a plist file in a text or hex editor is better than a tool meant for the job. 

The point is simply that there are multiple tools that can edit plist files. Some are better suited to some people than others. That's why so many exist.

3 hours ago, v_kyr said:

Not sure what you mean concrete here with "ordinary plain text file"...

One that does not actually have any key/value pairs, just plain text laid out to mimic that kind of data structure.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

3 hours ago, v_kyr said:

The <data> part you showed in that fake file is just one element portion, which for PropertyLists forms only the value part (as hex data) of a key = value pair. That alone in that form is no valid XML properties file.

And yet plutil says it is OK. The file was just intended to show that plutil is not by itself a reliable way to determine if a plist file is a valid XML one or not.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

3 hours ago, R C-R said:

And yet plutil says it is OK. The file was just intended to show that plutil is not by itself a reliable way to determine if a plist file is a valid XML one or not.

You can check the plutil XML validation behavior against other common XML validation services, like for example ...

☛ Affinity Designer 1.10.8 ◆ Affinity Photo 1.10.8 ◆ Affinity Publisher 1.10.8 ◆ OSX El Capitan
☛ Affinity V2.3 apps ◆ MacOS Sonoma 14.2 ◆ iPad OS 17.2

Link to comment
Share on other sites

7 hours ago, v_kyr said:

You can check the plutil XML validation behavior against other common XML validation services, like for example ...

I did that with the first URL ... & the result with my fake file is "No errors were found." The second one was more informative, as expected saying it has No DOCTYPE declaration or schema reference. I did not try the others.

But I am still left wondering if there is a simple, straightforward way to determine if a plist (or whatever) file is actually encoded as binary or as text data.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

12 hours ago, R C-R said:

The file was just intended to show that plutil is not by itself a reliable way to determine if a plist file is a valid XML one or not.

From the plist man page: The binary property list format is opaque and does not use XML. However, binary property lists and XML property lists are generally interchangeable...

Link to comment
Share on other sites

2 minutes ago, LondonSquirrel said:

The binary property list format is opaque and does not use XML. However, binary property lists and XML property lists are generally interchangeable...

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?

At least for me, all that really matters is if I change false to true using BBEdit & save the file then the hack works with no apparent issues, & if I want I can change it back to false, save it again & still see no apparent issues. I prefer using BBEdit for this because I am familiar with it & its find & compare features are useful for things like this.

I realize I could use plutil's convert fmt option to convert the file to (for example) binary1 but I do not see any need to do that. Do you think there is any reason to do that?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

18 minutes ago, LondonSquirrel said:

I personally would use plutil to do this. No doubt the format of the plist files is internally consistent in some way or has a set format, and BBEdit (however good it is) may not be 'aware' of that.

But is there any good reason to do that, considering that it works fine now however BBEdit saves it?

To be clear about this, I cannot see any difference at all in any respect between using the original unaltered plist file & the one modified in BBEdit.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

6 minutes ago, R C-R said:

But is there any good reason to do that, considering that it works fine now however BBEdit saves it?

Well I mentioned that plutil is designed to do the job, and AFAIK BBEdit is not. I have no problem personally editing files in all sorts of apps, but for binary files I would want to know for sure that the editor I am using is aware of the format and writes it correctly. For all I know, BBEdit may be slurping in the file and considering it to be in XML format. The fact that BBEdit opens the file is not a guarantee that it will write it correctly. I'm not singling out BBEdit here - the one true editor, vi(m), can also open these files. Though I note that somebody has made a plist plugin for vim. 

 

Link to comment
Share on other sites

3 minutes ago, LondonSquirrel said:

For all I know, BBEdit may be slurping in the file and considering it to be in XML format.

It does treat plist files as using the XML format in the edit window but like I said, there is zero difference in the behavior of what it writes to the file & the original version untouched by BBEdit or anything else. Isn't that indication enough that the file is being written correctly?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

1 minute ago, R C-R said:

there is zero difference

How are you testing this? You could test this by looking at checksums. Take a two copies of the plist file and put them somewhere. Edit one file using plutil, and the other using BBEdit. Now get the md5 checksums of each file. md5 is sufficient here before anyone mentions collisions. Are the md5 checksums the same? If they are, then it would appear that BBEdit does write the files properly. But, for the third time, I would still use the tool designed for the job.

Link to comment
Share on other sites

If "editing" means changing one instance of false to true then the 2 byte difference is most likely of no consequence. I would not use BBEdit to change more than just the one instance back and forth. 

There is a two byte difference between the original and the Saved As... with no changes made.

It is like digging toast out of a toaster with a fork, not a good idea to do that a lot.

Mac Pro (Late 2013) Mac OS 12.7.4 
Affinity Designer 2.4.0 | Affinity Photo 2.4.0 | Affinity Publisher 2.4.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

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