question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[designspace] Additional info for instances

See original GitHub issue

Hi,

I wonder if this idea has come up before, or if there is a way to do it that I don’t know of. If there is, please let me know!

I am wondering if we could extend the concept of localized names for instances sub elements of the <instance> tag to include more kinds of font info.

Say I have a designspace that I am using to generate static instances from. It has an axis other that Weight, Width, and Slope, so I want to make sure I set the WWS names for each of these instances. And more than that, I want to edit the Panose information, or make sure the trademark info has the individual style name in it. None of that stuff interpolates, so the generated instances would get that information from the source at the origin, which may be wrong in this case.

I can adjust these things after the fonts are generated, but it would be cleaner to have the option to declare UFO font info in the instance, maybe even as children of the <info> element to organize them, like so:

...
<instances>
    <instance familyname="My Font" stylename="Text Light" filename="instances/MyFont-TextLight.ufo" postscriptfontname="MyFont-TextLight" stylemapfamilyname="My Font Text Light" stylemapstylename="regular">
        <location>
            <dimension name="optical" xvalue="6"/>
            <dimension name="weight" xvalue="300"/>
        </location>
        <kerning/>
        <info>
            <openTypeNameWWSFamilyName>My Font Text</openTypeNameWWSFamilyName>
            <openTypeNameWWSFamilyName xml:lang="de">Meine Schrift Text</openTypeNameWWSFamilyName>
            <openTypeNameWWSFamilyName xml:lang="fr">Mon Police Texte</openTypeNameWWSFamilyName>
            <openTypeNameWWSSubfamilyName>Light</openTypeNameWWSSubfamilyName>
            <openTypeNameWWSSubfamilyName xml:lang="de">Leicht</openTypeNameWWSSubfamilyName>
            <openTypeNameWWSSubfamilyName xml:lang="fr">Léger</openTypeNameWWSSubfamilyName>
            <openTypeOS2Panose>...</openTypeOS2Panose>
            <trademark>My Font Text Light is a registered trademark...</trademark>
            <trademark xml:lang="de">Meine Schrift Text Leicht ist eine registrierte Marke...</trademark>
            <trademark xml:lang="fr">Mon Police Texte Léger est une marque enregistrée...</trademark>
        </info>
    </instance>
</instances>
...

The idea would be that build tools would take the info in the instance’s <info> tag, and apply it after creating the UFO. Anything explicitly declared in the <info> tag would overwrite whatever info it inherits from the source at the origin.

I have no idea if this has been brought up before, I just thought I would make this issue. If this idea seems feasible, I can make a more formal proposal, and/or take a crack at a PR.

Thanks!

Edit: Just saw #2606, maybe this could work with the <variable-font> element as well.

Issue Analytics

  • State:open
  • Created a year ago
  • Reactions:1
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

2reactions
anthrotypecommented, Apr 29, 2022

instance elements already have a <lib> which is formated as xml plist, we could define a new public key that stores fontinfo.plist overrides

1reaction
belluzjcommented, Apr 29, 2022

I only proposed including them as xml elements because it conceptually fit with the other 5 or so localized name elements

I see; in that case I would say that the pros of the plist format (same as UFO fontinfo.plist) yield more benefits than the pro of following the concept of the rest of the format using proper XML names.

Pros of reusing fontinfo.plist verbatim:

  • spec is already written and documented online, key names and value types are all already ironed out
  • good, tested code already exists to parse and validate
  • lots of example XML to copy-paste from in all the UFOs you already have
Read more comments on GitHub >

github_iconTop Results From Across the Web

Design Space says "An error has occurred" - Cricut - Help
Sign out of Design Space, then sign back in. In some cases, Design Space session can time out and give this error instead...
Read more >
Everything You Need To Know About The New Design Space ...
Everything You Need To Know About The New Design Space Features. Watch later. Share. Copy link. Info. Shopping. Tap to unmute.
Read more >
How to Organize Your Library in Cricut Design Space - YouTube
... we have some great tips and tricks for organizing your files in Cricut Design Space. More info below BEFORE YOU SCROLL ANY...
Read more >
Complete Cricut Design Space Tutorial For Beginners – 2022
For instance, if you have a Maker machine, you'll have more options than when you have any of the Explore machines.
Read more >
How to Use Attach in Cricut Design Space - Sarah Maker
Keep reading to learn how to attach text, attach writing to shapes, attach score lines, and more. I'll also explain why the Attach...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found