I want to make a controller button prompt in my game where it says 'Press X to Join', but I want the X to be an actual graphic of the 'X' button, like how it is in many games. How would I go about doing that? Right now I'm just putting a big space in my prompt text and putting a UI Image of the button in it, but I want to know if there's a better way about it.
For the sake of scaling to different resolution sizes, you would wanna scale the anchors of the UI elements correctly and have an appropriate parent-child relation tree in Unity's hierarchy.
The red box is the hierarchy.
The 2 green boxes shows ways of scaling the anchors.
The orange box shows the end result of it.
Anchors in combination with their relative position, allows Unity's UI elements to scale up and down according to screen size.
So for example if you say that an anchor is at 0.25x, that would be that its anchored at 25% of for example the x axis. Same goes if you set it for the y axis, just the vertical instead of horizontal anchoring.
You can use the anchors to adjust a minimum and a maximum anchor which the elements may float within, they may have the same value as well, then it's a fixed anchor point.
To clarify, I suggest that you use a panel to hold 2 text elements and the image with the X, each text element being on the left and right side of the X instead of having spacing inside the UI text elements. To keep correct spacing you then must use anchor points. This way your spacing stays correct despite changing screen and resolution sizes.
Please note that the "left", "top", "right" and "bottom" values are then relative to the anchor points. So if you move "left" 5 pixels, those 5 pixels will be out from the relative anchor point.
Here's the values I used:
My left text is at 0.25x, right text is at 0.8x, image is at 0.5x.
The panel holding the 3 is at 0.2 minimum x to 0.8 max x, same goes for y axis.
The largest parent panel is stretched to max fit in the canvas.
Currently I'm working on a text rendering algorithm that samples pixels from a font atlas. The text is in a horizontal layout from left to right.
Since true type fonts support left & right bearing, it is possible that two glyphs can overlap horizontally. That means, that a horizontal pixel coordinate in the string can belong to either of the two overlapping glyphs. For example with the glyph combination "Ta" in many fonts (mostly cursive) the upper pixels in the overlapping area will belong to the T-bar while the lower pixels will belong to the left border of the a.
This would complicate the algorithm I'm developing, but it would still be fixable as long as one horizontal pixel coordinate belongs to two glyphs max.
Now my question:
Are there any fonts/languages where a horizontal pixel coordinate can belong to more than two glyphs (only horizontal text, not vertical)?
I am pretty sure that the answer is yes.
I recommend the accepted answer to RegEx match open tags except XHTML self-contained tags for a fun stress test of how badly messed up font rendering can become. (I recommend that answer anyways for its humor value.)
I know Win2D allows you to draw text within a specific rectangle and you can set it so that text not within that rectangle is clipped so that it isn't drawn.
I was wondering if it would be possible to do this with not just a rectangle but any Geometry (which may include curved lines)
What I get with rectangular clipping:
What I want (clipping by the white rounded rectangle with the curved bottom):
One of the CreateLayer overloads will probably do what you want:
http://microsoft.github.io/Win2D/html/Overload_Microsoft_Graphics_Canvas_CanvasDrawingSession_CreateLayer.htm
I have an XY graph with a legend that automatically resizes to fit the contents of the legend. The problem is that sometimes the legend text is such that the resizing overlaps the plot, see the image below. Is there a way to keep the legend from resizing over the plot data? In other words to confine the resizing operation to outside of the plot box?
Update: it would seem that part of the problem is the auto expand ability of the legend always expands to the left-hand side. Placing the legend on the left-hand side of the plot keeps the legend from covering the graph.
1:
You probably have moved the legend, changing it's anchor point. You can move the legend to the right side of the graph element and it should re-anchor.
I have written a simple Cocoa app for Mac OS X (10.7) using Xcode 4.2. All the app does is create a window with a scrollable array of sub-Views in it, each representing a page to draw stuff on at a very low level. The sub-View's isFlipped method delivers YES, so the origin of every sub-View is the upper left corner. Using various Core Graphics routines, I'm able to draw lines and fill paths and all that fun PostScripty stuff successfully.
It's drawing glyphs from a given font that's got me confused.
Here's the complete code, cut-n-pasted from the program, for the sub-View's -drawRect: method --
- (void)drawRect:(NSRect)dirtyRect
{
// Start with background color for any part of this view
[[NSColor whiteColor] set];
NSRectFill( dirtyRect );
// Drop down to Core Graphics world, ensuring there's no side-effects
context = (CGContextRef) [[NSGraphicsContext currentContext] graphicsPort];
CGContextSaveGState(context);
{
//CGFontRef theFont = CGFontCreateWithFontName(CFSTR("American Typewriter"));
//CGContextSetFont(context, theFont);
CGContextSelectFont(context, "American Typewriter", 200, kCGEncodingMacRoman);
CGContextSetFontSize(context, 200);
// Adjust the text transform so the text doesn't draw upside down
CGContextSetTextMatrix(context, CGAffineTransformScale(CGAffineTransformIdentity, 1, -1));
CGContextSetTextDrawingMode(context, kCGTextFillStroke);
CGContextSetRGBFillColor(context, 0.0, .3, 0.8, 1.0);
// Find the center of view's (not dirtyRect's) bounds
// View is 612 x 792 (nominally 8.5" by 11")
CGPoint centerPoint;
CGRect bds = [self bounds];
centerPoint.x = bds.origin.x + bds.size.width / 2;
centerPoint.y = bds.origin.y + bds.size.height / 2;
// Create arrays to hold glyph IDs and the positions at which to draw them.
#define glyphCount 1 // For now, just one glyph
CGGlyph glyphs[glyphCount];
CGPoint positions[glyphCount];
glyphs[0] = 40; // Glyph ID for '#' character in above font
positions[0] = centerPoint;
// Draw above center. This works.
CGContextShowGlyphsAtPoint(context, centerPoint.x, centerPoint.y - 200.0, glyphs, glyphCount);
// Draw at center. This works.
CGContextShowGlyphsAtPoint(context, positions[0].x, positions[0].y, glyphs, glyphCount);
// Draw below center. This fails (draws nothing). Why?
positions[0].y += 200.0;
CGContextShowGlyphsAtPositions(context, glyphs, positions, glyphCount);
}
CGContextRestoreGState(context);
}
What's got me pulling my hair out is that the first two glyph-drawing calls using CGContextShowGlyphsAtPoint() work fine as expected, but the third attempt using CGContextShowGlyphsAtPositions() never draws anything. So there are only two # symbols on the page, rather than three. This difference in behaviors doesn't depend on whether I've previously used CGContextSetFont() or CGContextSelectFont().
There must be some hidden change in state going on, or something very different under the hood w/r/t these two almost identical Core Graphics glyph-drawing routines, but all my experiments so far have not demonstrated what that might be.
Sigh. I just want to efficiently draw an array of glyphs at a corresponding array of positions in a view.
Any ideas what I'm getting wrong?
After much experimentation enabled by being whacked upside the head by Peter Hosey's response (even though some of it isn't quite right, many thanks!), here's the source of my confusion and an explanation I'm pretty sure is correct (well, the code is doing what I expect it to, anyway).
In the usual higher-level PostScript path/drawing model, drawing a character updates the current point (path end) to the position where a next character might appear, leaving the current user-space transform the same. But under the hood, the text matrix transform is translated by the glyph's width (or more accurately by an advance vector) so that the next character to be drawn can start at, or with respect to, a new text origin. The text matrix's scale factors remain unchanged after translation.
So the initial setup call to CGContextSetTextMatrix() to flip the vertical sense of the text matrix is still necessary (if user-space is similarly flipped), because otherwise both glyph-collection drawing routines will draw the glyphs upside-down w/r/t path drawing, no matter where the text drawing starts or which drawing routine is used.
Neither of the two glyph collection drawing routines affects the current path. They are lower-level than that. I found that I could intersperse either routine among path construction calls without affecting a path's position or shape.
In the code posted above, the position data that CGContextShowGlyphsAtPositions() uses to draw the glyph collection are all relative to the user-space point corresponding to the current text matrix's origin, which was translated to the right of the previously drawn '#' glyph. Because I was using such a large font size, position[0] was causing the next '#' glyph to be drawn outside the view's bounds, so it wasn't visible, but it was being drawn.
But there's still some nuances among the two routines. CGContextShowGlyphsAtPositions() can never be used to place glyphs at any absolute user-space position. So how do you tell it where to start? The answer (or at least one answer) is that CGContextShowGlyphsAtPoint() updates the origin of the text matrix to the given user-space point even if there are no glyphs to draw. And CGContextShowGlyphsAtPoint() must translate the text matrix after each glyph it draws, because what would be the point (so to speak) of drawing the entire glyph collection on top of one another.
So one can "move" to a non-path point in user-space using CGContextShowGlyphsAtPoint() with a glyph count of 0, and then one can call CGContextShowGlyphsAtPositions() (any number of times) with a vector of positions each of which will be treated relative to the text matrix's origin (or really, the user-space point corresponding to it) without the text matrix origin being updated at all when CGContextShowGlyphsAtPositions() returns.
Finally, note that the position data provided to CGContextShowGlyphsAtPositions() is in user-space coordinates. A comment in Apple's header file for these routines expressly says so.
One possibility is this, from the CGContextShowGlyphsAtPositions document:
The position of each glyph is specified in text space, and, as a consequence, is transformed through the text matrix to user space.
The text matrix is a separate property of the context, distinct from the graphics state's current transformation matrix.
It doesn't say that about CGContextShowGlyphsAtPoint:
This function displays an array of glyphs at the specified position in the user space.
(Emphasis added to both quotes.)
So, your text matrix is not actually used when you show glyphs from a single point.
But then, when you show glyphs at an array of positions, it is used, and you see the symptom of a wrong matrix. Specifically, your matrix to try to flip the text back the other way is wrong: it flips the coordinate system upside down. You are drawing outside of the view.
(Try setting it to scale by 0.5 instead of -1 and you'll see what I mean.)
My recommendation is to take out your CGContextSetTextMatrix call.