A very similar question was asked here but the really answered sufficiently...
The CSS line-height property controls the amount of white space above the letters. Making it bigger/smaller spaces rows of text farther/closer together. But if you set the line height to the exact same value as the font-size, the text will still have white space above them.
So this DOESN'T quite work...
div { height: 80px; }
span { font-size : 80px; line-height : 80px; }
<div>
<span>Foo</span>
</div>
http://jsfiddle.net/s_d_p/yMHVs/
The degree to which the enclosed text actually matches the container height seems to differ from font to font.
So my question is two parts:
What are we actually adjusting when we set line-height?
Is there a way to remove it entirely so that letter fit precisely inside their container?
Note that the remaining/extra space is typically a symptom of the font being used, as designated by its designer.
Thus, the 80px includes the allocated white space above and/or below. Additional white space above is typically provided to allow for accented characters, which would otherwise require the letter itself to be compressed- producing an inconsistent typeface.
See here & here for further information.
Line height refers to the total height of the typeface, inclusive of any allocated whitespace.
i'm sure that space is reserved for some characters that need more space. like this one:
Fj╛
character "j" need more space that "F" and i'm sure again that there is other characters (like "╛") that needs some space in above and bottom. so font designer reserved this space for that characters.
jsFiddle
Related
I use NSTextView to render NSAttributedStrings that may contain non-Latin characters, and it seems that lines containing any CJK character are always 6 pixels taller than lines without those. Even setting the NSParagraphStyle's minimumLineHeight property to a much higher value (e.g. 32 pixels, when using the standard system font size) retains this problem (Lines with CJK characters a rendered as 38 pixels).
Moreover, NSAttributedString's boundingRectWithSize seems to report the wrong ("correct") size (without the extra 6 pixels).
What am I missing?
Setting layoutManager.usesFontLeading to NO solved this problem.
I am attempting to render a series of UNICODE characters onto a spritesheet. This all works quite well for most characters, including Cyrillic ones.
When using GetCharABCWidthsFloat with certain CJKV characters however, the ABCFLOAT::abcfB parameter provides a value lower than expected. It does not account for underhangs or overhangs, which is the exact purpose of the ABCs:
The B spacing is the width of the drawn portion of the character glyph.
Source: ABCFLOAT | Microsoft Docs
As you can see, all characters do not overlap left-to-right, except the last few characters:
I get around this by creating a customizable padding option, to handle such cases, but this bloats the rest of the glyphs and thus requires a larger surface:
Font being used is Arial. For the character 美, ABC returns (2, 10, 2), which sums to a advance of 14 pixels, when in fact, 17 pixels are needed.
I use TextOut to actually render the glyphs, but I do wonder if there is someone out there who's experienced this and came up with a universal solution.
Using functions like GetTextExtentPoint32W or DrawTextEx to get the rectangle does not allow precise per-character placement, which is the whole point of the ABC. And some unmentioned functions only work with TrueType fonts.
I question if certain characters shift to a different font under certain conditions, causing the results to be inaccurate. If that is the case, is there a way to determine if a character is not available for a font, knowing what Windows does automatically so I can reproduce the behaviour? That is, is there some sort of way to determine when a character should fall back on another font, and a way to determine what that font should be?
I have been on this problem for quite some time, so anyone with experience with these APIs would be greatly welcomed!
From the documentation on GetCharABCWidthsFloat:
The ABC widths of the default character are used for characters outside the range of the currently selected font.
Arial contains a lot of characters, including Cyrillic, but it does not contain CJKV ideographs. Other text-related calls may give you the false impression that it does have those characters (through a default/fallback font mechanism).
Before using (maybe before getting) the ABCFLOAT, you should first check that the characters you want metrics for are within the range of the currently selected font.
This is a followup to this.
After encountering issues with certain character compositions not working identically between Cocoa and Core Text, I decided to give Cocoa's text API a chance. Now, I need to be able to decompose a line vertically into each of its constituent parts:
whitespace due to NSParagraphStyle.paragraphSpacingBefore
whitespace due to NSParagraphStyle.lineHeightMultiple
typographic line ascent
typographic line descent
typographic line leading (line gap)
whitespace due to NSParagraphStyle.lineSpacing but not due to leading
whitespace due to NSParagraphStyle.paragraphSpacing
In Core Text, for the line ascent, descent, and leading, I could call CTLineGetBoundsWithOptions(0) and CTLineGetBoundsWithOptions(kCTLineBoundsExcludeTypographicLeading) (the origin of both of these rects is the baseline so I know where to chop) and then recreate Core Text's internal calculations for the CTParagraphStyle entries.
But I'm not sure what to do with NSLayoutManager, and trying to recreate the internal calculations isn't helping too much.
From what I can see, Cocoa's text system provides the following ways to get metric rectangles:
-[NSLayoutManager lineFragmentRectForGlyphAtIndex:effectiveRange:]
-[NSLayoutManager lineFragmentUsedRectForGlyphAtIndex:effectiveRange:]
-[NSLayoutManager boundingRectForGlyphRange:inTextContainer:]
However, these are not adequate enough to give me the data I need. For the first two, Apple has this to say:
In addition to the line fragment rectangle itself, the typesetter returns a rectangle called the used rectangle. This is the portion of the line fragment rectangle that actually contains glyphs or other marks to be drawn. By convention, both rectangles include the line fragment padding and the interline space calculated from the font’s line height metrics and the paragraph’s line spacing parameters. However, the paragraph spacing (before and after) and any space added around the text, such as that caused by center-spaced text, are included only in the line fragment rectangle and not in the used rectangle.
And the last seems to be completely unrelated to the first two :S
I did try to recreate Core Text's logic to determine what the line ascent and descent should be, assuming that the line ascent starts from the maximum font ascent of all the glyphs on the line, but that didn't quite work: instead of having the previous descent and the current ascent be the same line on a font with no leading like Palatino and no paragraph style, the two lines were some points apart :S
So is what I want possible? If not, I'll have to investigate ways to get Core Text to render and position combining accents the same way as Cocoa, or worse, manually lay out lines to at least avoid overlap (worse because I assume Apple knows what they are doing...)
This is for Mac OS X; I need to target 10.8 or newer. Thanks!
I bought a new iMac 27 inch and one of the first things I did was installing my text editor of choice, Sublime Text. After a bit of writing code I noticed that the indentation with tabs is to wide. In the bottom left corner it says Tab Size: 4 but in fact one tab is as wide as 12 spaces. When changing the setting to Tab Size: 2 one tab is as wide as 6 spaces.
Could it be that Sublime multiplies the length of one tab with 3 because of the large resolution (2560 x 1440)? Does anybody know how to fix this issue?
EDIT:
I use the Ubuntu Mono font with 16px font size. When setting the option Indent Using Spaces everything works as expected. Here an image of the current situation with Tab Size: 4.
Sublime works fine on my iMac, so the screen resolution isn't the issue. Instead, I would suspect that you are using a proportional font instead of a fixed-width one. A likely cause of this is lacking the specified font on your new system - I use a non-system font with Sublime, and so need to install it on new computers before everything looks right to me.
With a proportional font, spaces tend to be rather small, especially when compared to "large" characters like D, W, e, s, etc., that take up a proportionally larger amount of horizontal space (hence the name proportional font). Additionally, a tab character may be calculated by Sublime to be a certain size as a function of the pixel size of the font, and so may bear no relation to the actual number of space characters it takes to equal the size of the tabstop. I know that in programs such as MS Word, tabstops are set in fractions of an inch (or cm, or pica, or whatever), and have no relation to the type or size of font being used.
All this is simplified with fixed-width fonts. All characters (even Unicode ones) take up the same horizontal width. Sublime calculates the width of tabs using the standard character width, so everything is consistent.
All that being said, how to fix your problem? The easiest way to determine if this actually is the problem is to set your "font_face" setting to Menlo, an Apple-designed fixed-width font that's been on all their systems since the early days of the Macintosh. If your code goes back to looking like normal, that was the issue. You can then search for whichever font you were using before, if you like, or take a look at my favorite font, linked above, or just keep using Menlo if you're not too picky.
Good luck!
GetTextExtent32 returns different character width ratios (e.g., width of '9' versus space) than Word or Acrobat use when displaying the same font (e.g., 10-point Arial).
This matters because I'm trying to prepare clipboard strings that will get pasted into apps that don't support much formatting (no tabs or tables), but I still need to align certain columns of info. I'm trying to overcome this challenge by dynamically calculating the number of spaces I need to insert (remember, no tabs allowed!).
For example, calling GetTextExtent32 with a selected font of Arial 10-point gives a logical unit width of 7 for the digit '9', and a logical unit width of 4 for a space. This ratio proves correct when using something like DrawText.
However, when I export strings to Word or Acrobat, it turns out that 2 spaces in this example font exactly equals the width of one 9 (whether looking at a single 9, or nine contiguous 9s). I don't know much about fonts, but it doesn't appear to be any kind of juxtaposition issue; GetCharABCWidths shows 0 for both the a and c widths.
Does anyone know why Word and Acrobat are not showing the same proportions/measurements for a given font as Windows itself? Is there are a way to calculate this?