Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plist serialization: option to indent first dict element, expand empty elements #179

Open
madig opened this issue Sep 15, 2021 · 1 comment

Comments

@madig
Copy link
Collaborator

madig commented Sep 15, 2021

A rather annoying feature of ufonormalizer is that it

  1. indents the first dict element in a plist, compared to what Apple writes out by default, though it is more consistent when viewed from an XML lens, and
  2. expands empty elements.

Apple serializers, plist and Python's plistlib will write by default:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>lib</key>
	<dict>
		<key>org.unifiedfontobject.normalizer.imageReferences</key>
		<dict/>
	</dict>
</dict>
</plist>

but ufonormalizer will write:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>lib</key>
		<dict>
			<key>org.unifiedfontobject.normalizer.imageReferences</key>
			<dict>
			</dict>
		</dict>
	</dict>
</plist>

Note the <dict></dict> which ufonormalizer will write instead of just <dict/>.

Both are things that should maybe be writer options in plist, but I'm not sure if the author is open to this? We are, after all, doing semantically unnecessary things...

@madig madig changed the title Plist serialization: option to indent first dict element Plist serialization: option to indent first dict element, expand empty elements Sep 15, 2021
@chrissimpkins
Copy link
Collaborator

Both are things that should maybe be writer options in plist, but I'm not sure if the author is open to this? We are, after all, doing semantically unnecessary things...

Better there than creating workarounds here IMO. Worth a try.

@madig madig mentioned this issue Mar 9, 2022
22 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants