Have a look at this Sassmeister and let me know where the extra darker blue column to the far right comes from please. I don't believe this is a sub-pixel rounding issue but something else.
What really confuses me is that the extra bit shows up with 12, 13 and 14 columns selected, but not with 10, 15 or 16 columns, though 12 columns means it is a full number.
1200 / 10 = 120
1200 / 12 = 100
1200 / 13 = 92.30769230769231
1200 / 14 = 85.71428571428571
1200 / 15 = 80
1200 / 16 = 75
So regardless of if the result is a full number or a fraction there is somewhat odd behavior of the debug image. I have also removed gutters to be sure it has nothing to do with those. The reason I believe this is not a sub-pixel rounding issue is that this extra bit varies in width when selecting different amounts of columns, best visible with 12 columns.
https://www.sassmeister.com/gist/39b8136d4dcc6b8acfd269f675c97af5
edit
The extra bit is not visible in latest Firefox, only shows up in Chrome, anyone have a fix for Chrome to display the debug image correctly?
This used to annoy me, just a chrome bug, debug img looks perfectly neat in FireFox.
Viewed in FireFox
Related
I'm trying to set a cell element to show as red if % is below 95%, simple enough.
But when setting the rule >= 0% and < 95% then Red as shown in screen shot.
As you can see, the rules have been set, however cells are showing red on everything except 100%
What am I doing wrong?
Change Percent to number and try inputting 0 and 0.95
See here: How to get size of check and gap in check box?
It does not seem to quite answer the question as it applies to DPI.
I have tried several methods, but none yield the results of actual drawn checkboxes at various scale choices in Windows 10. The closest is
12 * GetDeviceCaps (LOGPIXELSX) / 96 + 1
This yields 22 pixels # 168 DPI, however, but Windows draws a 20 pixel checkbox.
Is there a reliable way to determine this? Below is a grid of results I captured, with greens being those that match the "on screen" values.
I'm attempting to get the width and height of the primary monitor via GetSystemMetrics. However, calling:
GetSystemMetrics(SM_CYVIRTUALSCREEN)
Is returning a value of 1018, rather than the actual vertical resolution, which is 1080.
Now, I thought maybe I misunderstood the docs, so I tried calling
SystemParametersInfo(SPI_GETWORKAREA)
to see if maybe that was actually the one that gave the full screen. But, it does as it describes, and returns the working area of the screen (total_height - taskbar_height). Which in my case is 1040 pixels (1080 - 40 (taskbar height)).
So, I'm a bit stumped. Where is 1018 coming from? What's causing it to be off by 62 pixels?
GetSystemMetrics(SM_CYSCREEN) should do the job.
As per MSDN this is equal to GetDeviceCaps(hdcPrimaryMonitor, VERTRES) which might be what you really want.
I can get 2 levels of PivotViewerItemTemplate to work just fine, but not three.
If I set one template at MaxWidth=130, the next at MaxWidth=400 and then a third with no MaxWidth, the second level starts transitioning into the 3rd at about 170 pixels and is no longer visible at all at only 280 pixels. I expect to see the 2nd level until it is 400 pixels wide.
Any tips on what I'm doing wrong here?
TIA
Your MaxWidth's need to be powers of two: 32, 64, 128 etc. You can then have as many levels as there are powers :)
I've written a post explaining it in more detail here http://www.rogernoble.com/2012/04/02/picking-maxwidth-for-pivotviewer-semantic-zoom
This may be waaay to specific for SO, but there seems to be a dearth of info on the sun raster standard. (Even JWZ is frustrated by this!)
Intro: The Sun raster standard says that rows of pixels have padding at the end such that the number of bits in a row is a factor of 16 (i.e. an even number of bytes). For example, if you had a 7-pixel-wide 24-bit image, a row would normally take 7 * 3 = 21 bytes, but sun raster would pad it to 22 bytes so the number of bits is divisible by 16. The code below achieves this for 24-bit images of arbitrary width:
row_byte_length = num_cols * 3;
row_byte_length += width_in_bytes % 2;
Here's my question: both Imagemagick and Gimp follow this rule for 24-bit images, but for 32-bit images it does something weird that I don't understand. Since the bit depth gives 4-byte pixels, any image width would take an even number of bytes per row, which always complies with the "16-bit alignment" rule. But when they compute the row length, they add an extra byte for images with odd widths, making the row length odd (i.e. the number of bits for the row is not divisible by 16). The code below describes what they're doing for 32-bit images:
row_byte_length = num_cols * 4 + num_cols % 2;
Adding one appears to go against the "16-bit alignment" rule as specified by the sun format, and is done with no apparent purpose. However, I'm sure if Gimp and Imagemagick do it this way, I must be misreading the sun raster spec.
Are there any Sun raster experts out there who know why this is done?
Edit
My mistake, Gimp only outputs up to 24 bit Sun raster. Looks like this is only an Imagemagick issue, so probably a bug. I'm labeling this for closure; better to discuss on the ImageMagick forums.
I'd say the image loading code in Gimp and ImageMagick has a bug. Simple as that.
Keep in mind that the SUN-Raster format isn't that widely used. It's very possible that you're one of the first who actually tried to use this format, found out that it doesn't work as expected and not ignored it.
If the spec. sais something along the lines: Regardless of width, the stored scanlines are rounded up to multiples of 16 bits, then there isn't much room for interpretation.
It seems like a mistake to me too. I even wonder if Sun even supports 32-bits RAS files. Basically, a 32-bits image would most likely add an alpha channel as "fourth" colour, to support transparency. But like many image file formats, it's a bit old and others have made adjustments to the format to support 32-bits images. So I think that whomever added the 32-bits support just implemented it wrong and ever since we have to live with that decision.
Compare it with the referer misspelling that has become part of the HTTP standard. :-) A mistake that has become part of a new standard.