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

[makeotf] cannot find PS name w/ unrelated lib.plist entry #701

Closed
frankrolf opened this issue Dec 18, 2018 · 4 comments
Closed

[makeotf] cannot find PS name w/ unrelated lib.plist entry #701

frankrolf opened this issue Dec 18, 2018 · 4 comments

Comments

@frankrolf
Copy link
Member

frankrolf commented Dec 18, 2018

makeotf v2.6.0 won’t be able to find a UFO3’s PostScript name if the lib.plist file contains a reference to the ScaleFast extension, like this:

<?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>com.loicsander.scaleFast</key>
    <dict>
      <key>guides</key>
      <array/>
      <key>presets</key>
      <dict/>
    </dict>
  </dict>
</plist>

makeotf fails with this message:

$ makeotf -f PSnameSerifText-Bold.ufo/
makeotf [Warning] Could not find default features file at 'None'. Font will be built without any layout features.
makeotf [Error] Could not find FontName (a.k.a. PostScript name) in FontDict of file '/Users/fgriessh/Desktop/psname_test/PSnameSerifText-Bold.ufo'

If the key is removed from the lib, the UFO will build without issues.
Example UFO attached. Another issue found thanks to the example files submitted by @rbmntjs.

PSnameSerifText-Bold.ufo.zip

@rbmntjs
Copy link

rbmntjs commented Dec 18, 2018

Is this just caused by the self-closing XML? I think I’ve actually encountered this issue before, but I totally forgot about it.

@frankrolf
Copy link
Member Author

Perhaps? But even if it is, it should not result in the above.
Thanks for the pointer though, it’s something we can investigate.

@frankrolf
Copy link
Member Author

It’s the self-closing <dict/>.
If I change that into <dict></dict>, it works.
I guess this issue underlines the importance of replacing our home-grown XML parser, as already planned here: #475 (comment)

@miguelsousa
Copy link
Member

The bug is in the UFO-reading code of tx. Currently working on a fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants