(this is for running reports outside of rally via the loginKey - currently using 1.26, although i have tried using up to 1.32 with no difference in results)
it seems that even though the iteration burndown chart accepts width and height parameters, they are not reliable in any sense, and often not honored at all. if i extract it down to the rendered iframe, i see the following link:
https://loginapirally1.rallydev.com/slm/analytics/reports/4/run?WIDTH=1024&HEIGHT=768&ITERATIONS=[MY_ITERATION]
but the chart is not near that size at all - often it seems to default to a very small size (540pt x 300pt) no matter what w/h is requested. in my implementation, i have the burndown chart in a div that is first adjusted to the size of the window and then those dimensions are passed to the cart object. at some sizes, it will come close to taking up the space, but at others it will revert back to the default size.
is this a known issue? am i missing anything obvious? thanks in advance for any thoughts anybody has!
For whatever reason, I have found that the largest I can get most all of the standard reports is Height = 599 and Width = 999. If I go with anything larger, I end up getting back a size much smaller than 599x999. One exception is the Velocity Chart, in which if you have Height of 599 it is large but has a vertical scroll bar, but if you make the height 600 it is smaller and does not have a scroll bar.
i have received confirmation from rally support that indeed this is the max supported resolution when using loginkey:
"Just wanted to let you know that I have received confirmation from our engineering team that the maximum resolution through LoginKey is indeed 600x1000, so the 599x999 would indeed be correct."
Related
Not discussing the good and bad of tracking pixels here, I wonder whether it is ok to set width and height of a tracking pixel to 0 each?
All examples and usages I see use a value of 1 for these, so I wonder if there is any reason for it?
I just quickly tried it in Chrome and saw that indeed, an image with width and height set to 0 is requested by the browser, despite not being rendered.
Maybe there are browsers out there that would not send a request to 0-dimensioned images and this is the reason why all examples use 1 pixel?
Could anyone enlighten me here?
Ok, it obviously is ok to use a value of 0 für tracking pixel width and heihgt. There are examples out there that use these values.
Pro: You can skip CSS for hiding these pixels.
I am working on a corporate-level summary report for my employer. Because this is a fairly high-level report, I'm trying to "pretty" it up a bit (I think the standard SAS output is exceptionally ugly). I've managed to include graphics using ODS REGION and the like, but I'm having trouble generating a fairly basic bar chart.
All I want to do is draw boxes onto the PDF file by specifiying X,Y and W,H and the background color. I've gotten close using this SUGI paper (which employs ODS REGION with a PROC GSLIDE).
That works OK, but I've run into many vexing little issues. For example:
There's a minimum height and width for GSLIDE (appx 3 points) which has made it very difficult to represent small numbers on my bar graph
The corners of GSLIDE are slightly rounded, causing strange looking "artifacts" when attempting to overlay and stack them
There's apparently a "maximum" width (appx 480 points). I think I might be able to solve this with the GOPTIONS VSIZE attribute, but I have to be careful because if the ODS REGION and GSLIDE are exactly the same size, then SAS (for some reason) thinks that the GSLIDE is bigger than the REGION and fails to render GSLIDE properly.
I've searched the internet for an easier approach, but it seems there are few SAS programmers trying to do what I'm doing. I know that I'm reinventing the wheel a bit in that SAS providers bar charts via SAS/GRAPH, but they don't provide the level of customization I need to display the results the way I want them.
How can I draw a simple rectangular shape, with nice square corners, and no weird width/height limitations, on a PDF file?
This isn't direclty relevant to the question, but since it's been brought up, here's an idea of what the bar chart looks like:
Each row measures a metric across a mutually exclusive sub-section of a larger population. The Gray bar represents the total size of the population being measured. The blue bar measures the metric (and the reported number is the metric across the sub-section). The "white bar" is the size of the total population. (The light blue bar is an alternate metric displayed only for those who are curious - it will always be smaller than the blue bar.) Some sub-sections contain no data, so they are displayed as "N/A".
There's also a rolling total. So, after one or a few sub-sections are reported, they are rolled into the rolling total. The gray background groups the related sub-sections, with the rolling total reported at the bottom.
This is pretty much exactly what I want this chart to look like. If it can be done using standard SAS charts, I'd be happy to use them - but I think it's been easier to get this effect on my own by painting the graph myself.
I found a partial answer... you can use a LayoutRegion defined via PROC TEMPLATE to set the background color of an ODS REGION. You still must "put something" within the region to force SAS to render it (for example, ODS TEXT = " ";), but it removes at least one pain point: minimum and maximum sizes.
Unfortunately, the corners are still rounded, but I'll update this answer if I can figure out a way to fix that via an attribute or something.
I'm trying to do a image resizing operation where:
Image stock is at 2x dimension (for Retina)
If device detected is low resolution (standard), reduce image by 50% back to 1x (i.e. zoom=0.5)
If device max resolution is 800, set the image not going over 800 (i.e. maxwidth=800)
However, when I combine the two operations (i.e. zoom=0.5&maxwidth=800), it basically give me an image that is 800 x 50% = 400. But I would like to have the image first reduced by 50% (e.g. if image was 2000w x 1000h, reduce it to 1000w x 500h), then make sure width does not go over 800 (i.e. 800w x 400h).
Is there any way to approach this?
Thanks in advance!
Stephen
Zoom operates after all other sizing operations, such as width/height/maxwidth/maxheight. This ensures that you can add 'zoom' to any image command set and zoom the result.
I.e, Zoom multiplies the 'result' size, not the source size.
If you're doing responsive images, you should consider trying slimmage.js. It's rather ideal if you want to handle both pixel densities and CSS viewport or element rules effectively together.
If you really need to build your own solution, you'll need to do the math either client side (and set maxwidth alone) or server side (and add a command that applies your custom rules).
Full disclosure: I wrote Slimmage, so I personally think it's the best all-around solution, of course :)
I've been looking all over the place to find the solution to this but haven't had success. I have a Sketchflow project and I want to scale every Screen to the browser resolution on running, as in scaling every element of the current Layout to fit the screen.
Do you want the objects themselves to get bigger to fill the screen or to spread out? For objects to get bigger you can wrap the whole thing in a ViewBox.
I am designing a simple music app where the user gets to play instruments i.e. Drums, and the problem that I am facing is with resolutions.
The drums are images, which I have converted them into buttons. Everything looks great at the state that I have designed it.
However, when I switch to other resolution states, the button(image) are distorted, e.g. skewed, scaled, and looks nasty.
I have tried designing or arranging them via selecting 'Enable state Recording', but the specific designs for that state are not being saved.
Have you tried the approaches discussed here? http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx For the actual button sizes, make sure you are not fixing the width/height with pixel values. Use * weighted rows and columns to layout your grids and have the buttons autosize to fill a given cell in the grid. Then match with the appropriate image resource per the article.
Grids are great for dividing up available space but they can't account for changes in aspect ratios. If your items are still set to Stretch (or Fill) then they can end up out of aspect ratio. Another option is to design the entire layout at a fixed size (let's say 1024 x 768 or 1366 x 768) and wrap the entire thing in a ViewBox. ViewBox will scale all elements equally and maintain the aspect ratio, adding letterboxing (or empty space) on the sides / top & bottom if necessary. This might be a better approach for a drum kit.
Hope that helps.
Redid the whole project of designing again.
This time, I put the image inside a specific grid and that made things lot better. :)