Title text top is cut off...

How can I avoid that the top of the Text in a box is being cut off? This is the title text:

Have you tried dragging down the bottom of the title frame a little bit? If I have both a title and subtitle in the same frame, I often find myself doing this.

It looks like the frame the title sits in is too narrow. What happens if you adjust the frame in your master page accordingly?
(Well, you can always try directly in your page, too)

It’s not a problem if the frames overlap.

Yes, I even made it very large to see what happens, but the top stays cut off. I have set the baseline shift of the first line to -3, now it looks good, but I don’t think I should need to do this.

Just out of curiosity, are you using the Title and Arranger fields from File>Project Info…, with {@flowTitle@} and {@flowArranger@} in that frame?

No, I use {@flowTitle@} and {@flowSubTitle@ in this frame.

Maybe use a separate frame for the subtitle? I’ve done that before and it seems to work well.

Yes, maybe that is the way it should be maybe. I will try that. Thanks.

No, the problem is that the Title text isn’t vertically centered. Comparing with the LayoutName in the top left with the same layout settings, that one is centered. So why isn’t the the Title?

Well that is a puzzle. My current project seems to have the same settings as yours, and the title text is centered. Maybe just delete the title frame and recreate it, and see if that helps. Or even just restarting Dorico?

I sometimes have to do what Eddo and Stephen says, adjust the frame a little bigger (from top to bottom), and all is well. This will “pull” the text a little lower, but you can then move the whole frame up a little to re-position.

I’m not sure if this has to do with different fonts, but I sometimes have to do this. Keep in mind, that if your text is set to “Top” in Vertical Alignment in Properties, you could try increasing the “Padding” option for a quick fix as well. :slight_smile:

What font are you trying to use, André? Is that Trajan? I suspect that there’s something off with the way that font’s metrics are being reported.

I have been experiencing similar issue with various fonts for over year. There are certain fonts his baseline seems to be slightly shifted relative to others and I do not think this is a Dorico glitch per se, but rather something related to the fonts themselves. Four instance, there is one fun I like to use where the tops of lowercase f are regularly cut off but it seems to simply be because particular glyph is “too tall” relative to the others.

If you let us know which fonts you’re experiencing problems with, we can look into it.

Yes, it’s Trajan and after trying out a couple of other fonts, it’s indeed this font that causes this problem. My client asked me specifically for this font so I will use the baseline shift to adjust this.

I’ve seen this behaviour, too. on occasion. I’ll keep an eye on it. I have observed in other apps that OpenType Std fonts often seem to display slightly higher than their PostScript ancestors. (Even mainstream fonts from Adobe, MT, LT, etc.)

Well, looking at the metrics for Trajan I can see why it behaves this way: the ascender value and the cap height value are set to be the same, which is quite unusual, and the serifs and the optical overshoots for the curves on letters like C, G, and O all proceed outside the font’s em square, and I guess Qt doesn’t handle that brilliantly. Rather than using baseline shift, I think you should be able to set the ‘Leading’ value to e.g. 110% or 120% in the paragraph style, and this should help.

I’m also seeing this with my titling and page numbers, using ITC Century Bold (Std OTF). The tops of the characters are cut off, if I use “Top” as the Vertical Alignment. It doesn’t matter how big the text frame is compared to the text.

It may be that the metrics reported by the font are wonky for some reason. Perhaps you could send me by email a simple project that exhibits the problem and the font file itself, so I can take a look?

Daniel, I have looked at the font internals and it seems that if there was a way to take the max of all ascent values and the min of all descent values, then it will probably catch most odd ball cases as well as the regulars. I do find the way the metrics are specified in these particular fonts (and apparently in the OP’s post with Trajan) is that all but the WinAscent values go only up to the capHeight, which is odd to me since any curved letter extends with overshoot. By I also wonder if something can be done on the Qt side of it. I don’t know. Just some thoughts.