I'm using gdiplus to "stroke" a textout. In certain circumstances, we see a "spike" appearing on the top or bottom of the graphic, and I'm not really sure why. We can minimize this by adjusting stroke width and font size, but thats not a good solution. I'm hoping someone can explain the problem to me.
And the code sample generating this 4, its outline, and the spike (unintentional)
GraphicsPath path(FillModeWinding);
path.AddString(text,wcslen(text),&fontFamily,StateInfo.TheFont.TheWeight,(REAL)minSize,PointF((REAL)ptStart.x, (REAL)ptStart.y),&sf);
// Draw the outline first
if (StateInfo.StrokeWidth > 0) {
Gdiplus::Color strokecolor(GetRValue(StateInfo.StrokeColor), GetGValue(StateInfo.StrokeColor), GetBValue(StateInfo.StrokeColor));
Pen pen(strokecolor,(REAL)StateInfo.StrokeWidth);
graphics.SetSmoothingMode(Gdiplus::SmoothingModeAntiAlias);
graphics.SetPixelOffsetMode(Gdiplus::PixelOffsetModeHighQuality);
graphics.DrawPath(&pen, &path);
}
// Draw the text by filling the path
graphics.FillPath(&solidBrush, &path);
Use Pen::SetLineJoin on the Pen you're using to draw the outline, and use something other than LineJoinMiter.
I agree that the fill mode isn't the issue, I think it is just the pen width used for drawing the outline. For characters that have enclosed spaces with pointy corners (like 4 and 'A'), as the pen width used for drawing the outline gets bigger, the size of the inner shape (the little triangle in the case of the four) gets bigger too.
Eventually the inner shape will get too big to be contained by the outer shape, and will start to poke through, resulting in the artifact you see.
Here is an illustration of a fixed font size (the Impact font again) as the outline width gets bigger. There is no fill here, just a call to graphics.DrawPath():
The fill operation doesn't care about the outline width, and uses the original shape of the letter.
This partially masks the problem by covering up some of the messy outline. Here is with the fill turned on:
Something similar will happen with the character 'A':
EDIT: calling SetLineJoin, as indicated in the other answer, is the way to stop this from happening.
Related
I am new to RRDtool. I generated a graph with grid(--grid-dash 1:0), a LINE(LINE1:rt#4e9a06) and I also have the area between the line and the x-axis coloured (AREA:rt#4e9a06 ). I notice the grid still shows up in the colored-area. I am wondering if there is any way to cover the grid with the colored-area.
Also, I am also wondering if there is any good-looking rrdtool samples/examples available online? Thanks.
I have no way of testing this currently, but here's what the documentation says (emphasis mine) :
[-c|--color COLORTAG#rrggbb[aa]]
Override the default colors for the standard elements of the graph.
The COLORTAG is one of BACK background, CANVAS for the background of
the actual graph, SHADEA for the left and top border, SHADEB for the
right and bottom border, GRID, MGRID for the major grid, FONT for the
color of the font, AXIS for the axis of the graph, FRAME for the line
around the color spots, and finally ARROW for the arrow head pointing
up and forward. Each color is composed out of three hexadecimal
numbers specifying its rgb color component (00 is off, FF is maximum)
of red, green and blue. Optionally you may add another hexadecimal
number specifying the transparency (FF is solid). You may set this
option several times to alter multiple defaults.
What about making an almost transparent grid with arguments like these (note the extra 7F parameter which translates to 127 in decimal):
-c MGRID#<hex triplet>7F -c GRID#<hex triplet>7F
It should still be visible in the background but be invisible (or barely noticeable) once any graph covers it.
Note that this answer from the developer of RRDTool says that the grid is always painted after the graph, so in the end you'll always have it in the foreground, your only solution is to either totally disable it or tinker with color/transparency parameters to make it invisible when covered by the graphed data.
I want to know how Qt does a border when using QPainter's drawRect. The reason for this is I am trying to draw three rectangles next to each other, but I'm having trouble getting them to touch perfectly at all pen sizes.
QPainter's documentation for drawRect says:
A stroked rectangle has a size of [the input rectangle] plus the pen width.
So it goes like this:
I just wanted to add to the answer and address the question about truncation.
Truncation might be happening because you are using the QRect and not QRectF. QRectF gives you floating point precision. Similarly, you can use QPen::setWidthF(qreal width) to ensure your border is not getting truncated either.
I'm trying to figure out how to have a DIV column snapping to some fixed-size grid, via CSS.
Here's the test page I'm working on: http://mapofemergence.com/test/MoEv2/
What I'm trying to get, is the right div (the green one) someway snapping to the background grid quads: when resizing the browser window, the red quads should distribute in the middle area, while the green column should "fill" the remaining area on the right side of the page, and yet remaining always aligned (on the left) with the grid.
Basically, being a the grid's quad size, the right green div should have a variable width, equal to or greater than a, and anyway minor than 2a (in which case it should set back to a width of a, while having one more red quad moving from the lower row to the upper one).
here's an image to get a better idea:
(sorry, my reputation doesn't allow to hyperlink)
I'm not really sure this can be done via CSS, but I'm sure that some of you can help finding some solution or workaround. I wouldn't use javascript, if possible.
Thanks for your help,
s
Unfortunately HTML/CSS don't have features necessary to do what you want. You can only achieve it by using JavaScript.
You should bind a function to window resize event which will set green's div width to desirable value. In jQuery it should look something like that:
$(window).resize(function() {
$("#rx").width(
parseInt($("#rx").css("min-width").slice(0, -2)) + (
($(window).width() - $("#lx").width() - $("#rx").css("min-width").slice(0, -2)) % $(".module:first").outerWidth(true)
)
);
});
Note that this code can be easily optimised but I wanted to make it as simple as possible.
I'm working on an application where I'm drawing some rectangles on the screen, and then will need to manipulate the shapes (change their size, location). I tried to do something with .drawRect and clearing the shape each time I was manipulating it, but the RAM usage was spiking and then falling (presumeably because i keep reinitializing a new component and then removing it, and garbage collection was cleaning it out). This seems like its probably not the most efficient way to do it.
Is there a way for me to just create a shape once, and then move it around on a canvas (and change its width and height without all this RAM usage?
If all you're doing is changing it's offsets, and adjusting it's width and height without needing to fundamentally change the structure of the shape (such as rounding the corners of a rectangle of some such) you should be able to just maintain a reference to the Shape and adjust it's x, y, scaleX, scaleY properties to effect the changes.
You can try Degrafa to draw the rectangle.
To move the rectangle:
Changing the x and y or height and width property of the shape
Using the Flex Move Effect
I have a problem on roating an Image on a canvas in gdi+, I am using the following code, however I find there are alias on the edge.
myPathMatrix.Rotate(GetDCAngle(), MatrixOrderAppend);
myPathMatrix.Translate(
GetDCX(),
GetDCY(),
MatrixOrderAppend);
canvas->SetTransform(&myPathMatrix);
canvas->Draw(XXX);
I used the following code to remove the alias, but failed.
canvas->SetInterpolationMode(InterpolationMode::InterpolationModeHighQualityBicubic);
canvas->SetSmoothingMode(SmoothingModeAntiAlias);
How can I remove the alias at rotated image's edges.
Many thanks!
It's been a while since I worked with GDI+, but I'd assume there's no effective option to remove antialiasing around the edges when rotating. The reason is basically that pixels are square. To rotate an image an amount other than a multiple of 90 degrees, you need to use some kind of interpolation to estimate pixel colours where there weren't really pixels before.
So if there's nothing in the library to specifically take away antialiasing around the edges, have you thought about drawing hard lines in the background colour along the borders? It should be easier to draw those lines without any antialiasing.