Auto-adjust height of layer based on line-height

#1

I'm struggling to set a custom line-height on my text and have the height of the text layer adjust as a result.

For example, I am setting the following in the CSS font spec: 22px/1.6 "SF UI Text". Notice the 1.6 line height.

It seems like the line-height specification is indeed interpreted correctly, pushing the text down or up inside the layer, but the boundaries of the latter are not. This results in me having to calculate the height manually and putting it in.

Is this something that it would make sense to support?

#2

As a side-note, the height of the layer only seems to change when I set my value in the "height" field, but doesn't work when I do the same in the "min" (height) field.

#3

This thread seems related to your problem

#4

@norton hit the issue on the head.

I agree with you, @gabrycir, that we should have line-height support and the layout engine should behave accordingly, but we haven't implemented it (or really any other type controls) yet.
There's a lot of open questions around type/layout: flowing text between boxes, what layout properties text boxes can have, if individual substrings of text within boxes can have their own layout (e.g., left/center/right), etc.

#5

I think that one of the most important questions is the positioning of the first baseline relative to the top frame edge. This setting should be explicit (unlike in CSS and many other implementations). This will give control to the designer.

You may check InDesign as a reference. It looks like, there is no better solution currently as it is the most sophisticated WYSIWYG layout application out there. (Need to check how TEX deals with it.)

#6

the positioning of the first baseline relative to the top frame edge

This is the thing I miss most about InDesign.

But if Subform were to do baselines properly… Would web people have to just design stuff and remember that text in adjacent columns won’t actually line up in the final product? Would it make sense to have an option to make baselines worse, but better represent the final (web) product?

#7

@kevin based on your question, allow me to go on a bit of a tangent:

Browsers have a very consistent (if possibly special) way of aligning baselines. It seems as if the text is always centred within the total line-height.

I design primarily for the web, and the font we use (Aktiv Grotesk from TypeKit) renders fine on the web, but is misaligned within the bounding box in a tool like Sketch. This makes my work unreliable.

I've gone through the maddening process of rendering a string of text at every font size we use in both HTML and in Sketch, then comparing the difference. Sketch's version is skewed towards the bottom and seems to grow linearly with the font size.

In order to save myself from madness, I created symbols in sketch for every font size, and now use those to lay out text in a way that the browser will match.

It should go without saying that this process is absolutely backwards, and I wish I didn't have to do it. This is one of the numerous issues that made me feel compelled to fund Subform in hopes of seeing solved.

If Subform had one of the following, it would set itself apart from the competition on this front:

  • Presets to emulate the line rendering of each platform (would require research into the respective platforms' way of rendering text)
  • A way to set a custom offset for the baseline, as mentioned by someone else here. Seeing as the offset is not constant, but grows linearly, this would also require a feature like "test styles" in order to allow me to figure out the offsets once and never again.

I would honestly also be curious to find out if browsers, iOS and Android actually have similar ways of rendering lines, as I have never noticed the aberrations that can be seen in design tools like Sketch. If they do, that'd be an even bigger incentive to emulate their model, I think.

#8

I feel this pain so deeply. The lack of professional type handling in UI/UX tooling was one of the major issues that I wrote up when we were conceiving of Subform. And we're not alone, a lot of the people we've talked to over the last year have some variation on your workflow here, @gabrycir.

That said—and I think you hint at this in the end of your post—this is a really gnarly problem with a lot of variables. Type rendering across platforms and browsers and versions is all over the place. Typography calls for precision, but our target media don't always support that.

There isn't one magic panacea that will solve it. But I do think we can take steps in the right direction. Thanks for sharing your ideas to that effect.

Create font hierarchy at start of project using classes
Text line not breaking and wrapping within parent container
#9

Thanks for your opinion @Ryan! I have great trust in the solution you'll come up with.