On 01/07/2011 04:16 AM, Matthias Melcher wrote: > OK, well, I did this to do the Dillo developers a favor. Now, since pretty > much all the OSs lie (which shouldn't come as a surprise, because until HDMI > the data exchange between screens and graphics cards has been very > minimalistic), we should probably not go beyond what's in FLTK2. Dillo has > been living with this false data from the OS, and their developers must have > figured out a way to deal with it. At least we have an API in FLTK now.
I think the reason all OS's lie is because on all of them there was this strange idea that *fonts* should scale depending on the DPI, but NO OTHER GRAPHICS would do so. All of them had an API to select a font size in "points" while all other graphics, for instance to draw a rectangle or an image, specified dimensions in pixels. This is just stupid really. FLTK tried to fix this by using the point api for specifying font size on all the platforms, but few other programs did this. The end result is that nobody's graphics looked correct unless the dpi was exactly the size the writer of the program had on their screen. On all other screens the fonts would be scaled differently than all the other graphics. Starting with Windows the fix has been to force the DPI so that the this scale is constant on all machines. Linux certainly has copied this, and it sounds like OSX did as well. Too bad. I really blame a whole lot of idiocy years ago for this. Why everybody was under this delusion that fonts must be measured in a different coordinate space than all other graphics leaves me stumped, though it can be somewhat blamed on terminal applications where the only interesting graphics are fonts, I guess... Still does not explain the multi-platform copying of this bug. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
