I'm trying to draw in a CTFrameRef only 8 character per line but I don't know how to do this with CTFrameRef.
I've read "Manual Line Breaking", but they use CTLine and I think use CTFrameRef it's simpler.
Maybe with some kind of frame setter or changing CGPath this could be possible.
This is my code right now (I've deleted comment lines with my testing code about the problem):
// Prepare font
CTFontRef font = CTFontCreateWithName(CFSTR("LucidaSansUnicode"), 16, NULL);
// Create path
CGMutablePathRef gpath = CGPathCreateMutable();
CGPathAddRect(gpath, NULL, CGRectMake(0, 0, 200, 200));
// Create an attributed string
CGContextSetTextDrawingMode (newcontext, kCGTextFillStroke);
CGContextSetGrayFillColor(newcontext, 0.0, 1.0);
CFStringRef keys[] = { kCTFontAttributeName };
CFTypeRef values[] = { font };
CFDictionaryRef attr = CFDictionaryCreate(NULL, (const void **)&keys,
(const void **)&values, sizeof(keys) / sizeof(keys[0]),
&kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFAttributedStringRef attrString = CFAttributedStringCreate(NULL,
CFSTR("Aenean lacinia bibendum nulla sed consectetur."), attr);
CTFramesetterRef framesetter =
CTFramesetterCreateWithAttributedString((CFAttributedStringRef)attrString);
CTFrameRef theFrame =
CTFramesetterCreateFrame(framesetter, CFRangeMake(0,
CFAttributedStringGetLength(attrString)), gpath, NULL);
CTFrameDraw(theFrame, newcontext);
// Clean up... CFRelease...
// Getting TIFF image
I get the following picture:
But I want something like this (there are differences because this image has been made with photoshop):
Thanks and sorry about my English.
Why do you think that CTFrame is simpler for this kind of problem than CTLine? You want an unusual line breaking algorithm. CTFrame uses the default line-break algorithm.
Break your input into 8-character NSAttributedString runs and create CTLineRef objects with them, then draw them. This should be extremely straight-forward. What is causing the confusion?
Related
This image shows a scene in my current app. This appearance is undesirable. The empty GtkList is only taking half the screen. How can I make it take four fifths of the screen and the done button take up one fifth? I am using the C programming language as always and Gtk3 which I just upgraded to. I am also having trouble with fat text entries, if there is a way to adjust the thickness of widgets. Making it homogeneous makes them all the same, but how can I make it NOT homogeneous but let me decide how much of the screen each widget gets?
#include "DisplayHelp.h"
#define NOTHING
void DisplayHelp(void) {
gtk_main_quit(NOTHING);
gtk_widget_destroy(Box);
Box = gtk_vbox_new(0, 0);
GtkWidget *Button = NULL;
GtkWidget *List = gtk_list_box_new();
gtk_container_add(GTK_CONTAINER(Box), List);
gtk_container_add(GTK_CONTAINER(Window), Box);
Button = gtk_button_new_with_label("Done");
gtk_box_pack_start(GTK_BOX(Box), Button, 1, 1, FALSE);
g_signal_connect(Button, "clicked", DisplayOptions, NULL);
// I need a function to adjust the size of the button here
printf("Entering the screen: Help\n");
gtk_widget_show_all(Window);
gtk_main();
}
You can use GtkGrid, set it's vertical homogenity to TRUE and set height for each widget with respect to desired proportions:
grid = gtk_grid_new ();
gtk_grid_set_row_homogeneous (grid, TRUE);
/*l t w h*/
gtk_grid_attach (grid, top_widget, 0, 0, 1, 4);
gtk_grid_attach (grid, bot_widget, 0, 0, 1, 1);
However, it may be not the best design solution, as you are wasting space for button.
I changed pixel array of an image, and I want to display it.
I tried this code (below), but it's doesn't work.
int[] pixelSrcImage;
PixelGrabber pgSrc =
new PixelGrabber(imageSrc, 0, 0, imageHeight, imageWidth, pixelSrcImage, 0,imageWidth);
pgSrc.grabPixels();
pixelSrcImage[...]=...
PixelWriter pw = null;
WritablePixelFormat<IntBuffer> format = WritablePixelFormat.getIntArgbInstance();
pw.setPixels(0, 0, imageWidth, imageHeight, format, step, 0, imageWidth);
Image imView = new Image (pw.???);
You need to define the destination image first and not set the PixelWriter to null.
WritableImage image = new WritableImage(width, height);
PixelWriter pw = image.getPixelWriter();
All I can see from your bits & pieces is that you'll get a NullPointer Exception.
And please consider what jewelsea said.
I have created a view and in my draw rect method I create paths depending on what a user does with sliders. Using standard colors , everything works and looks very nice. I am trying to follow a code snippet from apple that shows how to draw patterns into a rect at this link:
Apple Drawing Guide
The example shows how to create a function callback with the pattern desired and then an additional method call to draw the rect. If I call the code as it is written from my rect it will draw my pattern as I would expect, however, I do not want to fill my rect , I want to fill a specified path in the rect. If I change the call in the drawing method from CGContextFillRect to CGContextFillPath, it doesn't work. I'm sure there is something I am overlooking to modify this code to get it to do what I want.
My callback pattern is a simple checkerboard:
code:
// Call Back function for Graphics Pattern
#define PATTERN_SIZE 10
void patternSpec(void *info , CGContextRef pContext){
NSLog(#"patternSpec Callback Called");
CGFloat subUnit = PATTERN_SIZE / 2;
CGRect square1 = {{0,0}, {subUnit, subUnit}},
square2 = {{subUnit, subUnit}, {subUnit, subUnit}},
square3 = {{0 , subUnit}, {subUnit, subUnit}},
square4 = {{subUnit , 0}, {subUnit, subUnit}};
CGContextSetRGBFillColor(pContext, 1.0, 0.0, 0.0, 1.0 );
CGContextFillRect(pContext, square1);
CGContextSetRGBFillColor(pContext, 1.0, 0.0, 0.0, 1.0 );
CGContextFillRect(pContext, square2);
CGContextSetRGBFillColor(pContext, 0.0, 0.0, 0.0, 1.0 );
CGContextFillRect(pContext, square3);
CGContextSetRGBFillColor(pContext, 0.0, 0.0, 0.0, 1.0 );
CGContextFillRect(pContext, square4);
}
// Method that draws the pattern
static void drawPattern (CGContextRef myContext)
{
NSLog(#"drawPattern Called ");
CGPatternRef pattern;
CGColorSpaceRef patternSpace;
CGFloat alpha = 1.0;
//width, height;
static const CGPatternCallbacks callbacks = {0, &patternSpec, NULL};
CGContextSaveGState (myContext);
patternSpace = CGColorSpaceCreatePattern (NULL);// 6
CGContextSetFillColorSpace (myContext, patternSpace);// 7
CGColorSpaceRelease (patternSpace);// 8
pattern = CGPatternCreate (NULL,CGRectMake (0, 0, PATTERN_SIZE, PATTERN_SIZE),
CGAffineTransformIdentity, PATTERN_SIZE, PATTERN_SIZE,
kCGPatternTilingConstantSpacing true, &callbacks);
CGContextSetFillPattern (myContext, pattern, &alpha);// 17
CGPatternRelease (pattern);// 18
//CGContextFillRect(myContext, rect);
CGContextDrawPath(myContext, kCGPathFill);
CGContextRestoreGState (myContext);
}
Here is a snippet of the code where I would like to call the routine:
CGContextSetLineWidth(context, .7);
CGContextSetRGBStrokeColor(context, 0.0, 0.0, 0.0, 1.0);
// Standard non-inverted view scenario.
CGContextBeginPath(context);
CGContextMoveToPoint(context, 0.00 , bMargin);
CGContextAddLineToPoint(context, highPX - curveSP , bMargin);
[self addCurve:context startX:highPX startY:bMargin radius:bo curveSp:curveSP curveDir:FL_BL];
CGContextAddLineToPoint(context, highPX, ((h - tMargin) - curveSP) );
[self addCurve:context startX:highPX startY: (h - tMargin) radius:bo curveSp:curveSP curveDir:FL_TL];
CGContextAddLineToPoint(context, (lowPX - curveSP), (h - tMargin) );
[self addCurve:context startX: lowPX startY: (h - tMargin) radius:bo curveSp:curveSP curveDir:FL_TR];
CGContextAddLineToPoint(context, lowPX, (bMargin + curveSP) );
[self addCurve:context startX:lowPX startY: bMargin radius:bo curveSp:curveSP curveDir:FL_BR];
CGContextAddLineToPoint(context, w, bMargin);
//CGContextDrawPath(context, nonInvertedView);
CGContextDrawPath(context, kCGPathStroke);
// fill with pattern
drawPattern(context);
The actual apple example also includes an NSRect arg in the drawing method, but since I don't want to fill a rect, I figured I could omit that. not sure though.
Thanks
CGContextDrawPath resets the current path. (They used to mention that somewhere, but I couldn't find it in a quick search.)
Save the graphics state before you stroke, then restore before you fill with the pattern.
(I assume you're specifically trying to get an outer stroke by stroking and then filling over half of it. If you want or can accept a centered stroke, kCGPathFillStroke will do the job with a single CGContextDrawPath call.)
So heres an update: I don't fully understand whats happening, but if I drop the code in the drawPattern method into a test app with an empty rect, it draws just like it should. If I drop the code into my method for drawing a path into a view , I get very strange behavior; it even tries to redraw parts of the view controller it should't even know about.
As soon as I deleted the CGContextSaveGState() , CGColorSpaceRelease(), CGPatternRelease(), and the CGContextRestoreGState(), the code started doing exactly what I wanted. I modified the method to this:
static void drawPattern(CGContextRef *pContext){
static CGPatternRef pattern;
static CGColorSpaceRef patternSpace;
static CGFloat alpha = 1.0;
static const CGPatternCallbacks callbacks = {0, &patternSpec, NULL};
patternSpace = CGColorSpaceCreatePattern (NULL);
CGContextSetFillColorSpace (pContext, patternSpace);
pattern = CGPatternCreate (NULL,
CGRectMake (0, 0, PATTERN_SIZE, PATTERN_SIZE),
CGAffineTransformIdentity,
PATTERN_SIZE,
PATTERN_SIZE,
kCGPatternTilingConstantSpacing,
true, &callbacks);
CGContextSetFillPattern (pContext, pattern, &alpha);
}
Now I can either call the defined pattern, or set a define fill color:
CGContextSetFillColor(context);
or:
drawPattern(context);
I would appreciate input on this, because I would like to know if leaving out some of these saveState or Release methods is a problem such as memory leaks.
Thanks
According to the docs, CTFramesetterSuggestFrameSizeWithConstraints () "determines the frame size needed for a string range".
Unfortunately the size returned by this function is never accurate. Here is what I am doing:
NSAttributedString *string = [[[NSAttributedString alloc] initWithString:#"lorem ipsum" attributes:nil] autorelease];
CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString((CFAttributedStringRef) string);
CGSize textSize = CTFramesetterSuggestFrameSizeWithConstraints(framesetter, CFRangeMake(0,0), NULL, CGSizeMake(rect.size.width, CGFLOAT_MAX), NULL);
The returned size always has the correct width calculated, however the height is always slightly shorter than what is expected.
Is this the correct way to use this method?
Is there any other way to layout Core Text?
Seems I am not the only one to run into problems with this method. See https://devforums.apple.com/message/181450.
Edit:
I measured the same string with Quartz using sizeWithFont:, supplying the same font to both the attributed string, and to Quartz. Here are the measurements I received:
Core Text: 133.569336 x 16.592285
Quartz: 135.000000 x 31.000000
try this.. seem to work:
+(CGFloat)heightForAttributedString:(NSAttributedString *)attrString forWidth:(CGFloat)inWidth
{
CGFloat H = 0;
// Create the framesetter with the attributed string.
CTFramesetterRef framesetter = CTFramesetterCreateWithAttributedString( (CFMutableAttributedStringRef) attrString);
CGRect box = CGRectMake(0,0, inWidth, CGFLOAT_MAX);
CFIndex startIndex = 0;
CGMutablePathRef path = CGPathCreateMutable();
CGPathAddRect(path, NULL, box);
// Create a frame for this column and draw it.
CTFrameRef frame = CTFramesetterCreateFrame(framesetter, CFRangeMake(startIndex, 0), path, NULL);
// Start the next frame at the first character not visible in this frame.
//CFRange frameRange = CTFrameGetVisibleStringRange(frame);
//startIndex += frameRange.length;
CFArrayRef lineArray = CTFrameGetLines(frame);
CFIndex j = 0, lineCount = CFArrayGetCount(lineArray);
CGFloat h, ascent, descent, leading;
for (j=0; j < lineCount; j++)
{
CTLineRef currentLine = (CTLineRef)CFArrayGetValueAtIndex(lineArray, j);
CTLineGetTypographicBounds(currentLine, &ascent, &descent, &leading);
h = ascent + descent + leading;
NSLog(#"%f", h);
H+=h;
}
CFRelease(frame);
CFRelease(path);
CFRelease(framesetter);
return H;
}
For a single line frame, try this:
line = CTLineCreateWithAttributedString((CFAttributedStringRef) string);
CGFloat ascent;
CGFloat descent;
CGFloat width = CTLineGetTypographicBounds(line, &ascent, &descent, NULL);
CGFloat height = ascent+descent;
CGSize textSize = CGSizeMake(width,height);
For multiline frames, you also need to add the line's lead (see a sample code in Core Text Programming Guide)
For some reason, CTFramesetterSuggestFrameSizeWithConstraints() is using the difference in ascent and descent to calculate the height:
CGFloat wrongHeight = ascent-descent;
CGSize textSize = CGSizeMake(width, wrongHeight);
It could be a bug?
I'm having some other problems with the width of the frame; It's worth checking out as it only shows in special cases. See this question for more.
The problem is that you have to apply a paragraph style to the text before you measure it. If you don't then you get the default leading of 0.0. I provided a code sample for how to do this in my answer to a duplicate of this question here https://stackoverflow.com/a/10019378/1313863.
ing.conti's answer but in Swift 4:
var H:CGFloat = 0
// Create the framesetter with the attributed string.
let framesetter = CTFramesetterCreateWithAttributedString(attributedString as! CFMutableAttributedString)
let box:CGRect = CGRect.init(x: 0, y: 0, width: width, height: CGFloat.greatestFiniteMagnitude)
let startIndex:CFIndex = 0
let path:CGMutablePath = CGMutablePath()
path.addRect(box)
// Create a frame for this column and draw it.
let frame:CTFrame = CTFramesetterCreateFrame(framesetter, CFRangeMake(startIndex, 0), path, nil)
// Start the next frame at the first character not visible in this frame.
//CFRange frameRange = CTFrameGetVisibleStringRange(frame);
//startIndex += frameRange.length;
let lineArray:CFArray = CTFrameGetLines(frame)
let lineCount:CFIndex = CFArrayGetCount(lineArray)
var h:CGFloat = 0
var ascent:CGFloat = 0
var descent:CGFloat = 0
var leading:CGFloat = 0
for j in 0..<lineCount {
let currentLine = unsafeBitCast(CFArrayGetValueAtIndex(lineArray, j), to: CTLine.self)
CTLineGetTypographicBounds(currentLine, &ascent, &descent, &leading)
h = ascent + descent + leading;
H+=h;
}
return H;
I did try and keep it as 1:1 with the Objective C code but Swift is not as nice when handling pointers so some changes were required for casting.
I also did some benchmarks comparing this code (and it's ObjC counterpart) to another height methods. As a heads up, I used a HUGE and very complex attributed string as input and also did it on the sim so the times themselves are meaningless however the relative speeds are correct.
Runtime for 1000 iterations (ms) BoundsForRect: 8909.763097763062
Runtime for 1000 iterations (ms) layoutManager: 7727.7010679244995
Runtime for 1000 iterations (ms) CTFramesetterSuggestFrameSizeWithConstraints: 1968.9229726791382
Runtime for 1000 iterations (ms) CTFramesetterCreateFrame ObjC: 1941.6030206680298
Runtime for 1000 iterations (ms) CTFramesetterCreateFrame-Swift: 1912.694974899292
It might seem strange but I found that if you use ceil function first and then add +1 to the height it will always work. Many third party APIs use this trick.
Resurrecting.
When initially determining where lines should be placed within a frame, Core Text seems to massage the ascent+descent for the purposes of line origin calculation. In particular, it seems like 0.2*(ascent+descent) is added to the ascent, and then both the descent and resultant ascent are modified by floor(x + 0.5), and then the baseline positions are calculated based on these adjusted ascents and descents. Both of these steps are affected by certain conditions whose nature I am not sure, and I also already forgot at which point paragraph styles are taken into account, despite only looking into it a few days ago.
I've already resigned to just considering a line to start at its baseline and not trying to figure out what the actual lines land at. Unfortunately, this still does not seem to be enough: paragraph styles are not reflected in CTLineGetTypographicBounds(), and some fonts like Klee that have nonzero leadings wind up crossing the path rect! Not sure what to do about this... probably for another question.
UPDATE
It seems CTLineGetBoundsWithOptions(line, 0) does get the proper line bounds, but not quite fully: there's a gap between lines, and with some fonts (Klee again) the gap is negative and the lines overlap... Not sure what to do about this. :| At least we're slightly closer??
And even then it still does not take paragraph styles into consideration >:|
CTLineGetBoundsWithOptions() is not listed on Apple's documentation site, possibly due to a bug in the current version of their documentation generator. It is a fully documented API, however — you'll find it in the header files and it was discussed at length at WWDC 2012 session 226.
None of the options are relevant to us: they reduce the bounds rect by taking certain font design choices into consideration (or increase the bounds rect randomly, in the case of the new kCTLineBoundsIncludeLanguageExtents). One useful option in general, though, is kCTLineBoundsUseGlyphPathBounds, which is equivalent to CTLineGetImageBounds() but without needing to specify a CGContext (and thus without being subject to an existing text matrix or CTM).
After weeks of trying everything, any combination possible, I made a break through and found something that works. This issue seems to be more prominent on macOS than on iOS, but still appears on both.
What worked for me was to use a CATextLayer instead of a NSTextField (on macOS) or a UILabel (on iOS).
And using boundingRect(with:options:context:) instead of CTFramesetterSuggestFrameSizeWithConstraints. Even though in theory the latter should be more lower level than the former, and I was assuming would be more precise, the game changer turns out to be NSString.DrawingOptions.usesDeviceMetrics.
The frame size suggested fits like a charm.
Example:
let attributedString = NSAttributedString(string: "my string")
let maxWidth = CGFloat(300)
let size = attributedString.boundingRect(
with: .init(width: maxWidth,
height: .greatestFiniteMagnitude),
options: [
.usesFontLeading,
.usesLineFragmentOrigin,
.usesDeviceMetrics])
let textLayer = CATextLayer()
textLayer.frame = .init(origin: .zero, size: size)
textLayer.contentsScale = 2 // for retina
textLayer.isWrapped = true // for multiple lines
textLayer.string = attributedString
Then you can add the CATextLayer to any NSView/UIView.
macOS
let view = NSView()
view.wantsLayer = true
view.layer?.addSublayer(textLayer)
iOS
let view = UIView()
view.layer.addSublayer(textLayer)
Unfortunately, Lucida Grande does not have an italic variant and I need one.
My options here seem limited and I am hoping someone has a better one for me.
First, I tried, applying a NSAffineTransform by doing the following:
NSFont *theFont = [NSFont systemFontOfSize:[NSFont systemFontSizeForControlSize:NSMiniControlSize]];
const CGFloat kRotationForItalicText = -15.0;
NSAffineTransform *italicTransform = [NSAffineTransform transform];
[italicTransform scaleBy:[NSFont systemFontSizeForControlSize:NSMiniControlSize]];
[italicTransform rotateByDegrees:kRotationForItalicText];
theFont = [NSFont fontWithDescriptor:[theFont fontDescriptor] textTransform:italicTransform];
but, this does not produce text that is particularly readable.
My next option is to switch to a different font:
theFont = [NSFont userFontOfSize:[NSFont labelFontSize]];
theFont = [sharedFontManager convertFont:theFont toHaveTrait:NSItalicFontMask];
and while the text here is readable when italicized, I would rather be using the same font since it is obviously different.
I could, of course, use userFontOfSize font for both my italic and non-italic text, but I am currently limited to using the systemFontOfSize font.
Do I have any other (good) options?
Thank you.
This answer will be similar to my initial one, but updated for what, after more testing, works.
So, first, my method of creating the italic font was deeply flawed. Instead of simply applying a rotation to the text, I needed to apply a skew transform. I ended up finding a good skew transform to apply at WebKit's Font code. It contained the skew transform:
CGAffineTransformMake(1, 0, -tanf(SYNTHETIC_OBLIQUE_ANGLE * acosf(0) / 90), 1, 0, 0)
It does look good.
Simply using a different font is not the correct answer. While the Lucida Sans font is virtually identical to Lucida Grande (which is returned by systemFontOfSize) and has a real italic variant, the italic variant will not draw Japanese Characters in italic.
So, what appears to be the only answer is to obtain the systemFontOfSize, check to see if it has an italic variant, and, if not, add a skew transform.
Here is my final solution:
NSFont *theFont = [NSFont systemFontOfSize:[NSFont systemFontSizeForControlSize:NSMiniControlSize]];
NSFontManager *sharedFontManager = [NSFontManager sharedFontManager];
if ( wantItalic )
{
theFont = [sharedFontManager convertFont:theFont toHaveTrait:NSItalicFontMask];
NSFontTraitMask fontTraits = [sharedFontManager traitsOfFont:theFont];
if ( !( (fontTraits & NSItalicFontMask) == NSItalicFontMask ) )
{
const CGFloat kRotationForItalicText = -14.0;
NSAffineTransform *fontTransform = [NSAffineTransform transform];
[fontTransform scaleBy:[NSFont systemFontSizeForControlSize:NSMiniControlSize]];
NSAffineTransformStruct italicTransformData;
italicTransformData.m11 = 1;
italicTransformData.m12 = 0;
italicTransformData.m21 = -tanf( kRotationForItalicText * acosf(0) / 90 );
italicTransformData.m22 = 1;
italicTransformData.tX = 0;
italicTransformData.tY = 0;
NSAffineTransform *italicTransform = [NSAffineTransform transform];
[italicTransform setTransformStruct:italicTransformData];
[fontTransform appendTransform:italicTransform];
theFont = [NSFont fontWithDescriptor:[theFont fontDescriptor] textTransform:fontTransform];
}
}
So, first, my method of creating the italic font was deeply flawed. Instead of simply applying a rotation to the text, I needed to apply a skew transform. I ended up finding a good skew transform to apply at WebKit's Font code. It contained the skew transform:
CGAffineTransformMake(1, 0, -tanf(SYNTHETIC_OBLIQUE_ANGLE * acosf(0) / 90), 1, 0, 0)
It does look good. The cocoa code to set this up is:
const CGFloat kRotationForItalicText = -14.0;
NSAffineTransform *fontTransform = [NSAffineTransform transform];
[fontTransform scaleBy:[NSFont systemFontSizeForControlSize:NSMiniControlSize]];
NSAffineTransformStruct italicTransformData;
italicTransformData.m11 = 1;
italicTransformData.m12 = 0;
italicTransformData.m21 = -tanf( kRotationForItalicText * acosf(0) / 90 );
italicTransformData.m22 = 1;
italicTransformData.tX = 0;
italicTransformData.tY = 0;
NSAffineTransform *italicTransform = [NSAffineTransform transform];
[italicTransform setTransformStruct:italicTransformData];
However, I was told by another person that the "Lucida Sans" font is virtually identical to Lucida Grande and does have a real italic variant.
So, basically, I am using a different font, but one that should meet with full approval. However, if for some reason the Lucida Sans font cannot be found, I will default back to systemFontOfSize and apply the above transform to it if necessary.
You rock! I made one mod -16.0 instead of -14.0 rotation... so user can find italicized values more easily in a giant spreadsheet.
My problem was that using a non-LucidaGrande font causes all kinds of vertical alignment issues throughout my UI.