How font rendering is done in linux, bsd, windows? how they differ?
I am not talking about browser web font rendering.say for example how input system works? I press mouse keys. they trigger evdev drivers of linux kernel, and the kernel manages the higher level ops.
low level font rendering mechanism. how freetype, pango, window manager, interact with each other. another big question? how unicode support is accomplished??
simply, when I type a character in a text editor, what are the paths does the character flow before coming into the screen. how the MS word or LibreOffice render different fonts together in single canvas??
On *nix text-rendering is done client-side nowadays which means apps use whatever lib they like best to transform unicode codepoints to pixels and feed the result to x. The actual libs used wary widely though people has been converging on fontconfig + freetype + freebidi + harfbuzz in the past years, usually accessed through pango-cairo
A summary was posted here a few years ago
http://behdad.org/text/
It's all a devilishly complex process, you have weeks of reading if you want to understand all the steps involved.
text-rendering linux fonts
Related
I am sorry if my question is a bit vague. I am trying to understand where to look for my problems. I have a regression test suite that captures and compare the screen. It seems like whenever we do some kind of library upgrade the regression tests would fail. Our font settings are the same. The difference would be like the graphics card upgrade (driver), window manager upgrade, or just third party library upgrade (for example Qt library). From human visual testing, the fonts look almost identical, but if I do pixel to pixel comparison, it would show that the snapshots are different. Does anyone have insight how the fonts are rendered ?
Graphics rendering on Linux is a proper mess. While Linux is about as old as Windows, Linux first tried to copy the old X11 window system. This was one of the oldest GUI systems in the world, and it shows - the API is beyond horrible. As a result, lots and lots of libraries were stacked on top of X11 to make it workable, with various degrees of compatibility.
To make things worse, X11 was not just a single implementation, there were competing X11 implementations. Linux chiefly used XFree86, which later became Xorg. And because that's not confusing enough, recent developments added a number of alternatives to X11, which support backwards-compatibility interfaces to X11. Some of those GUI libraries on top of X11 are aware of these new libraries, and may now use the new interfaces.
So, you basically have a pretty fragile system, and any library with a decent programming model has shaky foundations. It's no wonder that changing any part may suddenly cause re-rendering, possibly even choosing entirely new rendering paths.
Windows is a bit better, but it too is old and has some competing GUI libraries. The reason why it's better is probably threefold: there's a single party in control of all the interfaces (Microsoft), they were aware of the bad X11 design from the start (avoided beginner mistakes) and Microsoft has far more resources to spend.
But still, both Linux and Windows had to evolve to support Unicode and the much larger fonts it brought, 24 bits color, high-DPI screens, LCD screens with subpixel resolution, accelerated GPU's, etc. And it's been hard for both to dump old interfaces.
Just looking through the list of issues for the chromium project, a large number of them are cross-platform text rendering issues. Having to use the platform's text rendering system, and cater to their respective idiosyncrasies, I imagine is a lot of work.
Why not simply use the FreeType library and be done with it? FreeType is used in Linux, iOS and Android, among other platforms. So on these platforms, browsers are using a wrapped FreeType library anyway. Why not scrap that wrapping, scrap the platform-supplied rendering on Windows and Mac, and go pure FreeType?
The only answer that occurs to me is that perhaps it's to take advantage of the hardware accelerated composition and blending of glyphs that Windows- and Mac-supplied rendering offers.
Or my other answer is that perhaps it was because WebKit was ported before the subpixel antialiasing patents had expired, so the only way to get subpixel antialiased text was to use platform-supplied rendering.
Are either of these correct? If not, what is the case?
When Safari was ported to Windows, it came with a port of Apple text renderer. Popular opinion was that the text was blurry and illegible.
People get really, really used to how their system renders text and react very sensitively, and very annoyed indeed, to anything different.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there any standard that has a list of web-safe fonts
Is there a list of safe fonts for all browser and os?I use generally tahoma and there isn't any problem for windows but I don't know is there a problem about linux or mac
There's this page, I had it in my Firefox Scrapbook. It covers some of the most useful, widespread fonts and their closest equivalents. Yes it focuses on Windows and Mac. There's a linux/ubuntu/gnome screenshot of the font rendering down there: bottom of the page.
Be wary: this topic is controversial. From a pure design standpoint, the point is moot: there are no equivalent fonts. Never. Using core system fonts your mileage (and your ex width) will vary so wildly that most would simply advise you not to even start.
If you are serious about typesetting you should anyway be using fontsquirrel, google web fonts, or any other #font-face trick. With those, backward compatility will (sort of) be an issue, but not one that's typically considered relevant on linux. (those guys update like crazy)
There are some corner cases though, where I believe this approach is sensible. E.G. You could be searching for a very readable font, and prefer not having the user downloading it. Or you could be in love with some widespread commercial typeface, but can't/won't license it for a reason or the other. (e.g. I personally love the readability Palatino Linotype gives me on Windows)
A last word of warning: if you're targeting mobile devices this approach will drive you insane. Don't even start, or you'll expose your frail soul to the blows of the unmotivated horrors that inhabit Mobile Safari updates. Sanity can't last long under that kind of crossfire.
Short answer: no
There is no guarantee that any given browser / OS will support a specific font.
You can specify families of fonts from which the browser will select the first available font e.g.,
font-family: Arial, Helvetica, Sans-Serif;
This is probably the closest you will get to what you want as it should at least select something of the desired style, if not the exact desired font.
You might take a look at Microsoft's Core fonts for the web project. These fonts are available for Windows, OS X, and Linux-based OSes (among others), but again there is no guarantee that these will be available on any given host.
PyQt experts: I developed the GUI in Windows and used setGeometry to position the widgets. When I tried to run the same code in Linux it looks cluttered.
And added to that in Windows the font size of 8 seems good. But in Linux, especially in Ubuntu, it doesn't appear well since the font size is 10 by default. Some among the differences are the border of the group box doesn't appear in Linux while it is visible in Windows..
Is there a way that I can make the same code to get the same look and feel in Windows and Linux irrespective of the font and size changes and other differences?
In future if I port my application to Mac will the same code work there too? Or should I have to maintain the separate code for each by checking with platform.system() equal to "windows" or "linux"?
The answer is simple: don't use setGeometry directly (to position your widgets).
Consider the following: what if the user wants to resize your application window?
Compose the user interface (you could do this from Designer or from code) within QSplitters (if you want a resize handle between two components) and/or within QVBoxLayouts / QHBoxLayouts (note that these can be nested).
This will make your UI components behave consistently.
I agree with #ChristopheD. Using setGeometry is bad. It's like designing a webpage with fixed pixel geometry and then wondering why it looks bad on another device.
Qt has a lot of wonderful layout code. Let it do it's job.
Qt by default will paint a widget according to instructions contained in the QStyle. You can test how badly you break your layout in different styles easily enough... run your program with different style options. Like so:
program.py -style motif
Also try -style platinum or -style windows. Even different versions of Windows will probably break your layout.
If you really want to see how bad pixel-based layouts are, try running your program with the -reverse parameter... that's how your program will look to someone running it who speaks a Right-To-Left language, like Hebrew or Farsi.
The problem that you have with widgets not drawing where you want them to can be solved by creating custom painting code for your widget. See the PyQt QPainter docs or better yet, the original Qt QPainter docs..
While I hope my answer is useful, it probably means your program needs to be partially rewritten. In the long term, however, it means that you'll have code that is portable between styles and operating systems, and will even work translated (assuming you care about that).
I woud like to create a cross-platform drawing program. The one requirement for writing my app is that I have pixel level precision over the canvas. For instance, I want to write my own line drawing algorithm rather than rely on someone elses. I do not want any form of anti-aliasing (again, pixel level control is required.) I would like the users interactions on the screen to be quick and responsive (pending my ability to write fast algorithms.)
Ideally, I would like to write this in Python, or perhaps Java as a second choice. The ability to easily make the final app cross-platform is a must. I will submit to different API's on different OS'es if necessary as long as I can write an abstraction layer around them. Any ideas?
addendum: I need the ability to draw on-screen. Drawing out to a file I've got figured out.
I just this week put together some slides and demo code for doing 2d graphics using OpenGL from python using the library pyglet. Here's a representative post: Pyglet week 2, better vertex throughput (or 3D stuff using the same basic ideas)
It is very fast (relatively speaking, for python) I have managed to get around 1,000 independently positioned and oriented objects moving around the screen, each with about 50 vertices.
It is very portable, all the code I have written in this environment works on windows and Linux and mac (and even obscure environments like Pypy) without me ever having to think about it.
Some of these posts are very old, with broken links between them. You should be able to find all the relevant posts using the 'graphics' tag.
The Pyglet library for Python might suit your needs. It lets you use OpenGL, a cross-platform graphics API. You can disable anti-aliasing and capture regions of the screen to a buffer or a file. In addition, you can use its event handling, resource loading, and image manipulation systems. You can probably also tie it into PIL (Python Image Library), and definitely Cairo, a popular cross-platform vector graphics library.
I mention Pyglet instead of pure PyOpenGL because Pyglet handles a lot of ugly OpenGL stuff transparently with no effort on your part.
A friend and I are currently working on a drawing program using Pyglet. There are a few quirks - for example, OpenGL is always double buffered on OS X, so we have to draw everything twice, once for the current frame and again for the other frame, since they are flipped whenever the display refreshes. You can look at our current progress in this subversion repository. (Splatterboard.py in trunk is the file you'll want to run.) If you're not up on using svn, I would be happy to email you a .zip of the latest source. Feel free to steal code if you look into it.
If language choice is open, a Flash file created with Haxe might have a place. Haxe is free, and a full, dynamic programming language. Then there's the related Neko, a virtual machine (like Java's, Ruby's, Parrot...) to run on Mac, Windows and Linux. Being in some ways a new improved form of Flash, naturally it can draw stuff. http://haxe.org/
QT's Canvas an QPainter are very good for this job if you'd like to use C++. and it is cross platform.
There is a python binding for QT but I've never used it.
As for Java, using SWT, pixel level manipulation of a canvas is somewhat difficult and slow so I would not recommend it. On the other hand Swing's Canvas is pretty good and responsive. I've never used the AWT option but you probably don't want to go there.
I would recommend wxPython
It's beautifully cross platform and you can get per pixel control and if you change your mind about that you can use it with libraries such as pyglet or agg.
You can find some useful examples for just what you are trying to do in the docs and demos download.