More advanced typography options

I’m wondering if rather than changing how typography works, it would be better if this would just be a setting applied to specific text box that would take x-height for alignment instead of changing the text box height. (Similar maybe to how today Sketch recognizes text baseline when aligning)

Thinking about this, it would be interesting to be able to assign a type to a symbol for the most usual component types. For example, you could make a symbol to be a button type and then that would reveal some settings specific to buttons, for example how text is aligned, states, etc. But that’s a whole other topic I guess.

Also, I still think decoupling some text preferences from styles would be the biggest typography update to Sketch. One can dream :smiley:

I totally understand and agree. But my original isn’t where trim is useful, but the opposite. Is there ever a situation where people would actually prefer NOT to trim, except engineering handoff?

Not sure.
I guess Sketch is not to inclined towards adding tons of preferences, but it may be a good thing to select default behavior inside preferences, but it should honor how every text element was created.

1 Like

I think it is just about not being realistic to how typography works, it doesn’t feel natural to have line height of the font trimmed by default imo. Not that there is necessarily any practical or other reason, it is just a bit unrealistic to how typography works in general.

@wwwedran If there’s no practical reason, why is it unrealistic, then? Is it just the fact that people are used to doing it this way, and that’s it?

I guess it could be that we are used to it, but in general it would feel weird to me to have a default where height of the container is cut while line height is applied. Maybe Sketch has some ideas how to do that that I haven’t considered yet. It would be interesting if there are some new ideas in this area.

Just a note that the line height still affects the space between multiple lines. But with trim, and working on a single line, there’s no point to change the default auto line height (except for development considerations). Which to me personally is one of the motivations to trim the default — it’s one less thing to deal with for single lines of text.

1 Like

With multiple lines it should only trim first one and last one. This way it will not affect the line spacing but the “sorrounding” box.

The point is that Figma released this update almost a year ago, and here we are still talking about it, honestly we have badly needed this feature for years and i think it’s time to implement it.
It simply leaves the user the choice to apply it or not.

Please Sketch don’t let me switch to Figma!!!

2 Likes

Came to the forum today to log something about how many steps it takes to change and test out OpenType features and found this thread and comment! Would really appreciate a better/less click intensive way to turn these features on and off.

Could I have more control over bullets? Choosing the icon, allowing it to be a different color, using a bullet unicode character not in the predefined list (eg allowing access to the various unicode classes such as the box drawing symbols and arrows).

4 Likes

And also:
More bullet and number list and indentation control.
A nicer way to view and apply fonts that isn’t a drop list inside of a dropdown list.
Better font management embedded libraries etc

+1 for hanging punctuation. There are some hacks that can make this work, but considering Figma enables it with a single click, it leaves a lot to be desired :grimacing:

+1 for allowing multiple styles within a symbol’s text box without the need for detaching. This is a pretty huge limitation.

Hey Mike!

There’s some good news for this request. The next version will bring Markdown support in Symbol overrides!

You can test it in the latest beta version :smiley:

Note: use the beta for testing purposes only, and make sure you’re working with a copy and not your production files.

1 Like

That’s great news! Thanks for the info Jorge.

1 Like

I just noticed a somewhat related issue. When you have a textbox with two colors in a symbol and you want to override the text in the instance, the color behaves buggy.

The text as it is in the symbol:

The overridden text with color bug:

It looks like the color change is maybe connected with the first space character index(?), not necessarily with the specific character, in this case the asterisk. So, if I then try to simply change the “Item” text to black, it changes all the text. If I try to then change only the asterisk to red, all of the text is changed to red.

Is this fixed in the beta?