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
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.
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.
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.
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.
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).
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
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.
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.
