Conversation
…ndation defines its own Size and Point.
| CFStringRef fontName = CFStringCreateWithCString(NULL, (const char*)args.data, kCFStringEncodingUTF8); | ||
| font = CTFontCreateWithName(fontName, args.pxSize, NULL); |
There was a problem hiding this comment.
I'm not familiar with Core Text, but is it OK that you pass the whole font data as a name?
There was a problem hiding this comment.
Hm, I forgot to look at this, though it worked for the font which I needed.
There was a problem hiding this comment.
LOL, it just used Helvetica as default font, because there is no font named ttcf, and I only needed Helvetica. Fixed with c7b8761, tested on Times and Helvetica.
| glyphMetrics.size.w = ceil(boundingRect.size.width) + ceil(boundingRect.origin.x); | ||
| #else | ||
| glyphMetrics.size.w = ceil(boundingRect.size.width); | ||
| #endif | ||
| glyphMetrics.offset.x = ceil(boundingRect.origin.x); | ||
|
|
||
| glyphMetrics.size.h = ceil(boundingRect.size.height); | ||
| glyphMetrics.offset.y = ceil(boundingRect.size.height) + ceil(boundingRect.origin.y); |
There was a problem hiding this comment.
I wonder why boundingRect.origin contributes to size of the glyph's bitmap? Have you tried to render the text with tools/draw-text.py?
There was a problem hiding this comment.
I don't know about FreeType and STB, but CoreText draws and calculates everything in floating-point. Most glyphs have non-integer offsets, and if we shift them back so they are rendered from point 0 in our bitmap (by setting position.x=-origin.x), they are displayed slightly different from their original shape. That's why I set position.x=0, so the glyph is rendered starting at its origin.x. But then it's needed to increase the width, so it wouldn't get cut, and set our local origin to 0 (which I forgot to do and now fixed by 88c07d8), because the true origin (floating-point) is already included in our bitmap. I've illustrated it with a drawing:
Here is an image which was generated by draw-text.py with CORETEXT_SHIFT_X_POSITION=0:
Here is an image which was generated by draw-text.py with CORETEXT_SHIFT_X_POSITION=1:
The second one looks almost like rendered by Core Text.
There was a problem hiding this comment.
Both x and y offsets should be in GlyphMetrics::offset, so that they are added during drawing and not baked right into a glyph bitmap.
There was a problem hiding this comment.
They are integer, we can't shift a bitmap by less than a pixel. It's done like you want when CORETEXT_SHIFT_POSITION=0 and you see what happens.
| CGPoint position = boundingRect.origin; | ||
| #if CORETEXT_SHIFT_X_POSITION | ||
| position.x = 0; | ||
| #else | ||
| position.x = -position.x; | ||
| #endif | ||
| position.y = -position.y; |
There was a problem hiding this comment.
You can as well just set coordinates to 0.
There was a problem hiding this comment.
x is explained in the upper conversation, and y should be subtracted, otherwise it's rendered outside of the provided area. dpFontBaker expects that the glyph image will be rendered from (0,0) to (width,height). If we ask CoreText to render a glyph at (0,0), it will be placed from (0+x,0+y) to (x+width,y+height).
There was a problem hiding this comment.
Ah, sorry, I mixed it up with -= operator.
There was a problem hiding this comment.
The renderGlyph() method fills an image of GlyphMetrics::size size, which should be boundingRect.size in your case; the size should not include drawing offsets.
|
Ping, we are interested in that landing upstream. |
|
I made some changes and fixes, fell free to review: |
3 participants
Uses native rendering engine on macOS.
I had to move
SizeandPointintoGeometrynamespace, becauseSizeandPointare already defined in/usr/include/MacTypes.hwhich is included fromCoreFoundation.h.