The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Même si je comprends votre alphabétisation apparente, j'ai l'honneur de vous informer, Madame, que je suis le Marquis de Sade.
Saint Evrémonde est un imposteur bourgeoise, et arriviste, un homme sans subtilité que ce soit. Bien sûr, je ne répète ce que de son épouse m'a dit que j'ai apprécié ses faveurs.
Des fessées heureux ! M. de S.
“Use the word 'cybernetics,' Norbert, because nobody knows what it means. This will always put you at an advantage in arguments.” Claude Shannon (Information Theory scientist): letter to Norbert Weiner of M.I.T., circa 1940
Just spent some hours today tracking down what I felt was a really odd and unexpected error that turned out to be really simple. I made a webpage that contained a chart, so far no problem. But when I moved the code over to the server the chart titles turned out smaller than on my devmachine. So identical code rendered as images turned out having different size of the text on two machines that I thought had the same settings.
Well, to the story belong that I got a new devmachine last week. It's a 14" laptop with 1920x1080 resolution (and a ridiculously fast harddrive compared to my old machine), so the clever people at Dell thought that as you obviously don't buy high resolution to get more real estate, had set the default DPI at 120 instead of 96. So I immediately set it down to 96DPI and thought no more of it. Problem was just that the IIS Worker Process uses a separate account that still had the default 120 DPI setting. And the rendering of text uses that default setting on the Worker Process Account rather than the setting on my account
So whose fault is this? Mine for not setting the font size in pixels instead of points? Or Dells for having a stupid default setting? Perhaps Devexpress for using a local environment setting for something that should have a standard translation in the Control?
Your call. Whose fault is it?
But more important, how should something like DPI be handled on the net? It shouldn't be set at the server, but rather use the setting from the client, or? /Rant over.
The DPI of the server or the IIS instance should be irrelevant. You should be rendering that chart in a machine-independent way.
I guess the component is designed to be used as an embedded UI control so it kind of makes sense that it picks up your local DPI setting by default. It's mostly your fault I suppose (assuming setting a pixel size makes it work right) but definitely an understandable mistake to make!
I would guess that the root of the problem is that he is using some control that makes an image on the fly. (As opposed to creating a drawing on HTML canvas.) If that is the case, then the image will most likely use the GDI of the server in rendering the image before sending it. Thus, the server settings begin to matter.
Just reading up on CSS and found out that a pixel is not a pixel because it is set to a specific size in the browser. So this setting is a browser setting so that when you define a page in pixels (as we all seem to do) it renders 'consistently' across multiple different resolutions. So the whole thing is not as simple as it sounds.
Problem was just that the IIS Worker Process uses a separate account that still had the default 120 DPI setting
This isn't really the problem. The problem is that the IIS Worker Process uses a locally sourced DPI value AT ALL. There is no single answer that will be correct for all the platforms that it will render for. Sure, you just fixed it for platforms set to 96 DPI, but that means you just broke it for platforms set to 120 DPI.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
This sounds cool and open source too. I'd like to be a fly on the wall for these meetings. "That’s why Facebook, LinkedIn, Twitter, and Google have teamed up to create what they call WebScaleSQL, a custom version of MySQL designed just for large scale web companies. Their changes to the database will be open sourced, meaning they’ll be freely shared with the world at large, and the companies plan to contribute their changes back to the original MySQL project. “Our goal in launching WebScaleSQL is to enable the scale-oriented members of the MySQL community to work more closely together in order to prioritize the aspects that are most important to us,” Facebook’s Steaphan Greene wrote in a blog post announcing the project this morning.