Search the Community
Showing results for tags 'baseline shifts'.
-
("W.a.d." in subject-line stands for "working as designed".) Before I call this a bug I'll post about it here — see if there's some "w.a.d." behavior I'm just not aware of. The situation: a block of text entered in a font (from Google Fonts) called Cormorant Garamond Semibold. I decide to add a run-in subhead using a font named Mukta (also from Google Fonts). I decide later to move the run-in subhead to a different paragraph. So I highlight that text, and the spaceband (old typesetter term meaning a word space) that follows it, and press Control+X. Immediately the baselines of all lines in the paragraph shift upward by a couple of points. I press Control+Z to undo the change. The baselines return to where they were before. I re-select the inline subhead, but this time I don't include the spaceband that follows it. Again I cut the text with Control+X. This time the baseline does not shift upward. Next test: I select the run-in subhead and simply delete it, leaving the spaceband behind (it is now the first character in the paragraph). No baseline shift. Then I delete the spaceband. The baselines shift again. Later, after making a few point-size changes to the run-in subhead, I can't replicate the unexpected baseline-shift behavior. When it was happening, I checked the baseline offset value in the Character panel and it was the same for all text (it was the nominal point size value for the paragraph as a whole). Whatever the culprit might be, this kind of thing could play complete havoc with a publication's baseline grid and so: wotthehell might be going on here? Ring any bells?
- 14 replies
-
- fonts
- paragraphs
-
(and 2 more)
Tagged with: