New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix/text underline #593
Conversation
…ed pixel size (#448), fixed getKerning returning scaled values even for bitmap fonts.
This is actually 2 bugfixes in one PR. |
Ok for me. |
Out of curiosity, where did you find the magic numbers |
I think you can answer your own question better than I can ;) |
Doh... Shouldn't |
That's what I initially thought as well... But considering that the fallback is only returned for non-scalable fonts, you won't be able to notice any difference between the underline thickness of bold and non-bold characters because well... non-scalable fonts don't support emboldening :P. From what I understand, the font glyphs in a bitmap font should already be styled as you would use it in your application, so glyphs should already be in italics/bold if you want italic/bold text. I don't know if the same applies to underlines as well, but it might be a possibility. |
I was not talking about non-scalable fonts ;) |
IMO the font style shouldn't affect underlines or strikethroughs. It won't for classic typewriters either (for obvious reasons). If you're able to set the style or thickness of the underline, it shouldn't change based on font style (e.g. in Word you'll set the font size but afaik this won't have any influence on the underline thickness. |
Well... since underline_thickness and underline_position are taken directly from the scaled FreeType face, it will scale them for us ;). No need to get our hands dirty when others already did so... especially since this value was available the whole time and SFML just didn't use it.
Actually, I tried when Laurent initially asked, and Word does scale the underline thickness based on font size. It kind of makes sense if you think of a hypothetical case where you would have a 1000 size font and only end up having 3 pixels of underline ;). |
But the FreeType face doesn't know you want bold glyphs. Bold is only applied when you render a glyph, not when you load a face. The loaded face has no style information. So when you request its underline thickness, it gives always the same value, regardless of the style. |
Hmm... Ok... I tried emboldening some text in Word with the Sansation font and the underline didn't change at all... The same applies for many other random fonts I tested. As examples, Arial and Times New Roman scale the thickness, Lucida Console and Handwriting don't. So I guess the style doesn't have to have an effect on the underline thickness? I have no idea what Word does with the fonts that embolden the underline, but in any case FreeType doesn't provide enough information to allow us to scale the thickness according to whether we want a bold underline or not. So I guess the implementation in this PR is as good as FreeType allows us to do unless I am missing something. |
I guess it makes sense. Imagine an underlined sentence with only one bold word in the middle (like a Google search result), it would be really weird to have the underline thicker under this word. So, this PR is definitely OK for me :p |
Try typing "Welcome to SFML Pong!" into Word using Arial with underline and make sure it fits on one line. If you embolden all the text, the underline thickness is scaled. If you just set the "P" to bold, the underline thickness isn't scaled. Now for the fun part: If you break the line before the "P", so the bold "P" starts the next line, the underline thickness of the second line is scaled whereas the first isn't. Hackish? Sure... Random? Possibly... I never tried to understand these things :P. I guess for professional printing that really puts value on these kinds of things, Word wouldn't be the prime candidate ^^. |
Funny. Ok, let's keep things simple in SFML then 😄 |
I'd like to merge this and wonder if it can't be merged for 2.2 already? I don't see any API-breaking changes. |
If it has been tested enough, yes, let's release it as soon as possible. |
No issues on my side, gonna merge this now, thanks. |
Merged, branch can be deleted. |
Don't forget to change the milestone to 2.2 if it's merged already now :) |
No description provided.