Can someone point me to how to clip marks in Vega 3.0?
For example, I start with the spec from https://vega.github.io/vega/examples/line-chart/. I then set the y scale's domainMin:20 and domainMax:50 but see its lines leak past y=20 and y=50.
I then thought autosize:"none" might correct this, but the clipping not only is applied to the marks, but to the axis ticks and labels as well.
Never mind, I found the answer - set clip:true to marks.
Related
I try to auto scale the y-axis for an LineChart. If I set the option autoScaleMinMaxEnabled, followed by an notifyDataSetChanged no auto scale occurs.
Also toggeling autoScaleMinMaxEnabled in ChartsDemo seems not to work. Is there a special trick?
Many thanks! - Tino
The "trick" is that min/max of the Y-axis is determined dynamically, during scrolling, depending on the y-values that are contained in the visible x-range.
If you want to see it working in the demo, then zoom in, enable autoScaleMinMaxEnabled, and then scroll to the right. Watch the Y-axis.
So I have 3 lines (technically patches) that have some transparency enabled. These lines were generated by the patchline FEX submission. The FEX entry works great by making patches seem like lines by adding a NaN to the end of the data so it doesn't create a big black patch between the end points of my line.
My lines looks like this
__ __
\ /
_ \ / _
\ \__/ /
\______/
The patch extends from the left end point to the right end point in a straight line across the top and then follows the line on the bottom. The actual patch is hidden (not drawn) though so all the user sees is the lines
The problem is if I wanted to click the bottom hump of the top line, it acts like I clicked the bottom line because it is part of that patch.
I have thought of a couple of workarounds and was hoping you guys could point out flaws or add ideas I might have missed with my workarounds.
Workaround #1
Ideally, I would create an actual line (line series obj.) over the transparent lines. I would turn hittest off on the patches and I would make the actual line invisible, but turn hittest on. The problem I am 99% sure exists is that if visibilty is off, you can't click the object. If anybody has a work around to that issue (documented or otherwise), that would be great.
Workaround #2
Turn the patchline hittest property to off. Make mock line objs. that follow the patchline coords. and have a line width very very small so as to make the line ideally pretty much invisible and have hit test clicks point to these lines instead. Has anybody tried something like this before? (I'm at work and can't try it now)
Workaround #3
NOTE THAT I REALLY DONT WANT TO DO THIS It is of course possible to turn off hittest for the patch/line objs and use the axes buttondown to figure out what patch obj (just the line part) it was closest to.
Once again, any insight would be much appreciated either about my possible work arounds, the situation in general, etc.
Thanks, Shaun
The problem can be illustrated with two line-thick patches, one of which is NOT parallel to the axes:
patch([2 8 8],[5 10 10],'w','EdgeColor','b','EdgeAlpha',0.4,'LineWidth',3)
patch([2 8 8],[4 4 4],'w','EdgeColor','r','EdgeAlpha',0.4,'LineWidth',3)
xlim([0 10])
ylim([3 11])
You cannot select but those lines which are parallel to one of the axes.
Workaround #1: impossible.
Workaround #2: quite visible, why would you need transparent lines then?
Workaround #3: the only way...
Workaround alternative: submit to the TMW a technical request to improve clickability of patches.
Oleg, your initial post somehow inspired me to come up with my elegant solution. (Don't ask me how, just accept my "thank you" haha)
The elegant solution to my problem required me to go beyond patch properties and turn to the axes child order. Under the assumption that none of the lines would intersect each other, I was able to plot them in a order where the bottom one was first, then the second lowest, etc. until I got to the top (effectively rearranging child order).
If anybody else stumbles upon this, what you can do (assuming your lines don't intersect) is to sort the first Y (or whatever values) to go from lowest to highest (in this case) in your plot, and make sure your sort function returns the indicies.
I don't have my computer in front of me, but what you end up doing is effectively making an acontinuous for loop, looping through the indicies.
something like:
for i=[6 2 5 4 1 3]
plot(X(:,i),Y(:,i))
end
Where the 6th column was my lowest data, 2nd column was second lowest on plot, etc.
To try and solve this problem, I started looking into writing a plugin for flot to do what I needed. It looked surprisingly straight-forward, but I have run into a minor snag. I First used the draw hook to draw my axis (note: I'm aware this code needs some error checking to make sure the origin isn't off the chart)
function draw(plot, ctx) {
var offset = plot.getPlotOffset();
var origin = plot.pointOffset({ x: 0, y: 0 });
ctx.moveTo(offset.left, origin.top);
ctx.lineTo(plot.width() + offset.left, origin.top);
ctx.stroke();
ctx.moveTo(origin.left, offset.top);
ctx.lineTo(origin.left, plot.height() + offset.top);
ctx.stroke();
}
And this works, with 2 small snags. The first and most important is that for some reason it makes the very last point of my data series change color! See here:
The point in the upper right-hand corner has turned black. By stepping through the code I can observe that this only happens when the axes are drawn. Before my draw code is called, the point is the correct color. So I think it has something to do with the drawing on the first "stroke". For some reason it seems to then apply the black color to the last point. Any idea on how to fix this?
The second problem is that this code is called only after flot has draw everything else (including the data points) which means that my lines appear on top of points instead of underneath them. This is only a problem for those two points that are very close to the vertical axis. Looking at the flot documentation, it mentions a drawBackground hook, but this doesn't seem to actually exist. I tried using it and it complained the drawBackground was null. So what happened? And is there a better place to hook into and draw my axes? I want to draw after flot has worked out the size of the plot area and before it draws the first series of data points.
What's currently on the website API documentation does not match the newest released version (0.7). In order to use the backgroundDraw hook, you'll need a newer version of flot, directly from their github repository. The newest version is fine, but anything after this commit would be workable.
I am creating a Microsoft Word document using the OpenXml library. Most of what I need is already working correctly. However, I can't for the life of me find the following bit of information.
I'm displaying an image in an anchor, which causes text to wrap around the image. I used WrapSquare but this seems to affect the last line of the previous paragraph as shown in the image below. The image is anchored to the second paragraph but causes the last line of the first paragraph to also indent around the image.
Word Screenshot http://www.softcircuits.com/Client/Word.jpg
Experimenting within Word, I can make the text wrap how I want by changing the wrapping to WrapTight. However, this requires a WrapPolygon with several coordinates. And I can't find any way to determine the polygon coordinates so that they match the size of the image, which is in pixels.
The documentation doesn't even seem to indicate what units are used for these coordinates, let alone how to calculate them from pixels. I can only assume the calculation would involve a DPI value, but I have no idea how to determine what DPI will be used when the user eventually loads the document into Word.
I would also be satisfied if someone can explain why the issues described above is happening in the first place. I can shift the image down and the previous paragraph is no longer affected. But why is this necessary? (The Distance from text setting for both Left and Top is 0".)
The WrapPolygon element has two possible child elements of LineTo and StartPoint that each take a x and y coordinate. According to 2.1.1331 Part 1 Section 20.4.2.9, lineTo (Wrapping Polygon Line End Position) and 2.1.1334 Part 1 Section 20.4.2.14, start (Wrapping Polygon Start) found in the [MS-OI29500: Microsoft Office Implementation Information for ISO/IEC-29500 Standard Compliance]:
The standard states that the x and y attributes are represented in
EMUs. Office interprets the x and y attributes in a fixed coordinate
space of 21600x21600.
As far as converting pixels to EMUs (English Metric Units), take a look at this blog post for an example.
I finally resolved this. Despite what the standard says, the WrapPolygon coordinates are not EMUs (English Metric Units). The coordinates are relative to the fixed coordinate space (21600 x 21600, as mentioned in the quote provided by amurra).
More specifically, this means 0,0 is at the top, left corner of the image, and 21600,21600 is at the bottom, right corner of the image. This is the case no matter what the size of the image is. Coordinates greater than 21600 extend outside the image.
According to this article, "The 21600 value is a legacy artifact from the drawing layer of early versions of the Microsoft Office."
When I make a figure in Matlab, with a legend and a rectangle that touches the y axis (strange, I know) upon exporting the figure to eps (or pdf) I've noticed that the rectangle obtains the line-style of the last line drawn (rather than what the rectangle was drawn with)
This behaviour also occurs for rectangles drawn after the one that touches the axis...
This doesn't happen if the rectangle is drawn before the legend is created....
Needless to say, it took me half a day to create a minimal example:
clf
L=plot(X,sin(X),'--');
legend(L,'sin(x)')
rectangle('position',[0.001,.1,.7,.7])
rectangle('position',[0,.5,.6,.7])
rectangle('position',[0.001,.3,.5,.7])
%legend(L,'sin(x)')
On the screen the 3 rectangle have solid lines, as they should. but once they are exported, the result has the last two with dashed lines (like the sin(x)). If the legend command is done later (as in the commented out line), everything works as it should....
Is this a feature or a bug?
This is not a feature. I am submitting this to development.
You found a workaround that works with minimal code gymnastics. I would document it in your code so someone does not change it unknowingly and move on.
If you are open to other output formats, notice this is not an issue with formats that use an output filter of MATLAB.
http://www.mathworks.com/access/helpdesk/help/techdoc/ref/print.html
(Graphic Format Files section, right column in table)
-Doug, Advanced Support at MathWorks dealing with graphical issues.